Il cambiamento più grande che viene fornito con Ubuntu 15.04 è il passaggio da startstart a systemd come predefinito per la gestione di avvio e avvio del servizio di sistema.
Qualcuno potrebbe spiegare adeguatamente a un utente non tecnico in che modo e se ciò ci riguarda? E perché è importante?
Risposte:
Gli utenti di Layman non dovrebbero notare alcun cambiamento, in base alla progettazione. È un sistema init, non qualcosa con cui gli utenti interagiscono tradizionalmente. Dovrebbe sostituire completamente la funzionalità fornita da Upstart - e fare alcune cose extra - ma l'unica volta che un utente non tecnico vedrà questo è quando va storto.
Utenti, amministratori di sistema e sviluppatori che hanno attivamente utilizzato e sviluppato per Upstart sono le persone che devono affrontare le cose. Esiste un documento di migrazione sul wiki di Ubuntu per aiutare gli sviluppatori a convertire i loro script init, ma utenti e sysops possono continuare a utilizzare Upstart attenendosi al 14.04 (che è supportato fino al 2019).
La ragione e la logica del cambiamento non erano davvero dalla parte di Ubuntu. Canonical era abbastanza felice con Upstart (il loro progetto) ma molti utenti Debian volevano passare a un moderno motore di inizializzazione per ottenere una migliore concorrenza all'avvio e una migliore funzionalità di monitoraggio su tutti i servizi.
Ciò significava una lotta tra varie opzioni (le razionali) e il sistema alla fine vinto.
Canonical è andato d'accordo con Debian perché è il più semplice e probabilmente il migliore. Possono abbandonare un progetto e non stanno combattendo a monte. Ci porta anche in linea con altre distribuzioni (Red Hat, Fedora, ecc.) Che stanno anche passando a systemd. Più attenzione e meno duplicazione degli sforzi.
tl; dr Per una persona non tecnica, questo non dovrebbe interessarti affatto. Per Ubuntu dovrebbe significare meno lavoro e un sistema init migliore.
Qualcuno potrebbe spiegare adeguatamente a un utente non tecnico in che modo e se ciò ci riguarda?
In teoria, ciò non dovrebbe influire sull'utente finale non tecnico che non viene coinvolto nella nitidezza del funzionamento del sistema. In pratica, ci sono molte cose che vedrai.
Ecco un elenco incompleto:
init+ rcsono morsi dal fatto che systemd è retrocompatibile solo con System 5 rc. Come l'avvio, e in effetti la maggior parte degli altri sistemi, professa e fornisce, nessuna retrocompatibilità con System 5 inite il suo file di configurazione /etc/inittab.Quindi le persone che hanno seguito il consiglio dei 30 anni di consigli su "Beh, puoi semplicemente modificarlo in /etc/inittab...", o le persone che usano software che seguono quel consiglio ora hanno software che non iniziano al bootstrap. Esempio: https://unix.stackexchange.com/a/196197/5132
shutdowncomando systemd , come si farebbe con i shutdowncomandi precedenti . A parte il fatto che si chiama modalità di salvataggio in gergo systemd, la modalità di salvataggio non è considerata uno stato di arresto nella visione del mondo systemd. È considerato uno stato in esecuzione . shutdown nowspegnerà la macchina. È systemctl rescueper raggiungere la modalità utente singolo nel mondo systemd. Ulteriori letture: https://unix.stackexchange.com/a/196471/5132--useropzione di systemctl. Questo non si applica a Ubuntu (ancora). upstart e systemd differiscono significativamente in quest'area e Ubuntu versione 15 utilizza ancora l'iniz up - start per sessione piuttosto che un'istanza systemd per utente . Quindi https://superuser.com/a/860598/38062 non si applica, ad esempio. ☺Come altri hanno già notato qui, in teoria, ciò non dovrebbe influire sull'utente finale non tecnico - e in teoria non vi è alcuna differenza tra teoria e pratica, ma in pratica esiste.
Penso che alcune cose pubblicate qui necessitino di alcuni chiarimenti:
È un sistema init, non qualcosa con cui gli utenti interagiscono tradizionalmente.
È stato il caso di SysV init e Upstart, ma non è più il caso di systemd. Fa molte cose con cui gli utenti interagiscono tradizionalmente:
Dovrebbe sostituire completamente la funzionalità fornita da Upstart e fare alcune cose extra
Due cose da chiarire: prima di tutto la sostituzione completa di Upstart:
Uno dei problemi che le persone hanno con systemd è che non esegue script di init SysV. Quindi c'è un esempio non sostituisce completamente la funzionalità fornita da Upstart.
Questo è qualcosa su cui potremmo fare affidamento per oltre 30 anni e tradizionalmente hai scritto gli script SysV init per la massima portabilità senza ripetere te stesso (scrivendo più versioni degli stessi script), il che non è più il caso.
Questo non dovrebbe essere un problema quando si usano solo pacchetti dai repository ufficiali perché presumibilmente tutti i pacchetti che avevano script SysV init o Upstart avrebbero dovuto riscrivere i loro script prima di essere impacchettati.
Sarà solo un problema per le persone che usano software di terze parti o personalizzato che hanno i loro script di init scritti per SysV init o per Upstart e quelli avranno bisogno di riscrivere gli script di init prima di passare a un sistema con systemd (o ottenere il upstart installato, che è anche un'opzione , o passa a un sistema che non usa systemd).
C'è un generatore di systemd-sysv che dovrebbe tradurre automaticamente gli script di init SysV in script di systemd ma ci sono alcuni bug e un lungo elenco di incompatibilità esplicite .
Ora, il secondo chiarimento - su quelle poche cose extra:
Quelle "poche cose extra" che systemd coprirà - secondo A Perspective for systemd - What is Been Achieved, e What Lies Ahead, presentazione di Lennart Poettering nel 2014 su GNOME.asia - sono le seguenti:
Quindi, tornando a: "È un sistema init, non qualcosa con cui gli utenti interagiscono tradizionalmente". - Va sottolineato che il sistema init è solo una voce in quella lista.
E infine, l'ultima cosa che vorrei commentare:
[T] solo una volta che un utente non tecnico vedrà ciò è quando andrà storto.
Oh, che sollievo. :)
Le modifiche più importanti per gli utenti finali (diversi dagli script stessi) sono l'avvio e l'arresto dei servizi e l'utilizzo di comandi come:
che 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 bug, è una scelta progettuale, quindi non è probabile che venga risolto in futuro. Questo è quanto ha detto Lennart Poettering a proposito di 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:
screenscreensystemd-run --user --scope screen(Nota: il comportamento di "upstart" sopra è in realtà qualsiasi cosa tranne systemd, questo non è specifico per l'avvio)
start foosystemctl start foostop foosystemctl stop foorestart foosystemctl restart fooinitctl listsystemctl status(Vedi la mia risposta a Quali sono i pro / contro di Upstart e systemd? Per maggiori dettagli che non rientrano nell'ambito di questa domanda.)
C'è anche una grande differenza nella gestione dei registri perché contrariamente alla tradizione Unix i registri di systemd sono memorizzati in file binari in un formato personalizzato, quindi invece di:
cat /var/log/upstart/foo.log
tail -f /var/log/upstart/foo.log
è necessario utilizzare comandi speciali per accedere ai registri:
sudo journalctl -u foo
sudo journalctl -u foo -f
L'introduzione di systemd prima su Debian e successivamente su Ubuntu non è stata priva di controversie e di una vasta opposizione, come è noto a chiunque abbia scritto uno dei seguenti articoli:
La posizione ufficiale di Debian su systemd e la conseguente controversia hanno portato alla dichiarazione di Exodus nel 2014 e si sono concluse con le dimissioni di Ian Jackson .
Sono nate le iniziative Init Freedom , Without-Systemd.org e Systemd-Free.org , con molte discussioni su Hacker News .