Nel sistema operativo Linux, così come in Windows, oltre ai normali programmi che possono interagire con l'utente, esiste un altro tipo di programma. Questi sono servizi in esecuzione in background. L'importanza dei servizi difficilmente può essere sopravvalutata, monitorano lo stato del sistema, forniscono la connessione automatica di dispositivi e reti esterni, consentono ai processi di interagire con le apparecchiature (dbus) e vari server web e server di database sono implementati come servizi. A differenza dei programmi utente, i servizi vengono eseguiti in background e l'utente non ha accesso diretto ad essi. L'utente non ha ancora effettuato il login, il download è appena iniziato ed i principali servizi sono già attivi e funzionanti.
In questo articolo, esamineremo la gestione dei servizi Linux. Non toccheremo sistemi già obsoleti come SysVinit, ci concentreremo solo su Systemd. Imparerai come visualizzare i servizi Linux in esecuzione e come arrestarli e avviarli tu stesso.
Per gestire tutto questo, è necessario un servizio principale: un sistema di inizializzazione che avvierà i servizi Linux al momento giusto, si assicurerà che funzionino normalmente, scriva messaggi di registro e, soprattutto, consenta di interrompere i servizi. In precedenza, per gestire i servizi venivano utilizzati gli script. Ho già detto che è possibile avviare il servizio dal terminale, quindi ogni servizio è stato avviato in background uno dopo l'altro, senza possibilità di avvio parallelo, e ha restituito il PID del processo allo script di inizializzazione, è stato salvato e quindi utilizzando questo PID è stato possibile verificare se il servizio era in esecuzione e, se necessario, interrompere il servizio Linux. Tutto questo può essere fatto manualmente.
Ma poi questo metodo è stato sostituito da un nuovo modello e dal sistema di inizializzazione systemd. Il sistema di inizializzazione si avvia immediatamente dopo il caricamento del kernel e inizia a inizializzare i servizi, ora è possibile l'inizializzazione parallela, così come le dipendenze tra i servizi. Pertanto, ora è possibile definire un complesso albero degli ordini di avvio del servizio. Ma non approfondiremo i dettagli della creazione dei servizi, siamo interessati solo al processo di avvio stesso. Dopo l'avvio, systemd raccoglie tutto l'output del servizio nel registro e ne monitora il lavoro, se il servizio si è bloccato, lo riavvia automaticamente.
Un servizio in Systemd è descritto da un file unitario, descrive cosa farne e come comportarsi. Esistono questi tipi di servizi:
Saremo interessati solo al servizio e ad un certo target, ma abbiamo trattato tutti gli altri in modo che tu possa guardare l'immagine un po' di più. Abbiamo trattato le nozioni di base, ora è il momento di configurare i servizi Linux.
Systemd ha uno strumento speciale per la gestione dei servizi su Linux chiamato systemctl. Questa utility ti consente di fare molte cose, dal riavviare un servizio Linux e controllarne lo stato, all'analisi dell'efficienza del caricamento di un servizio. La sintassi dell'utilità è:
$ systemctl opzioni comando servizio servizio...
Le opzioni configurano il comportamento del programma, la verbosità dell'output, il comando specifica cosa fare con il servizio e il servizio è proprio il servizio che controlleremo. In alcuni casi, l'utilità può essere utilizzata senza specificare un comando e un servizio.
Consideriamo tutto in ordine. Le opzioni dipendono molto dai comandi, quindi le vedremo più tardi, ma per ora esaminiamo i comandi:
E ora le opzioni principali:
Come puoi vedere, le opzioni saranno di scarsa utilità ed è meglio prestare maggiore attenzione ai comandi, con l'aiuto dei quali vengono eseguite tutte le azioni.
Ora che conosci già tutte le nozioni di base, i comandi e le opzioni, puoi metterti al lavoro. Affronteremo tutte le altre sottigliezze lungo il percorso. Per prima cosa vediamo i servizi Linux in esecuzione. Saremo interessati solo ai programmi, non a tutti questi componenti aggiuntivi, quindi utilizzeremo l'opzione type:
systemctl list-units --tipo servizio
Il comando mostra tutti i servizi che systemd sa che sono attualmente in esecuzione o sono stati in esecuzione. Il programma non esamina tutti i file, quindi verranno visualizzati solo i servizi a cui è già stato effettuato l'accesso. Stato caricato - significa che il file di configurazione è stato caricato con successo, la colonna successiva attiva - il servizio è stato avviato e in esecuzione o terminato indica se il servizio è attualmente in esecuzione o ha completato con successo il suo lavoro. È possibile scorrere l'elenco utilizzando i pulsanti su/giù.
Il seguente comando consente di ottenere un elenco di servizi Linux, che include tutti i servizi, anche quelli in esecuzione, quelli che non si sono avviati, ma sono noti a systemd, ma non sono tutti i servizi sul sistema:
systemctl list-units --type service -all
systemctl list-units --type service --state in esecuzione
Oppure quelli che falliscono:
systemctl list-units --type service --state non riuscito
Per filtrare, puoi prendere qualsiasi indicatore di stato da qualsiasi colonna. Con un altro comando possiamo vedere tutti i file di configurazione del servizio presenti sul disco. Qui non filtreremo per tipo, lasciamo che sia il programma a mostrare tutto:
systemctl list-unit-files
Ora filtriamo solo i servizi Linux:
systemctl list-unit-files --type servizio
Qui puoi anche utilizzare i filtri per stato. Ora che sai come visualizzare i servizi Linux in esecuzione, andiamo avanti.
Per avviare il servizio utilizzare il comando start, ad esempio:
sudo systemctl avvia application.service
Inoltre l'estensione del servizio può essere omessa, è già sostituita di default. Se il lancio è andato bene, il programma non produrrà nulla.
Puoi interrompere il servizio Linux con il comando:
sudo systemctl interrompe l'applicazione
Puoi visualizzare lo stato di un servizio con il comando status:
Applicazione di stato sudo systemctl
Qui puoi vedere lo stato di esecuzione, terminato, inattivo, non riuscito, ecc. Oltre ad alcune ultime righe dell'output del programma, che saranno molto utili per risolvere il problema di avvio se si verifica.
Come sai, systemd ti consente di caricare automaticamente i servizi all'avvio del sistema secondo necessità. Il comando list-unit-files mostra se il servizio è stato aggiunto all'avvio.
In generale, possono esserci diversi stati qui: abilitato - al caricamento automatico, disabilitato - il caricamento automatico è disabilitato, mascherato - il servizio è nascosto e statico - significa che il servizio è al caricamento automatico, ma non è possibile disabilitarlo.
Pertanto, per ottenere un elenco dei servizi Linux che si avviano automaticamente, è sufficiente filtrarne l'output per stato:
systemctl list-unit-files --state abilitato
Tutti i servizi sono avviati per impostazione predefinita. Puoi anche guardare i servizi statici. Per aggiungere un servizio all'avvio di Linux, utilizzare il comando abilita:
sudo systemctl abilita l'applicazione
E per rimuoverlo dal caricamento automatico.
Completamente incluso nel repository di test. Dalla versione (25-1) systemd ha .
Per installare systemd eseguire:
# apt-get update # apt-get install systemdÈ inoltre necessario un kernel con le seguenti opzioni abilitate:
CONFIG_FANOTIFY=y, facoltativo, richiesto per il readahead di systemd. Disponibile nel kernel Linux >= 2.6.37-rcX. Deve essere attivato per il kernel Debian Linux ().
Dalla versione v8 cgroupfs è montato su /sys/fs/cgroup. Ciò richiede un kernel Linux >= 2.6.36 o un backport di questa patch.
Esempio (per rsyslog: attivazione manuale del servizio dopo l'installazione):
# systemctl abilita rsyslog.service Output: ln -s "/lib/systemd/system/rsyslog.service" "/etc/systemd/system/multi-user.target.wants/rsyslog.service"sysvinit è l'attuale sistema init predefinito di Debian ed è contrassegnato come pacchetto "Essential". Ciò significa che gli strumenti di gestione dei pacchetti si rifiuteranno di rimuovere o sostituire il pacchetto a meno che non siano obbligati a farlo. Inoltre, quando viene eseguito l'aggiornamento dist, i pacchetti principali verranno preferiti e reinstallati. Per maggiori informazioni vedere i capitoli "3.8 Pacchetti Essential" e "5.6.9 Essential"
Il pacchetto systemd-sysv contiene /sbin/init (come collegamento simbolico a /bin/systemd) e quindi è in conflitto con il pacchetto sysvinit.
Soluzione n. 1: non installare systemd-sysv , modificare la riga di grub (riga di comando del kernel) per aggiungere l'opzione "init=/bin/systemd". Per grub2 la soluzione permanente è questa (richiede l'esecuzione di update-grub per aggiornare /boot/grub/grub.cfg):
# $EDITOR /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT="quiet init=/bin/systemd"<--- Измените эту строку # update-grubSoluzione n. 2: installare il pacchetto systemd-sysv e "trattenerlo".
C'è un problema con il "flag Essential" che deve essere discusso con il manutentore di DebianPkg: Sysvinit .
Questo problema è solo un avvertimento e può essere ignorato, lo abbiamo su TODO (vedi sotto "Crea /etc/mtab un collegamento simbolico a /proc/self/mounts. Richiede un pacchetto util-linux più recente che memorizza le opzioni utente separatamente.") . ()
Il messaggio di errore completo in dmesg:
[ 5.784886] systemd: /etc/mtab non è un collegamento simbolico o non punta a /proc/self/mounts. Questo non è più supportato. Assicurati di sostituire questo file con un collegamento simbolico per evitare output mount(8) errati o fuorvianti.Soluzione alternativa: creare il collegamento simbolico richiesto:
# ln -sf /proc/self/mounts /etc/mtabGli script di inizializzazione SysV nfs-common / portmap / rpcbind hanno un ciclo di dipendenza che farà sì che systemd li elimini. Riceverai un messaggio di errore durante l'avvio come il seguente:
Pista ciclabile dell'ordine trovata su basic.target/start Ho camminato sulla pista ciclabile fino a sysinit.target/start Ho camminato sulla pista ciclabile fino a portmap.service/start Ho camminato sulla pista ciclabile fino a basic.target/start Interruzione del ciclo di ordinazione eliminando il lavoro portmap.serviceFino a quando gli script di inizializzazione portmap /nfs-common/rpcbind non saranno stati corretti, è possibile eliminare questi messaggi di errore disinstallando tali pacchetti o correggendo manualmente l'intestazione di inizializzazione LSB.
Questo problema è causato da portmap / nfs-common / rpcbind che installa collegamenti simbolici sia in rcS che in rc(2345), vedere
Un problema simile a quello sopra, ma con una risoluzione automatica peggiore:
Ciclo di ordinazione trovato su basic.target/start Ho camminato sulla pista ciclabile fino a sockets.target/start Ho camminato sulla pista ciclabile fino a dbus.socket/start Ho camminato sulla pista ciclabile fino a sysinit.target/start Ho camminato sulla pista ciclabile fino a nfs-common.service/ start Percorso il percorso ciclabile verso basic.target/start Interruzione del ciclo di ordinamento eliminando il lavoro dbus.socket/startSegnalazione di bug corrispondente:
Con la versione 12 o successiva è possibile utilizzare la funzione mount nativa (ovvero systemd) e fsck assicurandosi che sia attivata in /etc/systemd/system.conf.
# egrep "MountAuto|SwapAuto" /etc/systemd/system.conf Risultato: MountAuto=si SwapAuto=siIl pacchetto Debian abilita il montaggio nativo per impostazione predefinita a partire dalla versione 15-1.
Se usi Logical-Volume-Manager (LVM) assicurati di aggiornare il tuo pacchetto lvm2 all'ultima versione disponibile da unstable (>= 2.02.84-1) poiché contiene importanti correzioni riguardanti l'integrazione udev. Vedi per maggiori dettagli. Il pacchetto 19-1 lo fa già.
A volte è necessario indagare sul motivo per cui systemd si blocca all'avvio o al riavvio/spegnimento.
Soluzione n. 0: rimuovere "quiet" dalla riga di comando del kernel (la cosiddetta "cmdline" o "grub line")
Soluzione n. 1: aumentare la verbosità tramite cmdline: aggiungere "systemd.log_target=kmsg systemd.log_level=debug"
Ovviamente puoi avere una soluzione persistente "temporanea":
[ /etc/default/grub ] GRUB_CMDLINE_LINUX="systemd.log_target=kmsg systemd.log_level=debug"<--- Add here (by uncommenting you can easily switch to debug) # update-grubInoltre migliora la cmdline con "systemd.sysv_console=1" (0: disabilitato, 1: abilitato).
Soluzione n. 2: aumentare la verbosità tramite /etc/systemd/system.conf
LogLevel=debug<--- Uncomment this line and use "debug" (default: commented and "info") LogTarget=syslog-or-kmsg <--- Uncomment this line (default: commented) SysVConsole=yes <--- Uncomment this line (default: commented)SUGGERIMENTO: "man system" e "man systemd.conf" (Nota: il file è system.conf rispetto alla pagina man system*d*.conf)
SUGGERIMENTO: come controllare i parametri/opzioni della riga di comando del kernel?
# cat /proc/cmdlineNOTA su LogLevel (vedi systemd(1) e systemd.conf(5)):
"Imposta livello di log. Come argomento accetta un livello di log numerico o i noti nomi simbolici syslog(3) (in minuscolo): emerg, alert, crit, err, warning, Notice, info, debug."
SUGGERIMENTO: conserva una copia di /sbin/init dal pacchetto sysvinit in caso di salvataggio (così puoi usare init=/sbin/init.sysvinit nella riga cmd)!
# cp -av /sbin/init /sbin/init.sysvinit<--- Before installing systemd-sysv packageVedi anche https://fedoraproject.org/wiki/How_to_debug_Systemd_problems
Controlla il sistema di tracciamento dei bug a monte (abbreviato: BTS)
Bug contrassegnati dagli utenti in Debian BTS
Vorrei parlare del nuovo sistema systemd init, il cui passo sta inesorabilmente prendendo il sopravvento sulle popolari distribuzioni Linux. Questa offensiva spaventa molte persone e, per una buona ragione, recentemente la maggior parte delle discussioni su Internet sui sistemi Linux si riducono all'argomento: essere o non essere con systemd?
Vorrei iniziare da lontano. Da giovane, ha imparato il suo primo sistema operativo dal mondo open source: FreeBSD. Da principiante, non sapevo come realizzare correttamente i miei script di avvio per software non di sistema. Il software di sistema in FreeBSD è relativamente semplice. Hai bisogno di ssh? Specifica sshd_enable="YES" in /etc/rc.conf e ti verrà dato. E come eseguire le tue attività software all'avvio del sistema? La mia giovane mente in quel momento non trovava niente di meglio di creare uno script di avvio eseguibile in /usr/local/etc/rc.d/ così
Se lo script ha un bit eseguibile e gestisce i parametri di avvio e arresto, in linea di principio ha funzionato. Se scrivi correttamente gli script utilizzando rc.subr, puoi anche specificare quali servizi dovrebbero essere già in esecuzione prima di iniziare. La cosa più importante da capire è devi scrivere il codice shell per avviare il tuo programma. Questo non è né buono né cattivo. E' un dato di fatto e basta.
Dopo la prima conoscenza con Linux, ero davvero spaventato dal suo sistema di inizializzazione, che a quei tempi regnava all'infinito. 7 livelli di init hell da 0 a 6, dove il livello 4 non viene utilizzato. Gli script di avvio sono in un posto e con l'aiuto di collegamenti simbolici con nomi complicati in un altro posto stai cercando di spiegare al sistema Che cosa E Quando vuoi correre. Il nome di un collegamento simbolico non ha un carico semantico, ma funzionale! Il nome del collegamento simbolico inizia con K (ad esempio, K60crond) ed è un'istruzione per terminare il servizio. Nome c lettera S (ad esempio S40crond) - avvia il servizio. I numeri che seguono il nome del servizio determinano l'ordine in cui vengono eseguiti gli script. Non stai solo scrivendo il codice per avviare e interrompere nuovamente il servizio, ma stai anche facendo una capriola con i nomi dei collegamenti simbolici. Basta non parlarmi di utilità che rendono più semplice questo lavoro da scimmie. Non facilitano, ma nascondono l'imperfezione estetica.
E ora systemd. Non scrivi fogli di alcun codice. Non giochererai con il nome del file o con i nomi dei collegamenti simbolici ad esso. Tu semplicemente indichi Che cosa correre e tutto.
Nel tempo, la tua unità iniziale cambierà e il numero di linee in essa contenute aumenterà. Ma queste saranno linee che diranno al sistema systemd init COSA fare, NON COME farlo. Devo dire subito che non sono un esperto di systemd. È entrato nelle nostre vite relativamente di recente e la mia conoscenza seria è iniziata dopo essere passato da upstart a systemd nel mio Ubuntu 15.04 funzionante. Ma non essendo uno specialista, vorrei parlare del mio pensiero sui sistemi di inizializzazione.
Ho quindi implementato con i miei colleghi un sistema di virtualizzazione basato su ProxmoxVE e storage software Ceph. Abbiamo trasferito i nostri server fisici in un nuovo mondo virtuale. È diventato possibile creare facilmente server virtuali per altri reparti della mia azienda per le loro attività e progetti. E il primo server virtuale di questo tipo ha sollevato una questione fondamentale. Ricordando lo zoo passato di diverse versioni di FreeBSD e distribuzioni Linux di cui mi sono sbarazzato migrando tutti i sistemi su Ubuntu Server LTS, ho mantenuto tutti i diritti di root all'interno del sistema operativo guest. Utilizzando il meccanismo sudo, concedo i privilegi necessari alla persona che supervisionerà già il lavoro dei servizi all'interno del sistema operativo guest. E così una persona scolpisce uno script Python 3 in una cartella, che è il suo server web e la sua proprietà ala Zabbix alcune risorse locali. Una persona non pensa che, idealmente, per la sua sceneggiatura autoprodotta, sia necessario organizzare un avvio automatico sul server. Un paio di aggiornamenti e riavvii del server lo hanno mostrato chiaramente.
Come posso essere un amministratore? Non essendo l'autore dello script e non volendo interferire nel suo destino, nel sistema Init ho bisogno di creare il mio script wrapper su sh, in cui avvio e interrompo per me uno script Python di terze parti. Quindi dovrò creare i collegamenti simbolici necessari. Se domani questa persona mi dice che il suo script è cresciuto per archiviare i dati di monitoraggio nel database MySQL, allora devo organizzare il caricamento dello script del demone Python DOPO il servizio MySQL. In systemd, devi aggiungere la riga After al tuo file unit e specificare quella richiesta, ma in Init dubito che me la caverei con una riga di modifiche.
Sono già grato a systemd per il fatto che mi salva dalla programmazione in materia di avvio automatico. Come amministratore, mi piace systemd perché è l'unico che oggi ti aiuta con demoni complessi. Se in un caso semplice il demone funziona come un unico processo, tutto è davvero molto semplice. Per fermare il demone nel tuo script, dovresti scrivere qualcosa come kill $(cat /var/run/daemon.pid). Ma cosa succede se il demone funziona in uno scenario complesso, generando altri processi dai programmi consentiti? Quando interrompi il processo principale, potrebbe o meno arrestare tutti i suoi processi secondari. Systemd, con cgroup, è attualmente l'unico sistema init in grado di fermare un demone, non importa quante volte si biforca e non importa come tenta di sfuggire al tuo controllo con un doppio fork o un bombardamento di fork. Dopo un arresto fallito di un demone complesso, molto probabilmente lo ucciderai e poi cercherai nell'output di ps i processi zombie, cercando di ucciderli. Molto probabilmente, tutto finirà con il riavvio dell'intero server. E systemctl kill funziona in modo pulito e ironico.
Vorrei riassumere brevemente la mia opinione su systemd. Ringrazialo per facilità e semplicità di “intervento” nel sistema operativo, controllo assoluto del demone. E in futuro, avvicinandoci ai nostri e non ai nostri server, grazie per uniformità rappresentato da un sistema di inizializzazione: systemd.
Originale: Comprendere e utilizzare Systemd
Autore: Carla Schroder
Data di pubblicazione: 18 settembre 2014
Traduzione: N. Romodanov
Data di trasferimento: dicembre 2014
Che ci piaccia o no, systemd è arrivato, quindi dobbiamo sapere cosa farne.
Il valore di systemd è discutibile per diversi motivi: sostituisce ciò che molti utenti Linux pensano non abbia bisogno di essere sostituito, e tutte le smorfie degli sviluppatori systemd non conquistano i cuori e le menti. Al contrario, come evidenziato dal famoso blog LKML, in cui Linus Torvalds ha rimosso lo sviluppatore di systemd Kay Sievers dallo sviluppo del kernel Linux.
È interessante quando le personalità ti lasciano intralciare. Per quanto sia interessante inveire e rilasciare epiteti coloriti, ma questo non è il punto. Per molti anni il sistema Linux si è accontentato di SysVInit e BSD init. Poi ci sono state aggiunte ai gestori dei servizi, come comandi come service e chkconfig, che avrebbero dovuto facilitare la gestione dei servizi, ma per me era solo qualcosa che andava semplicemente imparato, che non ha facilitato il compito, ma ha solo reso più confusione.
Poi sono arrivati Upstart e systemd con tutti gli extra per renderlo compatibile con SysVInit.
Tutto questo è meraviglioso, ma era necessario riuscire a capirlo. Ora Upstart è andato in pensione a favore di systemd e Ubuntu ha tantissime librerie e strumenti per lavorare con systemd. Solo per divertimento, cerca in Ubuntu un elenco di file nel pacchetto systemd-services:
$ dpkg -L servizi-systemd
Per scoprire a cosa serve tutto questo, dai un'occhiata alle pagine man.
È sempre spaventoso quando gli sviluppatori iniziano a scherzare con i sottosistemi Linux chiave, perché possiamo semplicemente rimanere annegati in ciò che viene offerto. Se non ci piace un particolare programma, ambiente desktop o comando e ci sono diverse alternative, è facile usare qualcos'altro. Ma i sottosistemi principali si trovano nel profondo del kernel, in tutti i tipi di script di controllo, nonché nelle dipendenze, quindi sostituirli non è un compito banale.
La morale cambia, i computer inevitabilmente diventano più complessi, ma alla fine tutto funziona. E se non riusciamo a gestire da soli il corso degli eventi, siamo costretti ad accontentarci di ciò che abbiamo.
Red Hat è l'inventore e la mente dietro systemd, quindi le migliori distribuzioni per utilizzare questo strumento sono Red Hat Enterprise Linux, cloni di RHEL come CentOS e Scientific Linux e, naturalmente, la ben nota Fedora Linux, che offre sempre il massimo delle potenzialità. ultime, più grandi e sanguinanti novità.
I miei esempi provengono da un sistema CentOS 7.
Gli utenti esperti di RH possono ancora utilizzare i comandi service e chkconfig in RH 7, ma sono in ritardo da tempo a favore dei comandi systemd nativi. systemd si sta evolvendo e i comandi service e chkconfig non supportano i servizi systemd nativi.
Manca il nostro file preferito. Invece, abbiamo una directory / piena di collegamenti simbolici ai file nella directory. Gli script di inizializzazione si trovano nella directory; per poter avviare il servizio all'avvio del sistema, è necessario associarlo a. Quando abiliti un nuovo servizio, il comando systemctl lo fa per noi, come, ad esempio, nel seguente esempio per ClamAV:
# abilita systemctl [e-mail protetta] ln -s '/usr/lib/systemd/system/ [e-mail protetta]''/etc/systemd/system/multi-user.target.wants/ [e-mail protetta]’
Come fai a sapere il nome dello script di inizializzazione e da dove lo prendi? In Centos7 vengono aggiunti in pacchetti separati. Molti server (come Apache) non possono essere avviati con systemd e non dispongono di script di inizializzazione systemd. ClamAV fornisce script init sia per systemd che per SysVInit, quindi puoi installare questo pacchetto nel modo che preferisci:
$ yum cerca clamav clamav-server-sysvinit.noarch clamav-server-systemd.noarch
Allora cosa c'è dentro quegli script di inizializzazione? Possiamo vederlo da soli:
$ meno /usr/lib/systemd/system/ [e-mail protetta].include /lib/systemd/system/ [e-mail protetta] Descrizione = Demone scanner clamav generico WantedBy = multi-user.target
Ora puoi vedere come systemctl sa dove impostare il collegamento simbolico e questo script di inizializzazione specifica anche una dipendenza da un altro servizio - [e-mail protetta].
Il comando systemctl visualizza lo stato di tutti i servizi installati che dispongono di script init:
$ systemctl list-unit-files --type=service STATO FILE UNITÀ […] chronyd.service abilitato [e-mail protetta] statico [e-mail protetta] Disabilitato
Esistono tre stati possibili per un servizio: abilitato, disabilitato e statico. Lo stato on significa che esiste un collegamento simbolico nella directory .want. Lo stato disabilitato significa che non lo è. Lo stato statico significa che il servizio non è nella sezione dello script di inizializzazione, quindi non puoi né abilitarlo né disabilitarlo. I servizi statici dipendono solitamente da altri servizi e vengono gestiti automaticamente. Questo può essere visto nell'esempio di ClamAV, dal momento che il servizio [e-mail protetta] dipendente dal servizio [e-mail protetta] e funziona solo quando il servizio è in esecuzione [e-mail protetta].
Nessuno di questi stati indica se il servizio è in esecuzione. Questo può essere trovato con il comando ps o, per ulteriori informazioni, utilizzare il comando systemctl:
$ systemctl status bluetooth.service bluetooth.service - Servizio Bluetooth Caricato: caricato (/usr/lib.systemd/system/bluetooth.service; abilitato) Attivo: attivo (in esecuzione) da giovedì 14-09-2014 6:40:11 PDT PID principale: 4964 (bluetoothd) CGroup: /system.slice/bluetooth.service |_4964 /usr/bin/bluetoothd -n
Se sai come chiedere, il comando systemctl ti dirà tutto quello che vuoi sapere.
È probabile che utilizzerai solo i seguenti comandi:
# systemctl start # systemctl stop # systemctl restart # systemctl ricarica $ systemctl status # systemctl è-attivo $ systemctl list-units --type service --all
systemd ha 12 tipi di unità. .service sono servizi di sistema e quando esegui uno dei comandi precedenti, puoi omettere l'estensione .service perché systemd presuppone che sia un servizio a meno che non specifichi qualcos'altro. Altri tipi di unità:
È improbabile che tu abbia mai bisogno di fare qualcosa con queste altre unità, ma è bello sapere che esistono e a cosa servono. Puoi dargli un'occhiata con il comando:
$ systemctl list-units --type [nome unità]
Per qualche ragione, i sostenitori della sostituzione di SysVInit sembrano ossessionati dal tentativo di ridurre i tempi di avvio. I miei sistemi con sistema, come CentOS 7, non si avviano molto più velocemente di altri. In ogni caso, questa non è una cosa che mi preoccupa particolarmente, dato che nella maggior parte dei casi la velocità di download viene misurata solo fino alla comparsa della richiesta di accesso, e non in quanto tempo si avvierà il sistema e quando sarà completamente utilizzabile. Microsoft Windows è stato a lungo un sostenitore ingiusto in questo senso, poiché la richiesta di accesso appare abbastanza rapidamente e poi ci vogliono alcuni minuti in più per tutto il resto che praticamente non è necessario caricare ed eseguire. Mi sembra che quando appare un'altra stupida schermata con un'offerta per l'aggiornamento di Oracle Java, comincio a sentire che si tratta di un abuso nei miei confronti.
Tuttavia, per coloro che hanno a cuore il tempo di avvio, è possibile eseguire un comando per vedere quanto tempo impiega ogni programma e ogni servizio per avviarsi:
$ systemd-analyze colpa 5.728s firewalld.service 5.111s plymouth-quit-wait.service 4.046s tuned.service 3.550s account.daemon.service […]
… e decine di altri programmi e servizi. È tutto per oggi. systemd è già molto complesso; per saperne di più utilizzare altre fonti.
A volte è necessario riavviare o arrestare in remoto il sistema operativo Linux dalla riga di comando. Questo può essere fatto in vari modi, li considereremo.
Commento. Tutti i seguenti comandi devono essere eseguiti come root.
Utilizza i comandi "su -" o "sudo" per cambiare utente o ottenere i privilegi di root.
Il comando shutdown è il comando principale per controllare lo spegnimento o il riavvio di un sistema Linux.
# spegni -r adesso
Quando si utilizza il comando shutdown, è possibile impostare il riavvio ad un orario specifico con l'output di messaggi informativi.
# shutdown -r 10:30 "REBOOT SYSTEM"
Il comando reboot esegue tutte le operazioni necessarie per arrestare il sistema, questo comando può essere richiamato con il comando shutdown -r, ma può essere utilizzato separatamente. Questo comando registra il tempo di arresto del sistema, interrompe i processi non completati, esegue la chiamata di sistema di sincronizzazione, attende il completamento della scrittura su disco e solo successivamente arresta il kernel e riavvia il sistema Linux.
# riavviare
Con questo comando puoi dire al demone init di andare ad un certo runlevel, ovvero il numero 7 indica che devi andare al 7° livello (riavvio). Il comando telinit non supporta messaggi di pausa o di avviso. Tipicamente utilizzato quando si controllano le modifiche apportate al file inittab.
#telinit7
# shutdown -h adesso
fermare la squadra.
Il comando è identico al comando reboot nelle sue azioni, la differenza è che il comando halt spegne il sistema.
#fermarsi
Il comando poweroff è identico al comando halt, tranne per il fatto che dopo l'arresto del sistema, viene inviata una richiesta speciale al sistema di gestione dell'alimentazione per spegnere l'alimentazione, consentendo lo spegnimento remoto dei sistemi.
# spegni
Identico al comando telinit 7, tranne che va al livello 0, il che significa che il sistema è fermo.
#telinit0
Questo è tutto, la revisione dei modi principali per spegnere e riavviare i sistemi Linux dalla riga di comando è completata.
Come abilitare il programma caricamento automatico o, al contrario, rimuovere dall'avvio in CentOS?
È possibile visualizzare l'elenco di caricamento automatico utilizzando il comando:
# /sbin/chkconfig --list
in cima 0:off 1:off 2:on 3:on 4:on 5:on 6:off crond 0:off 1:off 2:on 3:on 4:on 5:on 6:off tazze 0:off 1: off 2:on 3:on 4:on 5:on 6:off httpd 0:off 1:off 2:off 3:on 4:off 5:off 6:off ip6tables 0:off 1:off 2:on 3: on 4:on 5:on 6:off iptables 0:off 1:off 2:off 3:off 4:off 5:off 6:off
Vengono visualizzati 7 livelli di esecuzione, indicati dai numeri da 0 a 6.
Livello 0- arresto del sistema (halt) - il sistema deve essere arrestato;
Livello 1- modalità operativa per utente singolo: il sistema inizializza un minimo di servizi e fornisce a un singolo utente (solitamente un superutente) una riga di comando senza autenticazione.
In genere, questa modalità viene utilizzata per il ripristino del sistema;
Livello 2- modalità multiutente: gli utenti possono lavorare su diversi terminali, effettuare il login con il processo di autenticazione;
Livello 3- modalità di rete multiutente: a differenza del livello precedente, la rete viene configurata e vengono lanciati vari servizi di rete;
Livello 4- non ha un'interpretazione standard e praticamente non viene utilizzata;
Livello 5- avvio del sottosistema grafico - rispetto al livello 3 viene avviato anche il sottosistema grafico X11 e il sistema è loggato già in modalità grafica;
Livello 6- riavvio del sistema: quando questa modalità è abilitata, tutti i programmi in esecuzione vengono arrestati e viene eseguito un riavvio.
Fondamentalmente vengono utilizzati i livelli 2, 3, 5.
Puoi aggiungere un processo all'avvio con il comando:
#chkconfig -add nginx
che attiva automaticamente i livelli 2, 3, 4, 5. È inoltre possibile specificare i livelli richiesti:
# chkconfig --level 345 nginx attivo
Come rimuovere un programma dall'avvio?
#chkconfig --del nginx
Come aggiungere un servizio all'avvio?
Data: 26-10-2012
Un processo è un programma in esecuzione su un sistema.
1) Nella maggior parte dei casi, per studiare i processi in Linux, viene utilizzato il comando “ps”, che può essere eseguito sia in modalità testo che avere una shell grafica.
#ps ax: visualizza informazioni complete sui processi
COMANDO TEMPO STAT PID TTY
1? Ss 0:03 /sbin/init
Per sempre, probabilmente avremo bisogno di questo comando per monitorare i processi ed eliminare quelli bloccati, poiché premendo la combinazione di tasti ctrl+alt+canc entriamo nel task manager di Windows e possiamo interrompere il processo bloccato.
Può essere utilizzato insieme a grep per trovare rapidamente il processo di cui abbiamo bisogno.
# ps ascia | grepppt
2036 punti/0 S+ 0:00 grep pptp
17676? Ss 0:00 /usr/sbin/pptpd
Qui ci ha trovato la nostra ricerca e il processo stesso con il numero 17676
Oppure possiamo utilizzare un'utilità di ricerca di processi già pronta
# pgrep -l pp
2111pppt
2) Il comando ci aiuterà a terminare il processo:
# kill 17676 - che ne interromperà forzatamente l'esecuzione
# killall pptpd - termina un processo in base al nome
3) Se hai bisogno di una visualizzazione ad albero dei processi, l'utilità verrà in soccorso:
#pstree
init -acpid
--apache2-5*
-atd
—cron
-gg
—Vongole fresche
—6*
--klogd
—miniserv.pl
--named-3*[(nome)]
-nmbd
--pptpd
--slapd-2*[(slapd)]
-smbd -smbd
--sshd-sshd-bash-pstree
--syslogd
—udevd
--xinetd
Qui è quindi visibile la dipendenza reciproca dei processi sotto forma di albero.
E puoi vedere una dipendenza più dettagliata se aggiungi l'opzione -a
#pstree -a
4) Un'altra utilità molto utile.
# in alto: visualizza i processi in tempo reale
Compiti: 52 in totale, 1 che corre, 51 che dorme, 0 fermato, 0 zombi
CPU: 0,3%us, 0,7%sy, 0,0%ni, 99,0%id, 0,0%wa, 0,0%hi, 0,0%si, 0,0%st
Mem: 247780k totali, 242104k utilizzati, 5676k gratuiti, 64152k buffer
Scambio: 465844k totali, 184k usati, 465660k gratuiti, 127556k memorizzati nella cache
PID UTENTE PR NI VIRT SHR S %CPU RES %MEM TIME+ COMANDO
2094 radice 18 0 2304 852 R 0,3 1064 0,4 0:01,05 superiore
5549 syslog 15 0 1932 528 S 0.3 680 0.3 49:43.08 syslogd
5571 radice 15 0 1868 440 S 0,3 532 0,2 72:10,96 gg
1 radice 15 0 2840 540 S 0.0 1684 0.7 0:03.12 init
2 root 12 -5 0 0 S 0.0 0 0.0 0:00.00 kthreadd
Visualizza la memoria utilizzata e il processore, i processi sospesi e di lavoro.
Da qui puoi modificare la priorità del processo o eliminarlo. Visualizzare lo stato del processo (inattivo, interrotto, sospeso, ecc.)
# gtop - Può essere utilizzato in modalità grafica.
Altri comandi Linux
In modo che diventi chiaro perché e come è possibile utilizzare i comandi in Linux. Dimostrerò un piccolo script bash.
Questo script controlla se esiste un processo con il nome smb e se non esiste, si avvia.
grep -v grep è necessario per escludere il processo di ricerca smb stesso
#!/bin/bash
ps ascia | grep -v grep | grep smb
se[$? -ne 0]
Poi
/etc/init.d/smb avvia
altro
echo "demone in esecuzione" > /dev/null
fi
Plutonit.ru - Amministrazione, configurazione Linux e Windows 2009-2018
Qui mostrerò come scrivere initnik per avviare automaticamente qualsiasi demone in un sistema systemd.
Systemd tratta i file di unità come file di configurazione. È come un file .conf per upstart o script init per initd. I file unit possono anche descrivere altre entità di sistema, ma in questo caso ci interessano come configurazione per l'avvio automatico del servizio. Su Ubuntu 16.04 si trovano in /etc/systemd/ . Scriviamo il nostro file unitario.
Diciamo che abbiamo un programma che vogliamo eseguire come demone. Qui ho scritto come creare un bot di Telegram. Ho un file eseguibile che viene eseguito e si blocca in attesa di messaggi. Ora voglio che venga avviato come demone all'avvio del sistema.
Creiamo un file del genere:
Descrizione = TelegramBotMonitoring Dopo = network.target Tipo = semplice ExecStart = /usr/local/bin/telegram-site-monitoring -telegrambottoken 397______:___________WRDsIU -chatid -14____640 Riavvia = sempre WantedBy = multiutente.target
e inseriscilo in /etc/systemd/system/telegram-bot.service
La configurazione è simile a un normale file ini:
Dopo: lancia questa unità contro determinati demoni o bersagli (il bersaglio è un insieme di unità). Network.target è specificato qui, il che significa che il demone verrà avviato dopo l'attivazione delle interfacce di rete.
Tipo: il tipo di avvio del demone. Il più comunemente usato è semplice, biforcuto o one-shot. semplice: il demone si avvia e attende sulla console e non si biforca. biforcazione: il demone si avvia, quindi si biforca e termina il processo genitore. Molti programmi vengono avviati in questo modo per passare alla modalità background. Ad esempio, nginx si avvia in questo modo. one-shot: utilizzato per eseguire script che vengono eseguiti, eseguiti e terminati. Nel mio caso, questo non è uno script e il programma non esegue il fork, quindi il tipo è semplice
ExecStart è il comando per avviare il demone.
Riavvia: riavvia il demone se termina/si blocca. Con sempre systemd riavvierà il demone indipendentemente dal motivo per cui è terminato. È possibile specificare on-failure , quindi verrà riavviato se il demone è uscito con un codice di ritorno diverso da zero o è stato terminato da un segnale (kill DAEMONPID)
WantedBy: diciamo di eseguire questo demone quando il sistema si avvia in modalità multiutente
# systemctl demone-ricarica
E aggiungi l'unità creata al caricamento automatico:
# systemctl abilita telegram-bot.service Creato collegamento simbolico da /etc/systemd/system/multi-user.target.wants/telegram-bot.service a /etc/systemd/system/telegram-bot.service.```
Tutto. Il servizio è stato aggiunto all'avvio, ma non è stato ancora lanciato. Corriamo:
# systemctl avvia telegram-bot
Lanciato:
# systemctl stato telegramma-bot ● telegram.service - TelegramBotMonitoring Caricato: caricato (/etc/systemd/system/telegram-bot.service; abilitato; preimpostazione del fornitore: abilitato) Attivo: attivo (in funzione) da gio 2017-07-13 17:10:19 MSK; 5 secondi fa PID principale: 1825 (telegram-site-m) Attività: 4 Memoria: 4,4 MB CPU: 39 ms CGroup: /system.slice/telegram-bot.service └─1825 /usr/local/bin/telegram-site-monitoring -telegrambottoken 3972____:__________Gi03WRDsIU -chatid -14____40 13 luglio 17:10:19 Ubuntu Systemd: avviato TelegramBotMonitoring. 13 luglio 17:10:19 monitoraggio del sito di Ubuntu Telegram: 13/07/2017 17:10:19 () 13 luglio 17:10:19 Ubuntu Telegram-Site-Monitoring: 2017/07/13 17:10:19 Autorizzato sull'account 13 luglio 17:10:19 Ubuntu Telegram-Site-Monitoring: 2017/07/13 17:10:19 File di configurazione: config.json 13 luglio 17:10:19 monitoraggio del sito di Ubuntu Telegram: 13/07/2017 17:10:19 ChatID: 13 luglio 17:10:19 Ubuntu Telegram-Site-Monitoring: 2017/07/13 17:10:19 Avvio del thread di monitoraggio
Foglio informativo con comandi per la gestione dei demoni systemd -
La maggior parte delle distribuzioni Linux utilizza systemd come gestore di sistema e servizi.
systemctl è il comando principale per la gestione dei servizi in systemd.
In questo articolo ti mostrerò come creare un file di servizio in systemd che ti permetterà di controllare il tuo servizio utilizzando il comando systemctl, come riavviare systemd senza riavviare in modo che rilegga i file unit e come attivare il tuo nuovo servizio.
Fornirò anche una descrizione delle opzioni più importanti utilizzate nei file di servizio con esempi di file di servizio reali.
Crea un file di servizio /etc/systemd/system/foo-daemon.service (sostituisci foo-daemon con il nome del tuo servizio):
$ sudo touch /etc/systemd/system/foo-daemon.service $ sudo chmod 664 /etc/systemd/system/foo-daemon.service
Apri il file foo-daemon.service e annota le impostazioni minime che ti permetteranno di controllare il servizio utilizzando systemctl:
Descrizione=Foo ExecStart=/usr/sbin/foo-daemon WantedBy=multi-user.target
Il percorso verso il demone: Se non conosci il percorso del demone, prova which foo-daemon .
Dopo aver creato un nuovo file di servizio, è necessario riavviare systemd:
$ sudo systemctl daemon-reload
Ora puoi eseguire start, stop, restart e verificare lo stato del servizio:
$ sudo systemctl start foo-daemon $ sudo systemctl stop foo-daemon $ sudo systemctl restart foo-daemon $ systemctl status foo-daemon
Per aggiungere un servizio all'avvio è necessario attivarlo:
$ sudo systemctl abilita foo-daemon
Per controllare i log del servizio, eseguire:
$ journalctl -u foo-daemon
Gli elementi generali di configurazione del servizio sono configurati nelle sezioni e
Nella sezione si configurano i parametri di configurazione di un servizio specifico.
| Opzione | Descrizione |
|---|---|
| Descrizione | Breve descrizione dell'unità. |
| Documentazione | Elenco dei collegamenti alla documentazione. |
| Prima dopo | Ordine di lancio dell'unità. |
| Richiede | Se questo servizio è attivato, verranno attivate anche le unità qui elencate. Se una delle unità elencate si ferma o si blocca, anche quel servizio verrà interrotto. |
| Vuole | Installa dipendenze più deboli di Requires . Se una delle unità elencate non si avvia correttamente, ciò non influirà sull'avvio di questo servizio. Questo è il modo consigliato per stabilire le dipendenze. |
| Conflitti | Se un determinato servizio risulta essere in conflitto con un'altra unità, l'avvio di quest'ultima interromperà quel servizio e viceversa. |
Elenco di tutte le opzioni della sezione:
$ man systemd.unità
Elenco di tutte le opzioni della sezione:
$ man systemd.unità
| Opzione | Descrizione |
|---|---|
| tipo | Imposta il tipo di avvio del processo. Uno di: semplice (impostazione predefinita): avvia immediatamente il servizio. Si presuppone che il processo principale del servizio sia specificato in ExecStart . il fork considera il servizio in esecuzione dopo che il processo genitore ha creato un processo figlio e si è terminato. oneshot - Simile a simple , ma è previsto che il processo termini prima che systemd inizi a monitorare gli stati delle unità (utile per gli script che eseguono un lavoro una tantum e escono). Potresti anche voler utilizzare RemainAfterExit=yes per dire a systemd di continuare a considerare il servizio attivo dopo la chiusura del processo. dbus - Simile a simple , ma considera il servizio avviato dopo che il processo principale ha ottenuto un nome sul D-Bus. notify - Simile a simple , ma considera il servizio avviato dopo aver inviato un segnale speciale a systemd. idle - Simile a simple , ma l'avvio effettivo dell'eseguibile del servizio viene ritardato fino al completamento di tutte le attività. |
| ExecStart | Comandi insieme agli argomenti che verranno eseguiti all'avvio del servizio. L'opzione Type=oneshot consente di specificare più comandi da eseguire in sequenza. Le opzioni ExecStartPre e ExecStartPost possono specificare comandi aggiuntivi da eseguire prima o dopo ExecStart . |
| ExecStop | Comandi da eseguire per arrestare un servizio avviato con ExecStart . |
| ExecReload | Comandi da eseguire per dire al servizio di rileggere i file di configurazione. |
| Ricomincia | Se questa opzione è abilitata, il servizio verrà riavviato se il processo viene terminato o viene raggiunto il timeout, tranne quando il servizio viene normalmente interrotto utilizzando il comando systemctl stop |
| Rimani dopo l'uscita | Se impostato su True il servizio verrà considerato in esecuzione anche se il processo stesso viene terminato. Utile con Type=oneshot . Il valore predefinito è falso . |
Elenco di tutte le opzioni della sezione:
$man systemd.service
