Quali sono i pro / contro di Upstart e systemd?


183

Sembra che systemd sia il nuovo caldo sistema init sul blocco, proprio come Upstart era qualche anno fa. Quali sono i pro / contro per ciascuno? Inoltre, come si confronta ciascuno con altri sistemi init?


4
@keith iirc openrc utilizza semplicemente SysV, il vantaggio è una raccolta ben progettata di script di avvio che utilizzano componenti comuni e sono portatili (il che significa che funzionano su qualsiasi shell) È una buona pulizia, ma non è davvero un nuovo initd
xenoterracide

@xeno Lo fa, ma non puoi davvero dirlo. non ci sono link simbolici rcX.d o [KS]. In realtà sysv init stesso è piuttosto flessibile e i runlevel non sono realmente usati nel solito modo.
Keith,

Sebbene l'autore di questo blog sia contrario a systemd, suggerisco di dare una lettura. Esamina i pro e i contro di systemd e BSD init. textplain.net/blog/2015/…
Peschke,

1
Si prega di consultare anche l'aggiornamento unix.stackexchange.com/a/287282/49091 del 2016 .
igaurav,

Eventuali presunti vantaggi di systemd non compenseranno in 100 anni il costo già sostenuto per il mondo per implementarlo. Ogni minuto o ora o giorno speso da un amministratore Unix per gestire questa spazzatura deve già sommarsi a miliardi e per quali benefici reali oltre a un paio di campane e fischietti?
Waslap,

Risposte:


90

Aggiornamento 2016

La maggior parte delle risposte qui ha cinque anni, quindi è tempo di ricevere aggiornamenti.

Ubuntu era solito usare upstart di default ma lo hanno abbandonato l'anno scorso a favore di systemd - vedi:

Per questo motivo c'è un bell'articolo Systemd per utenti Upstart su Ubuntu wiki: un confronto molto dettagliato tra upstart e systemd e una guida alla transizione da upstart a systemd.

(Si noti che, secondo la wiki di Ubuntu, è ancora possibile eseguire l'avvio delle versioni correnti di Ubuntu per impostazione predefinita installando upstart-sysve in esecuzione, sudo update-initramfs -uma considerando l'ambito del progetto systemd non so come funziona in pratica, o se systemd sia o meno possibile disinstallare.)

La maggior parte delle informazioni nelle sezioni Comandi e Script seguenti è adattata da alcuni degli esempi utilizzati in quell'articolo (che è convenientemente concesso in licenza proprio come i contributi degli utenti Stack Exchange ai sensi della Licenza Creative Commons Attribution-ShareAlike 3.0 ).

Ecco un rapido confronto tra comandi comuni e semplici script, vedere le sezioni seguenti per una spiegazione dettagliata. Questa risposta sta confrontando il vecchio comportamento dei sistemi basati su Upstart con il nuovo comportamento dei sistemi basati su systemd, come richiesto nella domanda, ma si noti che i comandi contrassegnati come "Upstart" non sono necessariamente specifici di Upstart - spesso sono comandi che sono comuni a tutti i sistemi Linux e Unix non di sistema.

comandi

In esecuzione su:

  • parvenu: su
  • systemd: machinectl shell

(vedere la sezione "Sostituzione comando su" di seguito)

Schermata corrente:

  • parvenu: screen
  • systemd: systemd-run --user --scope screen

(vedi la sezione "Uccisione imprevista di processi in background" di seguito)

Esecuzione di tmux:

  • parvenu: tmux
  • systemd: systemd-run --user --scope tmux

(vedi la sezione "Uccisione imprevista di processi in background" di seguito)

Avvio di lavoro foo:

  • parvenu: start foo
  • systemd: systemctl start foo

Interruzione lavoro foo:

  • parvenu: stop foo
  • systemd: systemctl stop foo

Riavvio del lavoro foo:

  • parvenu: restart foo
  • systemd: systemctl restart foo

Elenco lavori:

  • parvenu: initctl list
  • systemd: systemctl status

