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 .