sviluppo-web-qa.it

Quali sono i pro / contro di Upstart e systemd?

Sembra systemd è il nuovo sistema init sul blocco, come pstart era alcuni anni fa. Quali sono i pro/contro per ciascuno? Inoltre, come si confronta ciascuno con altri sistemi init?

187
tshepang

Aggiornamento 2016

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

Ubuntu usava 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 sul wiki di Ubuntu - un confronto molto dettagliato tra upstart e systemd e una guida alla transizione da upstart a systemd.

(Si noti che secondo il wiki di Ubunt è ancora possibile avviarsi all'avvio delle versioni correnti di Ubuntu per impostazione predefinita installando upstart-sysv e in esecuzione Sudo update-initramfs -u ma considerando l'ambito del progetto systemd non so come funziona in pratica o se sia possibile disinstallare systemd.)

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

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:

  • upstart: su
  • systemd: machinectl Shell

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

Schermata corrente:

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

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

Esecuzione di tmux:

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

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

Avvio di lavoro foo:

  • upstart: start foo
  • systemd: systemctl start foo

Interruzione lavoro foo:

  • upstart: stop foo
  • systemd: systemctl stop foo

Riavvio del lavoro foo:

  • upstart: restart foo
  • systemd: systemctl restart foo

Elenco lavori:

  • upstart: initctl list
  • systemd: systemctl status

Verifica della configurazione del job foo:

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

Elenco delle variabili di ambiente del lavoro:

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

Impostazione della variabile d'ambiente del lavoro:

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

Rimozione della variabile d'ambiente del lavoro:

  • upstart: 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 utilizzare il comando journalctl per accedervi:

Sudo journalctl -u foo
Sudo journalctl -u foo -f

Script

Esempio 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 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 sostituzione del comando su è 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 comportamento simile a su è ora:

machinectl Shell

È stato ulteriormente spiegato da Lennart Poettering nella discussione al 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 Shell , 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 screen e tmux devono essere invocati in un modo speciale o altrimenti i processi che esegui con loro verranno uccisi (mentre non li uccidi di solito è il motivo principale per cui esegui screen o tmux in primo luogo).

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

A mio avviso, in realtà UNIX era abbastanza strano che, per impostazione predefinita, lasciava che il codice utente arbitrario rimanesse senza restrizioni 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 attivato l'interruttore e infine, per impostazione predefinita, 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 non 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 for Upstart Users lo spiega:

Il modello di Upstart per l'avvio dei processi (lavori) è "avido basato sugli eventi", i. e. 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 l'avvio di processi (unità) è "basato sulla dipendenza pigra", i. e. 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 n fork di Debian è stato proposto 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 da parte per cercare di ridurre la misura in cui le conversazioni sulla governance del progetto sono personalizzate. [...]

Devuan è nato da una controversia sulla decisione di usare come sistema init predefinito per Debian. posizione ufficiale di Debian su systemd è pieno di affermazioni che 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:

Esistono 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 le notizie file per alcune delle funzionalità.

Piani di espansione

Secondo na prospettiva per sistemare ciò che è stato raggiunto e ciò che si trova avanti presentazione di Lennart Poettering nel 2014 su GNOME.asia, ecco i principali obiettivi di sistem, aree 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 uso generale 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, senza mai legarci sopra

Aree già coperte:

Cosa trattiamo 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 fpmurphy1 notato nei commenti, "Va sottolineato che systemd ha ampliato il suo ambito di lavoro nel corso degli anni ben oltre semplicemente 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 Systemd vs SysV Init Linux Cheatsheet .

92
rsp

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 del 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. Ciò significa che non stai scrivendo uno script 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.

68
jsbillings

Ho visto systemd menzionato su Arch General ML oggi. Quindi leggi su di esso. The H Online come sempre è una grande fonte per la tecnologia Linux ed è dove ho trovato il mio posto per iniziare la ricerca Systemd come SysV Init e alternativa Upstart . Tuttavia l'articolo di H Online (in questo caso) non è una lettura molto utile, il vero uso dietro è che fornisce collegamenti alle letture utili.

La vera risposta è nel 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 con /etc) da montare e/o fsck quando potresti avviare demoni come / e /var/ etc, sono già montati. Ha detto che avrebbe usato autofs a tal fine.

Ha anche l'obiettivo di creare .desktop descrittori di init style in sostituzione di script. Questo eviterà tonnellate di processi sh lenti e ancora più fork di processi da cose come sed e grep che vengono spesso utilizzati negli script 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 quello che fanno crond e atd. 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 da non poter eseguire crond o atd, quindi non fa male a nessuno tranne che al 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 nel annuncio di systemd .

29
xenoterracide

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 dal "Wonder autocgroup patch" .
11
enaut

Per uno sguardo molto dettagliato a systemd, iniziando con le prime bozze di progettazione (e una critica dettagliata dei sistemi di 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) Sono molto soddisfatto. 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 di nuovo impostazione manuale delle interdipendenze e che semplicemente non funziona. systemd calcola le dipendenze da solo (o consente solo 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).

8
vonbrand

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.

3
Bert