Verifica della configurazione del job foo:

  • parvenu: init-checkconf /etc/init/foo.conf
  • systemd: systemd-analyze verify /lib/systemd/system/foo.service

Elenco delle variabili di ambiente del lavoro:

  • parvenu: initctl list-env
  • systemd: systemctl show-environment

Impostazione della variabile d'ambiente del lavoro:

  • parvenu: initctl set-env foo=bar
  • systemd: systemctl set-environment foo=bar

Rimozione della variabile d'ambiente del lavoro:

  • parvenu: initctl unset-env foo
  • systemd: systemctl unset-environment foo

logs

In upstart, i log sono normali file di testo nella directory / var / log / upstart, quindi puoi elaborarli come al solito:

cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log

Nei registri di systemd sono memorizzati in un formato binario interno (non come file di testo) quindi è necessario usare il journalctlcomando per accedervi:

sudo journalctl -u foo
sudo journalctl -u foo -f

Script

Esempio di script upstart scritto in /etc/init/foo.conf:

description "Job that runs the foo daemon"
start on runlevel [2345]
stop on runlevel [016]
env statedir=/var/cache/foo
pre-start exec mkdir -p $statedir
exec /usr/bin/foo-daemon --arg1 "hello world" --statedir $statedir

Esempio di script systemd scritto in /lib/systemd/system/foo.service:

[Unit]
Description=Job that runs the foo daemon
Documentation=man:foo(1)
[Service]
Type=forking
Environment=statedir=/var/cache/foo
ExecStartPre=/usr/bin/mkdir -p ${statedir}
ExecStart=/usr/bin/foo-daemon --arg1 "hello world" --statedir ${statedir}
[Install]
WantedBy=multi-user.target

su comando di sostituzione

Una susostituzione di comando è stata unita in systemd nella richiesta pull # 1022:

perché, secondo Lennart Poettering, "su è davvero un concetto spezzato" .

Spiega che "puoi usare su e sudo come prima, ma non aspettarti che funzionerà per intero " .

Il modo ufficiale per ottenere un sucomportamento simile è ora:

machinectl shell

È stato ulteriormente spiegato da Lennart Poettering nella discussione sul numero 825:

"Beh, ci sono state lunghe discussioni su questo, ma il problema è che quello che su dovrebbe fare è molto poco chiaro. [...] Per farla breve: su è davvero un concetto spezzato. Ti darà una specie di guscio , e va bene usarlo per quello, ma non è un accesso completo e non dovrebbe essere scambiato per uno. " - Lennart Poettering

Guarda anche:

Uccisione imprevista di processi in background

Comandi come:

non funziona più come previsto . Ad esempio, nohupè un comando POSIX per assicurarsi che il processo continui a essere eseguito dopo il logout dalla sessione. Non funziona più su systemd. Anche programmi come screene tmuxdevono essere invocati in un modo speciale o altrimenti i processi che eseguirai con loro verranno uccisi (mentre non farli uccidere di solito è il motivo principale per eseguire screen o tmux in primo luogo).

Questo non è un errore, è una decisione deliberata, quindi non è probabile che venga riparato in futuro. Questo è quanto ha detto Lennart Poettering in merito a questo problema:

A mio avviso, in realtà UNIX era abbastanza strano che, per impostazione predefinita, lasciava che il codice utente arbitrario rimanesse libero dopo il logout. È stato discusso per secoli tra molte persone del sistema operativo, che questo dovrebbe essere possibile, ma certamente non è il valore predefinito, ma nessuno ha osato finora girare l'interruttore per passare da un valore predefinito a un'opzione. Non ripulire le sessioni utente dopo il logout non è solo brutto e un po 'hacker, ma è anche un problema di sicurezza. systemd 230 ora ha finalmente girato l'interruttore e alla fine di default pulisce tutto correttamente quando l'utente si disconnette.

Per maggiori informazioni vedi:

Concetto di avvio di alto livello

