Porting delle vecchie abitudini di Sysvinit su Systemd?

Ho una serie di script con i quali sono stato in grado di installare e configurare i nuovi sistemi Debian stabili. Per avviare automaticamente i programmi utilizzo /etc/rc.local ma per altri casi ho dovuto modificare manualmente il /etc/inittab file. Ho anche altre modifiche come l'aggiunta di --noclear alla riga 1:2345:respawn:/sbin/getty --noclear 38400 tty1 .

Poiché dovevo personalizzare il processo di spegnimento, ho finito per fare questo:

l0:0:wait:/etc/rc.halt 0
...
l6:6:wait:/etc/rc.halt 6

e il mio /etc/rc.halt assomiglia a questo

#!/bin/sh
#   
# rc.halt
#   
# This script is executed when entering level 6/0 (on halt or reboot)

su - teststand -c "/home/teststand/stop_server.sh"  # my custom command

# making sure the halt/reboot process is resumed
test -n "${1}" && /etc/init.d/rc ${1}

exit 0

Oggi è stata la prima volta che ho installato una nuova Debian 8 con systemd come sistema di inizializzazione predefinito. Non ci ho pensato e per la prima volta sono rimasto sorpreso dal fatto che il /etc/inittab mancava il file.

Sui miei sistemi in esecuzione (@work &@home) sto ancora eseguendo i miei sistemi con sysvinit ed è per questo che ho 0 esperienza con systemd .

So che posso passare al vecchio sysvinit ma voglio vedere le differenze con systemd . Inoltre sto personalizzando una nuova installazione in questo momento e non ho molto tempo per finirla, ecco perché non ho tempo per guardare la documentazione.

La mia domanda:c'è un modo per cambiare rapidamente systemd comportamento in modo da poter aggiungere --noclear a getty e usando /etc/rc.halt come punto di partenza per il riavvio/arresto?

Fondamentalmente posso importare rapidamente il mio vecchio inittab modifiche a systemd ?

Grazie

Risposta accettata:

systemd non è retrocompatibile con System 5 init , solo System 5 rc .

La gestione del sistema in stile Linux System 5 comprende due parti, init che viene eseguito come processo #1 e rc che è responsabile dell'esecuzione degli script di avvio e arresto. Questi sono in realtà da due pacchetti distinti in Debian. init proviene dal pacchetto sysvinit; e rc è solitamente dal pacchetto sysv-rc, ma potrebbe provenire dal pacchetto file-rc o openrc.

/etc/inittab è un file di configurazione elaborato da init . systemd non fornisce alcun meccanismo di compatibilità con le versioni precedenti per questo. il meccanismo di compatibilità con le versioni precedenti di System 5 di systemd è solo per System 5 rc , che esegue i programmi in /etc/init.d/ . (È solo per quella specifica versione di rc , inoltre. systemd non implementa alcun meccanismo di compatibilità con le versioni precedenti per i meccanismi di configurazione di file-rc e openrc.)

Questo non è qualcosa che è specifico di systemd. Praticamente no sostituzione init/gestore di sistema (con una sola eccezione in tre decenni) elabora /etc/inittab .

Per collegare un servizio a systemd, devi utilizzare i meccanismi che fa supporto, ovvero la propria unità di servizio file e (tramite un generatore che converte automaticamente in file unit) System 5 rc file di configurazione in /etc/init.d/ .

Dimentica i livelli di esecuzione.

Tutta quella roba del runlevel con cui stai lavorando è stata dichiarata "obsoleta" sui sistemi operativi Linux Systemd. Non c'è eseguire il livello 0 o 6 per entrare. Non esistono senza alcuni spessori di compatibilità.

Per eseguire un servizio allo spegnimento, la risposta ovvia, data da molti, è creare un'unità di servizio che sia WantedBy il shutdown.target . Questo ha alcune sottili insidie, però. Una risposta migliore, ma meno ovvia, è creare un'unità di servizio altrimenti normale, con DefaultDependencies=yes per assicurarti che sia in conflitto con la destinazione di arresto e metti la parte centrale del servizio in ExecStop invece che in ExecStart .

[Unit]
Documentation=https://unix.stackexchange.com/questions/233561/

[Service]
Type=oneshot
User=teststand
RemainAfterExit=true
ExecStart=/bin/true
ExecStop=/home/teststand/stop_server.sh

