Questo è il comando systemd che può essere eseguito nel provider di hosting gratuito OnWorks utilizzando una delle nostre numerose workstation online gratuite come Ubuntu Online, Fedora Online, l'emulatore online di Windows o l'emulatore online di MAC OS
PROGRAMMA:
NOME
systemd, init - gestore di sistema e servizi systemd
SINOSSI
systemd [OPZIONI...]
init [OPZIONI...] {COMANDO}
DESCRIZIONE
systemd è un gestore di sistema e servizi per i sistemi operativi Linux. Quando eseguito come primo
processo all'avvio (come PID 1), agisce come sistema init che avvia e mantiene lo spazio utente
servizi.
Per compatibilità con SysV, se systemd viene chiamato come init e un PID che non è 1, lo farà
eseguire telinite e passare tutti gli argomenti della riga di comando senza modificarli. Ciò significa init e
telinite sono per lo più equivalenti quando richiamati da normali sessioni di accesso. Vedere telinite(8) per
maggiori informazioni.
Quando viene eseguito come istanza di sistema, systemd interpreta il file di configurazione system.conf e
i file nelle directory system.conf.d; quando eseguito come istanza utente, systemd interpreta
il file di configurazione user.conf e i file nelle directory user.conf.d. Vedere systemd-
sistema.conf(5) per maggiori informazioni.
VERSIONI
Si intendono le seguenti opzioni:
--test
Determina la sequenza di avvio, esegui il dump ed esci. Questa è un'opzione utile per il debug.
solo.
--dump-elementi-di-configurazione
Scarica gli elementi di configurazione dell'unità compresi. Questo restituisce un elenco conciso ma completo di
elementi di configurazione compresi nei file di definizione dell'unità.
--unità=
Imposta l'unità predefinita da attivare all'avvio. Se non specificato, il valore predefinito è default.target.
--sistema, --utente
Da --sistema, indica a systemd di eseguire un'istanza di sistema, anche se l'ID del processo non è 1,
cioè systemd non viene eseguito come processo init. --utente fa il contrario, eseguendo un utente
istanza anche se l'ID del processo è 1. Normalmente, non dovrebbe essere necessario passare
queste opzioni, poiché systemd rileva automaticamente la modalità in cui viene avviato. Queste
le opzioni sono quindi di scarsa utilità, tranne che per il debug. Nota che non è supportato
avvio e manutenzione di un sistema completo con systemd in esecuzione in --sistema modalità, ma PID
non 1. In pratica, passando --sistema esplicitamente è utile solo in combinazione con
--test.
--dump-core
Abilita il core dumping in caso di crash. Questa opzione non ha effetto quando si esegue come istanza utente.
Questa impostazione può essere abilitata anche durante l'avvio sulla riga di comando del kernel tramite
systemd.dump_core= opzione, vedi sotto.
--crash-vt=VT
Passa a una console virtuale (VT) specifica in caso di arresto anomalo. Accetta un numero intero positivo nel
intervallo 1–63 o un argomento booleano. Se viene passato un intero, seleziona quale VT commutare
a. Se sì, è selezionato il kernel VT in cui vengono scritti i messaggi. Se no, nessun interruttore VT è
tentato. Questa opzione non ha effetto quando viene eseguita come istanza utente. Questa impostazione potrebbe
essere abilitato anche durante l'avvio, sulla riga di comando del kernel tramite systemd.crash_vt=
opzione, vedi sotto.
--crash-shell
Esegui una shell in caso di crash. Questa opzione non ha effetto quando viene eseguita come istanza utente. Questo
l'impostazione può anche essere abilitata durante l'avvio, sulla riga di comando del kernel tramite
systemd.crash_shell= opzione, vedi sotto.
--crash-reboot
Riavvia automaticamente il sistema in caso di crash. Questa opzione non ha effetto quando si esegue come
istanza utente. Questa impostazione può essere abilitata anche durante l'avvio, sul comando del kernel
linea tramite il systemd.crash_reboot= opzione, vedi sotto.
--conferma-spawn
Chiedi conferma quando vengono generati i processi. Questa opzione non ha effetto quando viene eseguita come
istanza utente.
--mostra-stato=
Mostra informazioni concise sullo stato del servizio durante l'avvio. Questa opzione non ha effetto quando
eseguito come istanza utente. Accetta un argomento booleano che può essere omesso, ovvero
interpretato come vero.
--log-obiettivo=
Imposta la destinazione del registro. L'argomento deve essere uno dei consolle, rivista, kmsg, giornale-o-kmsg, nullo.
--livello-log=
Imposta il livello di registro. Come argomento accetta un livello di registro numerico o il ben noto
syslog(3) nomi simbolici (minuscoli): emerg, allarme, crit, sbagliare, identificazione dei warning, bacheca, Maggiori informazioni.,
mettere a punto.
--log-color=
Evidenzia i messaggi di registro importanti. L'argomento è un valore booleano. Se l'argomento è
omesso, il valore predefinito è vero.
--log-location=
Includere la posizione del codice nei messaggi di log. Questo è particolarmente rilevante per scopi di debug.
L'argomento è un valore booleano. Se l'argomento viene omesso, il valore predefinito è vero.
--output-standard-predefinito=, --errore-standard-predefinito=
Imposta l'output predefinito o l'output di errore per tutti i servizi e socket, rispettivamente.
Cioè, controlla l'impostazione predefinita per Uscita standard= e Errore standard= (Vedi
systemd.exec(5) per i dettagli). Prende uno dei ereditare, nullo, tty, rivista,
diario+console, syslog, syslog+console, kmsg, kmsg+consoleSe l'argomento è
omessa --output-standard-predefinito= il valore predefinito è rivista e --errore-standard-predefinito=
a ereditare.
--id-macchina=
Sostituisce l'ID macchina impostato sul disco rigido, utile per l'avvio dalla rete o per
contenitori. Potrebbe non essere impostato su tutti zeri.
-h, --Aiuto
Stampa un breve testo di aiuto ed esci.
--versione
Stampa una stringa di versione breve ed esci.
CONCETTI
systemd fornisce un sistema di dipendenza tra varie entità chiamate "unità" di 12
diversi tipi. Le unità incapsulano vari oggetti rilevanti per l'avvio del sistema
e manutenzione. La maggior parte delle unità sono configurate in file di configurazione dell'unità, i cui
la sintassi e l'insieme di opzioni di base sono descritti in unità.sistema(5), tuttavia alcuni sono creati
automaticamente da un'altra configurazione, dinamicamente dallo stato del sistema o programmaticamente
in fase di esecuzione. Le unità possono essere "attive" (ovvero avviate, vincolate, collegate, ..., a seconda di
il tipo di unità, vedi sotto), o "inattivo" (che significa fermato, non vincolato, scollegato, ...), come
così come nel processo di attivazione o disattivazione, cioè tra i due stati
(questi stati sono chiamati "attivazione", "disattivazione"). Uno stato speciale "fallito" è
disponibile, che è molto simile a "inattivo" e viene inserito quando il servizio
in qualche modo non è riuscito (il processo ha restituito un codice di errore all'uscita, oppure si è bloccato, oppure un'operazione è stata programmata
fuori). Se si entra in questo stato, la causa verrà registrata, per riferimento futuro. Nota che
i vari tipi di unità possono avere un numero di sottostati aggiuntivi, che sono mappati al
cinque stati unitari generalizzati descritti qui.
Sono disponibili i seguenti tipi di unità:
1. Unità di servizio, che avviano e controllano i daemon e i processi che li compongono. Per
dettagli, vedi servizio.sistema(5).
2. Unità socket, che incapsulano socket IPC o di rete locali nel sistema, utili per
attivazione basata su socket. Per i dettagli sulle unità socket, vedere systemd.socket(5), per
dettagli sull'attivazione basata su socket e altre forme di attivazione, vedere demone(7).
3. Le unità target sono utili per raggruppare le unità o fornire punti di sincronizzazione ben noti
durante l'avvio, vedere systemd.target(5).
4. Le unità dispositivo espongono i dispositivi del kernel in systemd e possono essere utilizzate per implementare
attivazione basata sul dispositivo. Per i dettagli, vedere dispositivo systemd(5).
5. Le unità di montaggio controllano i punti di montaggio nel file system, per i dettagli vedere systemd.mount(5).
6. Le unità di montaggio automatico forniscono funzionalità di montaggio automatico, per il montaggio su richiesta dei file system
così come l'avvio parallelizzato. Vedi systemd.automount(5).
7. Le unità timer sono utili per innescare l'attivazione di altre unità in base ai timer.
puoi trovare dettagli in timer.di.sistema(5).
8. Le unità di swap sono molto simili alle unità di montaggio e incapsulano partizioni di swap di memoria o
file del sistema operativo. Sono descritti in systemd.swap(5).
9. Le unità di percorso possono essere utilizzate per attivare altri servizi quando gli oggetti del file system cambiano o
sono modificati. Vedi percorso di sistema(5).
10. Le unità slice possono essere utilizzate per raggruppare le unità che gestiscono i processi di sistema (come il servizio
e unità di ambito) in un albero gerarchico per scopi di gestione delle risorse. Vedere
systemd.slice(5).
11. Le unità di ambito sono simili alle unità di servizio, ma gestiscono processi esterni invece di
avviandoli anche. Vedi ambito di sistema(5).
Le unità sono denominate in base ai loro file di configurazione. Alcune unità hanno una semantica speciale. A
l'elenco dettagliato è disponibile in systemd.special(7).
systemd conosce vari tipi di dipendenze, inclusi i requisiti positivi e negativi
dipendenze (ad esempio Richiede= e Conflitti=) così come l'ordinamento delle dipendenze (Dopo= e
Prima=). NB: l'ordinamento e le dipendenze dei requisiti sono ortogonali. Se solo un requisito
esiste dipendenza tra due unità (ad esempio foo.service richiede bar.service), ma no
dipendenza dell'ordinamento (ad esempio foo.service dopo bar.service) ed entrambi sono richiesti per iniziare,
verranno avviati in parallelo. È un modello comune che sia il requisito che
le dipendenze di ordinamento sono posizionate tra due unità. Si noti inoltre che la maggior parte delle
Le dipendenze sono implicitamente create e gestite da systemd. Nella maggior parte dei casi, dovrebbe essere
non è necessario dichiarare manualmente ulteriori dipendenze, tuttavia è possibile farlo
Questo.
I programmi applicativi e le unità (tramite dipendenze) possono richiedere modifiche di stato delle unità. In
systemd, queste richieste sono incapsulate come 'lavori' e mantenute in una coda di lavori. I lavori possono
avere successo o fallire, la loro esecuzione è ordinata in base alle dipendenze di ordinamento del
unità per cui sono stati programmati.
All'avvio systemd attiva l'unità di destinazione default.target il cui compito è quello di attivare all'avvio
servizi e altre unità on-boot estraendole tramite dipendenze. Di solito, l'unità
name è solo un alias (collegamento simbolico) per graphical.target (per gli avvii completi in
l'interfaccia utente) o multi-user.target (per avvii limitati solo alla console per l'uso in sistemi embedded o server
ambienti, o simili; un sottoinsieme di graphical.target). Tuttavia, è a discrezione
dell'amministratore per configurarlo come alias per qualsiasi altra unità di destinazione. Vedere
systemd.special(7) per i dettagli su queste unità target.
I processi generati da systemd vengono inseriti in singoli gruppi di controllo Linux denominati in base a
unità a cui appartengono nella gerarchia privata di systemd. (vedere cgroups.txt[1] per saperne di più
informazioni sui gruppi di controllo, o "cgroup" in breve. systemd utilizza questo per elaborare in modo efficace
tenere traccia dei processi. Le informazioni sul gruppo di controllo sono mantenute nel kernel e sono
accessibile tramite la gerarchia del file system (sotto /sys/fs/cgroup/systemd/), o negli strumenti
ad esempio systemd-cgls(1) o ps(1) (ps xawf -io pid, utente, cgroup, argomenti è particolarmente utile
per elencare tutti i processi e le unità systemd a cui appartengono.).
systemd è compatibile con il sistema di inizializzazione SysV in larga misura: gli script di inizializzazione SysV sono
supportato e viene semplicemente letto come un formato di file di configurazione alternativo (anche se limitato).
Viene fornita l'interfaccia SysV /dev/initctl e le implementazioni di compatibilità di
Sono disponibili vari strumenti client SysV. Oltre a ciò, sono disponibili vari sistemi operativi Unix consolidati.
funzionalità come /etc/fstab o il database utmp sono supportati.
systemd ha un sistema di transazioni minimo: se viene richiesto a un'unità di avviarsi o arrestarsi
lo aggiungerà e tutte le sue dipendenze a una transazione temporanea. Quindi, verificherà
se la transazione è coerente (vale a dire se l'ordinamento di tutte le unità è privo di cicli).
In caso contrario, systemd tenterà di risolverlo e rimuoverà i lavori non essenziali dal
transazione che potrebbe rimuovere il loop. Inoltre, systemd cerca di sopprimere i lavori non essenziali
nella transazione che fermerebbe un servizio in esecuzione. Infine viene verificato se il
i lavori della transazione contraddicono i lavori che sono già stati messi in coda e, facoltativamente,
la transazione viene quindi interrotta. Se tutto ha funzionato e la transazione è coerente e
minimizzato nel suo impatto viene unito a tutti i lavori già in sospeso e aggiunto al
coda di esecuzione. In pratica questo significa che prima di eseguire un'operazione richiesta, systemd
verificherà che abbia senso, correggendolo se possibile e fallendo solo se realmente
non può funzionare.
Systemd contiene implementazioni native di varie attività che devono essere eseguite come parte
del processo di avvio. Ad esempio, imposta il nome host o configura la rete di loopback
dispositivo. Imposta e monta anche vari file system API, come / sys o /proc.
Per maggiori informazioni sui concetti e le idee alla base di systemd, fare riferimento a
Originale Progettazione funzionalità di[2].
Si noti che alcune ma non tutte le interfacce fornite da systemd sono coperte da Interfaccia
Stabilità Promessa[3].
Le unità possono essere generate dinamicamente all'avvio e al momento del ricaricamento del gestore di sistema, ad esempio
in base ad altri file di configurazione o parametri passati sulla riga di comando del kernel. Per
dettagli, vedi generatore.di.sistema(7).
I sistemi che invocano systemd in un contenitore o in un ambiente initrd dovrebbero implementare
Contenitore Interfaccia[4] o inizia Interfaccia[5] specifiche, rispettivamente.
DIRECTORY
Directory delle unità di sistema
Il gestore di sistema systemd legge la configurazione dell'unità da varie directory. Pacchetti
che vogliono installare i file dell'unità devono posizionarli nella directory restituita da
pkg-config systemd --variabile=systemdsystemunitdir. Altre directory controllate sono
/usr/local/lib/systemd/system e /lib/systemd/system. La configurazione utente richiede sempre
precedenza. pkg-config systemd --variabile=systemdsystemconfdir restituisce il percorso di
la directory di configurazione del sistema. I pacchetti dovrebbero modificare il contenuto di questi
directory solo con il enable e disable comandi del systemctl(1) strumento. Completo
l'elenco delle directory è fornito in unità.sistema(5).
Directory delle unità utente
Regole simili si applicano alle directory delle unità utente. Tuttavia, qui il X DG Tavola XY
elenco specificazione[6] è seguito per trovare le unità. Le applicazioni dovrebbero posizionare il loro
file di unità nella directory restituita da pkg-config systemd
--variabile=systemduserunitdirLa configurazione globale viene eseguita nella directory segnalata
by pkg-config systemd --variabile=systemduserconfdir. enable e disable comandi
di systemctl(1) lo strumento può gestire sia i dati globali (vale a dire per tutti gli utenti) che quelli privati (per
un utente) abilitazione/disabilitazione delle unità. L'elenco completo delle directory è fornito in
unità.sistema(5).
Directory degli script di init SysV
La posizione della directory dello script di init SysV varia a seconda della distribuzione. Se
systemd non riesce a trovare un file di unità nativo per un servizio richiesto, cercherà un
Script di inizializzazione SysV con lo stesso nome (con il suffisso .service rimosso).
Directory della farm di collegamento del runlevel SysV
La posizione della directory della farm di collegamento del runlevel SysV varia a seconda della distribuzione.
systemd terrà conto della link farm quando determinerà se un servizio dovrà
essere abilitato. Si noti che un'unità di servizio con un file di configurazione dell'unità nativa non può essere
avviato attivandolo nella farm di collegamento del runlevel SysV.
SEGNALI
TERMINE
Dopo aver ricevuto questo segnale, il gestore di sistema systemd serializza il suo stato, riesegue
se stesso e deserializza nuovamente lo stato salvato. Questo è per lo più equivalente a systemctl
demone-reexec.
I gestori utenti systemd avvieranno l'unità exit.target quando riceveranno questo segnale.
Ciò equivale per lo più a systemctl --utente inizia a uscita.obiettivo.
SIGINT
Dopo aver ricevuto questo segnale, il gestore di sistema systemd avvierà il
ctrl-alt-canc.unità di destinazione. Questo è per lo più equivalente a systemctl inizia a
ctl-alt-canc.targetSe questo segnale viene ricevuto più di 7 volte ogni 2 secondi, viene emesso un segnale immediato
il riavvio viene attivato. Nota che premendo Ctrl-Alt-Canc sulla console verrà attivato questo
segnale. Quindi, se un riavvio si blocca, premere Ctrl-Alt-Canc più di 7 volte in 2 secondi
è un modo relativamente sicuro per attivare un riavvio immediato.
I gestori degli utenti systemd trattano questo segnale allo stesso modo di TERMINE.
SIGWINCH
Quando questo segnale viene ricevuto, il gestore di sistema systemd avvierà il
kbrequest.target unit. Questo è per lo più equivalente a systemctl inizia a kbrequest.target.
Questo segnale viene ignorato dai gestori utenti di systemd.
SIGPWR
Quando viene ricevuto questo segnale, il gestore systemd avvierà l'unità sigpwr.target.
Ciò equivale per lo più a systemctl inizia a sigpwr.target.
SIGUSR1
Quando questo segnale viene ricevuto, il gestore systemd tenterà di riconnettersi al D-Bus
autobus.
SIGUSR2
Quando questo segnale viene ricevuto, il gestore systemd registrerà il suo stato completo in
formato leggibile dall'uomo. I dati registrati sono gli stessi stampati da systemd-analyze cumulo di rifiuti.
SIGILLO
Ricarica la configurazione completa del demone. Questo è per lo più equivalente a systemctl
demone-ricarica.
SIGRTMIN+0
Entra in modalità predefinita, avvia l'unità target predefinita. Questo è per lo più equivalente a
systemctl inizia a obiettivo.predefinito.
SIGRTMIN+1
Entra in modalità di salvataggio, avvia l'unità rescue.target. Questo è per lo più equivalente a
systemctl isolato salvataggio.target.
SIGRTMIN+2
Entra in modalità di emergenza, avvia l'unità di servizio di emergenza. Questo è per lo più equivalente a
systemctl isolato servizio di emergenza.
SIGRTMIN+3
Arresta la macchina, avvia l'unità halt.target. Questo è per lo più equivalente a systemctl
inizia a stop.target.
SIGRTMIN+4
Spegne la macchina, avvia l'unità poweroff.target. Questo equivale per lo più a
systemctl inizia a poweroff.target.
SIGRTMIN+5
Riavvia la macchina, avvia l'unità reboot.target. Questo è per lo più equivalente a
systemctl inizia a riavvia.target.
SIGRTMIN+6
Riavvia la macchina tramite kexec, avvia l'unità kexec.target. Questo è per lo più equivalente
a systemctl inizia a kexec.target.
SIGRTMIN+13
Arresta immediatamente la macchina.
SIGRTMIN+14
Spegne immediatamente la macchina.
SIGRTMIN+15
Riavvia immediatamente la macchina.
SIGRTMIN+16
Riavvia immediatamente la macchina con kexec.
SIGRTMIN+20
Abilita la visualizzazione dei messaggi di stato sulla console, come controllato tramite
systemd.show_status=1 sulla riga di comando del kernel.
SIGRTMIN+21
Disabilita la visualizzazione dei messaggi di stato sulla console, come controllato tramite
systemd.show_status=0 sulla riga di comando del kernel.
SIGRTMIN+22, SIGRTMIN+23
Imposta il livello di registro su "debug" (o "info" su SIGRTMIN+23), come controllato tramite
systemd.log_level=debug (o systemd.log_level=info on SIGRTMIN+23) sul kernel
riga di comando.
SIGRTMIN+24
Esce immediatamente dal gestore (disponibile solo per le istanze --user).
SIGRTMIN+26, SIGRTMIN+27, SIGRTMIN+28
Imposta il livello di registro su "journal-or-kmsg" (o "console" su SIGRTMIN+27, "kmsg" su
SIGRTMIN+28), come controllato tramite systemd.log_target=journal-or-kmsg (o
systemd.log_target=console on SIGRTMIN+27 or systemd.log_target=kmsg on SIGRTMIN+28)
sulla riga di comando del kernel.
AMBIENTE
$SYSTEMD_LOG_LEVEL
systemd legge il livello di log da questa variabile d'ambiente. Questo può essere sovrascritto
con --livello-log=.
$SYSTEMD_LOG_TARGET
systemd legge la destinazione del log da questa variabile d'ambiente. Questa può essere sovrascritta
con --log-obiettivo=.
$SYSTEMD_LOG_COLOR
Controlla se systemd evidenzia i messaggi di registro importanti. Questo può essere sovrascritto
con --log-color=.
$SYSTEMD_LOG_LOCATION
Controlla se systemd stampa la posizione del codice insieme ai messaggi di log. Questo può essere
sovrascritto con --log-location=.
$XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME, $XDG_DATA_DIRS
Il gestore utenti systemd utilizza queste variabili in conformità con X DG Tavola XY elenco
specificazione[6] per trovare la sua configurazione.
$SYSTEMD_UNIT_PATH
Controlla dove systemd cerca i file di unità.
$SYSTEMD_SYSVINIT_PATH
Controlla dove systemd cerca gli script di init SysV.
$SYSTEMD_SYSVRCND_PATH
Controlla dove systemd cerca le farm di collegamento del runlevel dello script di init SysV.
$SYSTEMD_COLORS
Controlla se deve essere generato un output colorato.
$LISTEN_PID, $LISTEN_FDS, $LISTEN_FDNAMES
Impostato da systemd per i processi supervisionati durante l'attivazione basata su socket. Vedere
sd_listen_fds(3) per maggiori informazioni.
$NOTIFY_SOCKET
Impostato da systemd per i processi supervisionati per lo stato e il completamento dell'avvio
notifica. Vedi sd_notify(3) per maggiori informazioni.
NOCCIOLO COMANDO LINE
Quando viene eseguito come istanza di sistema, systemd analizza un certo numero di argomenti della riga di comando del kernel[7]:
systemd.unit=, rd.systemd.unit=
Sostituisce l'unità da attivare all'avvio. Il valore predefinito è default.target. Può essere utilizzato
per avviare temporaneamente un'unità di avvio diversa, ad esempio rescue.target o
servizio di emergenza. Vedi systemd.special(7) per i dettagli su queste unità. L'opzione
prefissato con "rd." è onorato solo nel disco RAM iniziale (initrd), mentre quello
che non è prefissato solo nel sistema principale.
systemd.dump_core=
Accetta un argomento booleano. Se sì, il gestore systemd (PID 1) esegue il dump del core quando
crash. Altrimenti, non viene creato alcun core dump. Il valore predefinito è sì.
systemd.crash_chvt=
Accetta un intero positivo o un argomento booleano. Se un intero positivo (nell'intervallo
1–63), il gestore di sistema (PID 1) attiverà il virtuale specificato
terminale (VT) quando si blocca. Il valore predefinito è no, il che significa che non esiste alcun interruttore del genere
tentato. Se impostato su sì, viene selezionato il VT su cui vengono scritti i messaggi del kernel.
systemd.crash_shell=
Accetta un argomento booleano. Se sì, il gestore di sistema (PID 1) genera una shell quando
si blocca dopo un ritardo di 10 secondi. Altrimenti, non viene generata alcuna shell. Il valore predefinito è no, Per
motivi di sicurezza, poiché la shell non è protetta dall'autenticazione tramite password.
systemd.crash_reboot=
Accetta un argomento booleano. Se sì, il gestore di sistema (PID 1) riavvierà la macchina
automaticamente quando si blocca, dopo un ritardo di 10 secondi. Altrimenti, il sistema si bloccherà
a tempo indeterminato. Per impostazione predefinita, no, per evitare un ciclo di riavvio. Se combinato con
systemd.crash_shell=, il sistema viene riavviato dopo l'uscita dalla shell.
systemd.confirm_spawn=
Accetta un argomento booleano. Se sì, il gestore del sistema (PID 1) chiede conferma
durante la generazione dei processi. Il valore predefinito è no.
systemd.show_status=
Accetta un argomento booleano o la costante auto. Se sì, il gestore systemd (PID 1)
mostra aggiornamenti concisi sullo stato del servizio sulla console durante l'avvio. auto si comporta come
falso finché un servizio non fallisce o non si verifica un ritardo significativo nell'avvio. Per impostazione predefinita, è sì,
salvo che silenzioso viene passato come opzione della riga di comando del kernel, nel qual caso il valore predefinito è
auto.
systemd.log_target=, systemd.log_level=, systemd.log_color=, systemd.log_location=
Controlla l'output del registro, con lo stesso effetto del $SYSTEMD_LOG_TARGET,
$SYSTEMD_LOG_LEVEL, $SYSTEMD_LOG_COLOR, $SYSTEMD_LOG_LOCATION variabili ambientali
descritto sopra.
systemd.default_standard_output=, systemd.default_standard_error=
Controlla l'output standard predefinito e l'output di errore per i servizi, con lo stesso effetto
la --output-standard-predefinito= e --errore-standard-predefinito= argomenti della riga di comando
descritti sopra, rispettivamente.
systemd.setenv=
Accetta un argomento stringa nel formato VARIABILE=VALORE. Può essere utilizzato per impostare il valore predefinito
variabili di ambiente da aggiungere ai processi figlio biforcati. Possono essere utilizzate più di una volta per
impostare più variabili.
systemd.machine_id=
Accetta un valore esadecimale di 32 caratteri da utilizzare per impostare l'ID macchina. Destinato principalmente
per l'avvio di rete in cui è desiderato lo stesso ID macchina per ogni avvio.
silenzioso
Disattiva l'output di stato all'avvio, in modo molto simile systemd.show_status=false lo farebbe. Nota che
questa opzione viene letta anche dal kernel stesso e disabilita l'output del log del kernel. Passando
questa opzione disattiva quindi l'output usuale sia dal gestore di sistema che dal
kernel.
mettere a punto
Attiva l'output di debug. Ciò equivale a systemd.log_level=debug. Nota che
questa opzione viene letta anche dal kernel stesso e abilita l'output di debug del kernel. Passando
questa opzione attiva quindi l'output di debug sia dal gestore di sistema che dal
kernel.
emergenza, -b
Avviare in modalità di emergenza. Ciò equivale a systemd.unit=emergency.target e
fornito per motivi di compatibilità e per facilitarne la digitazione.
salvataggio, singolo, s, S, 1
Avviare in modalità di ripristino. Ciò equivale a systemd.unit=rescue.target e fornito
per motivi di compatibilità e per facilitarne la digitazione.
2, 3, 4, 5
Avviare nel runlevel SysV legacy specificato. Equivalgono a
systemd.unit=runlevel2.target, systemd.unit=runlevel3.target,
systemd.unit=runlevel4.targete systemd.unit=runlevel5.target, rispettivamente, e
fornito per motivi di compatibilità e per facilitarne la digitazione.
locale.LANG=, locale.LINGUA=, locale.LC_CTYPE=, locale.LC_NUMERIC=, locale.LC_TIME=,
locale.LC_COLLATE=, locale.LC_MONETARY=, locale.LC_MESSAGES=, locale.LC_PAPER=,
locale.LC_NAME=, locale.LC_ADDRESS=, locale.LC_TELEPHONE=, locale.LC_MEASUREMENT=,
locale.LC_IDENTIFICATION=
Imposta le impostazioni locali del sistema da utilizzare. Questo sovrascrive le impostazioni in /etc/locale.conf. Per
maggiori informazioni, vedi locale.conf(5) e località(7).
Per altri parametri della riga di comando del kernel compresi dai componenti del sistema operativo principale, per favore
fare riferimento a riga di comando del kernel(7).
PRESE E FIFOS
/esegui/systemd/notifica
Socket di notifica dello stato del demone. Questo è un AF_UNIX socket datagramma e viene utilizzato per
implementare la logica di notifica del demone come implementata da sd_notify(3).
/esegui/systemd/privato
Utilizzato internamente come canale di comunicazione tra systemctl(1) e il processo systemd.
Questo è uno AF_UNIX socket di flusso. Questa interfaccia è privata per systemd e non dovrebbe
essere utilizzato in progetti esterni.
/dev/initctl
Supporto di compatibilità limitato per l'interfaccia client SysV, come implementato da
Unità systemd-initctl.service. Questa è una named pipe nel file system. Questa interfaccia
è obsoleto e non dovrebbe essere utilizzato in nuove applicazioni.
Utilizzare systemd online utilizzando i servizi onworks.net