In un certo senso systemd funziona all'indietro: nei lavori di avvio i lavori iniziano appena possono e nei lavori di sistema iniziano quando devono. Alla fine della giornata gli stessi lavori possono essere avviati da entrambi i sistemi e praticamente nello stesso ordine, ma ci pensi guardando da una direzione opposta per così dire.

Ecco come Systemd per gli utenti Upstart lo spiega:

Il modello di Upstart per l'avvio dei processi (lavori) è "avido basato sugli eventi", ovvero tutti i lavori disponibili i cui eventi di avvio si verificano vengono avviati il ​​più presto possibile. Durante l'avvio, upstart sintetizza alcuni eventi iniziali come startup o rcS come "radice dell'albero", i primi servizi iniziano su quelli e successivamente iniziano quando i primi sono in esecuzione. Un nuovo lavoro deve semplicemente installare il suo file di configurazione in / etc / init / per diventare attivo.

Il modello di systemd per i processi di avvio (unità) è "basato sulla dipendenza pigra", ovvero un'unità si avvia solo se e quando un'altra unità di partenza dipende da essa. Durante l'avvio, systemd avvia una "unità radice" (default.target, può essere sovrascritta in grub), che quindi si espande e inizia in modo transitorio le sue dipendenze. Una nuova unità deve aggiungersi come dipendenza di un'unità della sequenza di avvio (comunemente multi-user.target) per diventare attiva.

Utilizzo nelle distribuzioni

Ora alcuni dati recenti secondo Wikipedia:

Distribuzioni utilizzando upstart per impostazione predefinita:

Distribuzioni che utilizzano systemd per impostazione predefinita:

(Vedi Wikipedia per informazioni aggiornate)

Distribuzioni che non utilizzano né Upstart né systemd:

Controversia

In passato è stato proposto un fork di Debian per evitare systemd . È stato creato Devuan GNU + Linux - un fork di Debian senza systemd (grazie a fpmurphy1 per averlo sottolineato nei commenti).

Per ulteriori informazioni su questa controversia, vedere:

Come molti di voi già sapranno, il voto Debian di Init GR promosso da Ian Jackson non è stato utile per proteggere l'eredità di Debian e i suoi utenti dalla valanga di sistema.

Questa situazione prevede un blocco delle dipendenze del sistema che di fatto minaccia la libertà di sviluppo e ha gravi conseguenze per Debian, il suo monte e il suo valle.

Il CTTE è riuscito a scambiare una dipendenza e guadagnare tempo su una sottile installazione di systemd su sysvinit, ma anche questo processo è stato estenuante e pieno di drammaticità. Alla fine, una settimana fa, Ian Jackson si è dimesso. [...]

Mi dimetto dal comitato tecnico con effetto immediato.

Mentre è importante che le opinioni del 30-40% del progetto che concordano con me continuino ad essere rappresentate nel TC, io stesso sono chiaramente una figura troppo controversa a questo punto per farlo. Dovrei fare un passo indietro per cercare di ridurre la misura in cui le conversazioni sulla governance del progetto sono personalizzate. [...]

Devuan è nato da una controversia sulla decisione di utilizzare come sistema init predefinito per Debian. La posizione ufficiale di Debian su systemd è piena di affermazioni secondo cui altri hanno smascherato . I lettori interessati possono continuare a discutere di questo hot topic in The systemd controversy . Tuttavia ti incoraggiamo a mantenere la testa fredda e la tua voce civile. Alla Devuan siamo più interessati a programmarli in modo sbagliato che a guardare indietro. [...]

Sono stati creati alcuni siti Web e articoli dedicati alla controversia sistemica:

Ci sono molte discussioni interessanti su Hacker News:

Tendenze simili in altre distro possono essere osservate anche:

Filosofia

upstart segue la filosofia Unix di DOTADIW - "Fai una cosa e fallo bene". È un sostituto del demone init tradizionale. Non fa altro che avviare e interrompere i servizi. Altre attività sono delegate ad altri sottosistemi specializzati.