[Install]
WantedBy=multi-user.target

Non utilizzare il tuo Supervisore Demone di Poor Man in shell script.

Cose del genere sono sempre scritte male.

Relazionato:Fai uscire la coda -f su un tubo rotto?

Se il tuo "servizio" è semplicemente l'esecuzione di un comando chiamato "stop_server.sh", allora l'inferenza è che questo è uno script che arresta un server in un sistema di gestione dei servizi di script di shell eseguito manualmente.

È per questi disastri mal scritti, traballanti, inaffidabili e pericolosi:stop_server.sh stop_server.sh stop_server.sh stop_server.sh stop_server.sh stop_server.sh

Hai systemd. Usalo ed esegui qualsiasi servizio viene eseguito qui utilizzando meccanismi di gestione del servizio appropriati. Non avrai bisogno di questo strano ExecStop -servizio solo se rendi il tuo effettivo servizio eseguibile tramite systemd con DefaultDependencies=true , poiché systemd gestirà l'arresto del servizio al momento dello spegnimento.

Prendendo un Poor Man's Daemon Supervisor in uno script di shell che "gestisce" un servizio, e quindi avvolgendolo in un'unità di servizio systemd per un secondo servizio che si organizza quindi per avviare allo spegnimento, quando l'obiettivo non è altro che gestire il primo servizio e spegnerlo quando il sistema viene arrestato o spento, è un buon modo per entrare nella House of Horror di sistema.

Il mondo vuole che tu pulisca il tuo schermo.

Volendo non cancellare un terminale virtuale tra la disconnessione e il successivo accesso è molto controcorrente, come hanno scoperto Greg Wooledge e altri. La presenza di output sensibile da parte di utenti privilegiati, o capi, che rimane dopo la disconnessione è stato un problema di sicurezza per Unice (e in effetti altri sistemi operativi di accesso remoto in multiproprietà) dagli anni '70, e ci vuole un grande sforzo per annullare tutto le cose che le persone hanno messo in atto per evitare questo problema.

• Molti sistemi hanno una clear_console comando nei loro script di logout della shell come standard. (Questo è di per sé problematico, poiché non funziona bene con i programmi grafici in esecuzione sul terminale virtuale n. 1 del kernel e non funziona con nessun altro tipo di terminale, virtuale o reale.)

  Questo comando deve essere rimosso.

• L'impostazione predefinita nei programmi getty destinati a terminali virtuali, come mingetty , è cancellare il terminale. (Lo fa prima dell'accesso, il che significa che l'output del terminale può rimanere non cancellato se un servizio di accesso TTY viene interrotto. Ironia della sorte, questa funzionalità sarebbe stata collocata meglio in login , che grazie alle necessità di PAM è ancora in esecuzione alla disconnessione.)

  Il --noclear l'opzione deve essere distribuita per disabilitarlo. Ciò comporta la scrittura di uno o più file di sostituzione del file unit, la modifica di ExecStart impostazione o semplicemente indicando [email protected] in un file di unità locale di propria ideazione.

• Systemd ha fornito [email protected] set di unità di servizio modello TTYVTDisallocate=yes che indica a systemd di cancellare un terminale virtuale del kernel. (Anche questo non funziona con nessun altro tipo di terminale, nemmeno con i terminali virtuali nello spazio utente, come in parte si riflette nel suo nome.)

  Anche questo deve essere rimosso, sempre con un override o un modello di servizio diverso indicato da [email protected] .

Ulteriori letture

• Jonathan de Boyne Pollard (2015). /etc/inittab appartiene al passato. . Risposte frequenti.
• https://unix.stackexchange.com/a/196014/5132
• Come eseguire uno script con systemd subito prima dell'arresto?
• Jonathan de Boyne Pollard (2014). Non abusare di su per l'eliminazione dei privilegi utente. . Risposte frequenti.
• Greg Wooledge (08-04-2014). Smettila di cancellare la mia dannata console . Il Wiki di Greg.
• Jonathan de Boyne Pollard (22-08-2015). Blocco del sistema con più tty in Debian Jessie . [email protetta] utente-debian.
• https://unix.stackexchange.com/a/194218/5132
• Jonathan de Boyne Pollard (2015). La casa dell'orrore di sistema . Risposte frequenti.

Correlati:buona spiegazione dettagliata della sintassi /etc/network/interfaces?