systemd fa molto di più. Oltre a avviare e interrompere i servizi, gestisce anche password, accessi, terminali, gestione dell'alimentazione, ripristini di fabbrica, elaborazione dei registri, punti di montaggio del file system, rete e molto altro: vedere il file NEWS per alcune delle funzionalità.

Piani di espansione

Secondo A Perspective for systemd What Is Was Achieved , e What Lies Ahead presentazione di Lennart Poettering nel 2014 su GNOME.asia, ecco i principali obiettivi di systemd, aree che erano già coperte e quelle che erano ancora in corso:

obiettivi di sistema:

I nostri obiettivi

  • Trasformare Linux da un sacco di bit in un sistema operativo per scopi generici competitivo.
  • Costruire il sistema operativo di prossima generazione di Internet Unificare le differenze inutili tra le distribuzioni
  • Riporta l'innovazione al sistema operativo principale

  • Desktop, Server, Contenitore, Incorporato, Mobile, Cloud, Cluster,. . . Queste aree sono più vicine di quanto si possa pensare

  • Riduzione della complessità dell'amministratore, affidabilità senza supervisione
  • Tutto introspettivo
  • La scoperta automatica, plug and play è la chiave
  • Risolviamo le cose dove sono rotte, non fissarle mai

Aree già coperte:

Cosa copriamo già:

sistema init, registrazione journal, gestione login, gestione dispositivo, gestione file temporanea e volatile, registrazione formato binario, salvataggio / ripristino retroilluminazione, salvataggio / ripristino rfkill, diagramma di avvio, readahead, configurazione archiviazione crittografata, rilevamento partizioni EFI / GPT, macchina virtuale / contenitore registrazione, gestione minima dei container, gestione dei nomi host, gestione delle impostazioni locali, gestione dei tempi, gestione dei seed casuali, gestione delle variabili sysctl, gestione della console,. . .

Lavori in corso:

A cosa stiamo lavorando:

  • gestione della rete
  • systemd-networkd
  • Cache DNS locale, risponditore mDNS, risponditore LLMNR, verifica DNSSEC
  • IPC nel kernel
  • kdbus, sd-bus
  • Sincronizzazione dell'ora con NTP
  • systemd-timesyncd
  • Maggiore integrazione con i contenitori
  • Sandboxing dei servizi
  • Sandboxing delle app
  • Formato immagine del sistema operativo
  • Formato immagine contenitore
  • Formato immagine dell'app
  • GPT con rilevamento automatico
  • Sistemi stateless, sistemi istanziabili, ripristino delle impostazioni di fabbrica
  • / usr è il sistema operativo
  • / etc è la configurazione (facoltativa)
  • / var è lo stato (facoltativo)
  • Inizializzazione e aggiornamenti del nodo atomico
  • Integrazione con il cloud
  • Gestione del servizio tra nodi
  • Immagini del sistema operativo verificabili
  • Fino al firmware
  • Caricamento di avvio

Portata di questa risposta

Come notato da fpmurphy1 nei commenti, "Va sottolineato che systemd ha ampliato il suo ambito di lavoro nel corso degli anni ben oltre quello di avvio del sistema".

Ho cercato di includere la maggior parte delle informazioni pertinenti qui. Qui sto confrontando le funzionalità comuni di Upstart e systemd quando utilizzate come sistemi init come richiesto nella domanda e menziono solo le funzionalità di systemd che vanno oltre lo scopo di un sistema init perché non possono essere confrontate con Startup, ma la loro presenza è importante per capire la differenza tra questi due progetti. La documentazione pertinente deve essere controllata per ulteriori informazioni.

Ulteriori informazioni

Ulteriori informazioni sono disponibili all'indirizzo:

extra

Il team LinOxide ha creato un cheatsheet Systemd vs SysV Init Linux .


4
... e si è verificato un tale fork di Debian. Devuan GNU + Linux è un fork di Debian senza systemd.
fpmurphy,

2
Va sottolineato che nel corso degli anni systemd ha ampliato il proprio ambito di lavoro ben al di là del semplice avvio del sistema.
fpmurphy,

1
Posta eccezionale ed estremamente utile per il ragazzo di Cent. Grazie per aver dedicato del tempo signore !!!
origin1tech,

4
@ronsmith service <foo> start/stop/restart/statusfunziona ancora bene. Come la maggior parte dei software unix, systemd fornisce la compatibilità dei comandi con valori predefiniti ben noti.
Shadur

2
Ottima risposta Un punto però: i sistemi operativi BSD non sono distribuzioni Linux: sono diversi sistemi operativi Unix con il proprio kernel.
Giorgio,

68

Sia upstart che systemd sono tentativi di risolvere alcuni dei problemi con i limiti del tradizionale sistema di inizializzazione SysV. Ad esempio, alcuni servizi devono essere avviati dopo altri servizi (ad esempio, non è possibile montare i filesystem NFS fino a quando la rete non è in esecuzione), ma l'unico modo in SysV per gestire è quello di impostare i collegamenti nella directory rc # .d tale che uno è prima dell'altro. Aggiungete a ciò, potrebbe essere necessario ricodificare tutto in seguito quando le dipendenze vengono aggiunte o modificate. Upstart e Systemd hanno impostazioni più intelligenti per la definizione dei requisiti. Inoltre, c'è il problema con il fatto che tutto è uno script shell di qualche tipo e non tutti scrivono i migliori script init. Ciò influisce anche sulla velocità di avvio.

Alcuni dei vantaggi di systemd posso vedere:

  • Ogni processo avviato ottiene il proprio cgroup o un particolare cgroup.
  • Pre-creazione di socket e handle di file per i servizi, in modo simile a come fa xinetd per i suoi servizi, consentendo ai servizi dipendenti di avviarsi più rapidamente. Ad esempio, systemd manterrà aperto il filehandle per / dev / log per syslog, e i servizi successivi che invieranno a / dev / log avranno i loro messaggi bufferizzati fino a quando syslogd non sarà pronto a subentrare.
  • Vengono eseguiti meno processi per avviare effettivamente un servizio. Questo significa che non stai scrivendo uno script di shell per avviare il tuo servizio. Questo può essere un miglioramento della velocità e (IMO) qualcosa di più facile da impostare in primo luogo.

Uno svantaggio che conosco è che per sfruttare il preallocazione socket / FH di systemd, molti demoni dovranno essere patchati per far passare l'FH da systemd.


13
PulseAudio è un sistema audio molto diffamato ( pulseaudio.org ), originariamente scritto da Lennart Poettering, l'autore di systemd. Stavo principalmente scherzando qui, perché conosco diverse persone a cui piace lamentarsi di pulseaudio e sono sicuro che si lamenterebbero anche di Systemd. Onestamente, non ho avuto problemi con systemd o pulseaudio.
jsbillings,

4
Ne fa quasi uno per gli abbondanti fiordi di Plan9 ... tutto è un file.
dhchdhd,

4
A dire il vero, pulseaudio era una soluzione a un problema inesistente. Non c'è niente che PA possa fare che ALSA non può, e ho sentito MOLTE persone che hanno problemi con PA, ancora e ancora.
WhyNotHugo,

3
Due svantaggi di systemd che hai perso: (1) tutti gli script di avvio devono essere riscritti. (2) c'è molta meno compatibilità con i sistemi operativi non Linux (come ad esempio BSD).
WhyNotHugo,

8
Semplicemente fantastico. Dai un'occhiata a 0pointer.de/blog/projects/the-biggest-myths . Ho assistito alla crescita di Systemd e posso attestare che molte delle critiche qui fornite sono del tutto prive di fondamento. Al link troverai un colpo dopo l'altro, confutazione motivata .
vonbrand,

30

Ho visto oggi systemdmenzionato su Arch General ML . Quindi leggi su di esso. H Online come sempre è un'ottima fonte di tecnologia Linux ed è qui che ho trovato il mio posto per iniziare a ricercare Systemd come SysV Init e Upstart alternative . Tuttavia l'articolo di H Online (in questo caso) non è una lettura molto utile, il vero utilizzo è che fornisce collegamenti alle letture utili.

La vera risposta è nell'annuncio di systemd . Ciò fornisce alcuni punti cruciali di ciò che è sbagliato in SysV initd e di cosa devono fare i nuovi sistemi

  • Per iniziare di meno.
  • E per iniziare di più in parallelo.

Il suo piano principale per farlo sembra essere quello di avviare i servizi solo quando sono necessari e di avviare un socket per quel servizio, in modo che il servizio che ne ha bisogno possa connettersi al socket creato molto prima che il demone sia completamente online. Apparentemente un socket manterrà una piccola quantità di dati bufferizzati, il che significa che nessun dato andrà perso durante il ritardo, verrà gestito non appena il demone sarà online.

Un'altra parte del piano sembra essere quella di non serializzare i filesystem, ma di montare anche quelli su richiesta, in questo modo non stai aspettando il tuo /home/, ecc. (Da non confondere /etc) per montare, e / o fsckquando potresti essere i demoni iniziali come /ed /var/ecc. sono già montati. Ha detto che avrebbe usato autofs a tal fine.

Ha anche l'obiettivo di creare .desktopdescrittori di init di stile in sostituzione di script. Ciò impedirà tonnellate di shprocessi lenti e ancora più forchette di processi provenienti da cose simili sede grepche vengono spesso utilizzate negli script di shell.

Hanno anche in programma di non avviare alcuni servizi fino a quando non vengono richiesti e forse anche di spegnerli se non sono più necessari, il modulo bluetooth e il demone sono necessari solo quando si utilizza un dispositivo bluetooth, ad esempio. Un altro esempio dato è il demone ssh. Questo è il tipo di cosa di cui inetd è capace. Personalmente non sono sicuro che mi piaccia, dato che potrebbe significare latenza quando ne ho bisogno, e nel caso di ssh penso che significhi una possibile vulnerabilità di sicurezza, se il mio inetd fosse compromesso l'intero sistema sarebbe. Tuttavia, sono stato informato che l'utilizzo di questo per violare questo sistema è impossibile e che, se lo desidero, posso disabilitare questa funzione per servizio e in altri modi.

A quanto pare, un'altra funzionalità sarà la possibilità di iniziare in base a eventi temporali, a intervalli regolari programmati o in un determinato momento. Questo è simile a cosa cronde atdfare ora. Anche se mi è stato detto che non supporterà l'utente "cron". Personalmente sembra la cosa più inutile. Penso che questo sia stato scritto / pensato da persone che non lavorano in ambienti multiutente, non c'è molto scopo per l'utente cron se sei l'unico utente sul sistema, oltre a non funzionare come root. Lavoro quotidianamente su sistemi multiutente e la regola è sempre eseguire script utente come utente. Ma forse non ho la lungimiranza che hanno, e non lo farà in alcun modo in modo che io non possa correre crondo atd, quindi non fa male a nessuno, ma agli sviluppatori, suppongo.

Il grande svantaggio di systemd è che alcuni demoni dovranno essere modificati per sfruttarne appieno. Ora funzioneranno, ma funzionerebbero meglio se fossero stati scritti appositamente per il suo modello di socket.

Sembra per lo più che il problema dei popoli del sistema con startstart sia il sistema degli eventi, e che credono che non abbia senso o non sia necessario. Forse le loro parole lo dicono meglio.

O per semplificare: il fatto che l'utente abbia appena avviato D-Bus non indica in alcun modo che anche NetworkManager debba essere avviato (ma questo è ciò che farebbe Upstart). È esattamente il contrario: quando l'utente chiede NetworkManager, questo è sicuramente un'indicazione che dovrebbe essere avviato anche D-Bus (che è certamente quello che la maggior parte degli utenti si aspetterebbe, giusto?).
Un buon sistema init dovrebbe avviare solo ciò che è necessario e quello su richiesta. O pigramente o parallelizzati e in anticipo. Tuttavia, non dovrebbe avviarsi più del necessario, in particolare non tutto ciò che è installato per poter utilizzare quel servizio.

Come ho già detto, questo è discusso in modo molto più completo nell'annuncio di systemd .


scusa ma l'annuncio è come un libro. Devo leggere e parlare, prima di poter davvero includere altro qui.
xenoterracide,

2
In che modo è meglio della risposta di @ John? È un segnaposto? Un promo di H Online ?
Tshepang,

1
@tshepang beh in realtà si collega all'annuncio del sistema d e le cose online h hanno collegamenti a quello e altri collegamenti interessanti. è una lettura lunga e noiosa. Potrei aggiungere altro una volta che lo ho criticato ... questo non è un argomento semplice . quando ho scritto questo ho pensato che potresti voler iniziare a leggere prima o poi. ma sentiti libero di rimediarmi. sicuramente la risposta di @jsbillings è decente e migliore della mia finora. ma non buono come leggere l'annuncio stesso
xenoterracide,

@tshepang Probabilmente aggiungerò altro domani, dopo il letto. h roba online ero solo io che ero un buon giornalista e citavo le mie fonti.
xenoterracide,

@tshepang. Ho aggiornato la mia risposta. abbastanza sicuro di aver finito a meno che le persone disponibili su irc: //frenode.net/systemd non decidano di voler offrire una correzione di qualche tipo.
xenoterracide,

11

Bene, una cosa che molti di voi hanno dimenticato è l'organizzazione dei processi in cgroups .

Quindi, se systemd ha avviato qualcosa, inserirà questa cosa nel proprio cgroup e non vi è alcun mezzo (senza privilegi) per consentire al processo di sfuggire a quel cgroup. Ecco le conseguenze di ciò:

  • Un amministratore di un grande sistema con molti utenti ha nuovi modi efficienti per identificare utenti / processi dannosi.
  • Le priorità per la programmazione della CPU possono essere determinate meglio come fatto dalla "patch Wonder autocgroup" .

8

Per uno sguardo molto dettagliato a systemd, iniziando con le prime bozze di progettazione (e una critica dettagliata dei sistemi init esistenti, incluso upstart, e come systemd propone di risolverli), vai alla sua home page . Nel tempo, ci sono stati diversi articoli all'avvio pubblicati in LWN . Basta essere avvisati che qualsiasi menzione di systemd (o pulseaudio) innesca infinite guerre di fiamma.

IMVHO (e come utente Fedora) ne sono molto contento. Qualcosa in questa linea era atteso da tempo per gestire la complessità degli attuali sistemi Linux. Fedora ha usato upstart per un po ', ma non è mai uscito dal palcoscenico di essere un sostituto fantasioso per sysvinit, eseguendo script di init sostanzialmente invariati. La sua promessa di semplificare la configurazione di avvio ha un costo di nuovoimpostazione manuale delle interdipendenze e questo non funziona. systemd calcola le dipendenze da solo (o consente semplicemente di iniziare roba senza riguardo alle dipendenze, si risolvono da sole). Un altro grande vantaggio (alcuni sostengono che sia un grave svantaggio) è che sfrutta le funzionalità specifiche di Linux fino in fondo (in particolare i cgroups consentono di isolare un demone e tutti i suoi discendenti, quindi è facile monitorare, limitare le risorse o ucciderli come un gruppo; ce ne sono molti altri).


3

Journaling - Systemd è letteralmente come la cartella WinSXS quando si tratta di registrare cose, crea copie di copie a meno che non si elimini o riduca manualmente le dimensioni del file che manterrà lontano dal disco rigido. Lo chiamo cookie del caricatore di avvio.


sbagliato. quelli non sono copie e ha un limite configurabile freedesktop.org/software/systemd/man/journald.conf.html
amico
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.