Workstation online OnWorks Linux e Windows

Logo

Hosting online gratuito per workstation

<Precedenti | Contenuti | Succ.>

5.4. Gestione dei servizi‌‌


Kali usa systemd come il suo sistema di inizializzazione, che non è solo responsabile della sequenza di avvio, ma agisce anche in modo permanente come gestore di servizi completo, avviando e monitorando i servizi.

systemd può essere interrogato e controllato con systemctl. Senza alcun argomento, esegue il systemctl list-unità comando, che emette un elenco degli attivi unità. Se corri stato systemctl, l'output mostra una panoramica gerarchica dei servizi in esecuzione. Confrontando entrambi gli output, si vede immediatamente che ci sono più tipi di unità e che i servizi sono solo uno tra questi.

Ogni servizio è rappresentato da a unità di servizio, che è descritto da un file di servizio solitamente spedito in

/lib/systemd/system/ (o /run/systemd/system/, o /etc/systemd/system/; sono elencati in ordine crescente di importanza e vince l'ultimo). Ciascuno è eventualmente modificato da altri Nome di ServizioFile .service.d/*.conf nello stesso insieme di directory. Questi file di unità sono file di testo semplice il cui formato è ispirato ai noti file "*.ini" di Microsoft Windows, con chiave

= APPREZZIAMO coppie raggruppate tra [pagina] intestazioni. Qui vediamo un file di servizio di esempio per /lib/systemd/system/ssh.service:


[Unità]

Description=Server OpenBSD Secure Shell Dopo=network.target auditd.service ConditionPathExists=!/etc/ssh/sshd_not_to_be_run


[Servizio]

EnvironmentFile=-/etc/default/ssh ExecStart=/usr/sbin/sshd -D $SSHD_OPTS ExecReload=/bin/kill -HUP $MAINPID KillMode=processo

Restart=in caso di errore RestartPreventExitStatus=255 Type=notify


[Installare]

WantedBy=multi-utente.target Alias=sshd.service

[Unità]

Description=Server OpenBSD Secure Shell Dopo=network.target auditd.service ConditionPathExists=!/etc/ssh/sshd_not_to_be_run


[Servizio]

EnvironmentFile=-/etc/default/ssh ExecStart=/usr/sbin/sshd -D $SSHD_OPTS ExecReload=/bin/kill -HUP $MAINPID KillMode=processo

Restart=in caso di errore RestartPreventExitStatus=255 Type=notify


[Installare]

WantedBy=multi-utente.target Alias=sshd.service


Le unità target sono un'altra parte del design di systemd. Rappresentano uno stato desiderato che si vuole raggiungere in termini di unità attivate (che significa un servizio in esecuzione nel caso di unità di servizio). Esistono principalmente come un modo per raggruppare le dipendenze da altre unità. Quando il sistema si avvia, abilita le unità necessarie per raggiungere il obiettivo.predefinito (che è un collegamento simbolico a grafico.target, e che a sua volta dipende da multiutente.target). Quindi tutte le dipendenze di tali obiettivi vengono attivate durante l'avvio.

Tali dipendenze sono espresse con il Vorrei direttiva sull'unità di destinazione. Ma non è necessario modificare l'unità di destinazione per aggiungere nuove dipendenze, è anche possibile creare un collegamento simbolico che punti al

unità dipendente in /etc/systemd/system/nome-obiettivo.obiettivo.vuole/ directory. E questo è esattamente ciò che abilitazione systemctl pippo.servizio fa. Quando abiliti un servizio, dici a systemd di aggiungere una dipendenza dalle destinazioni elencate in ricercato da iscrizione del [Installare] sezione del file dell'unità di servizio. Al contrario, systemctl disable pippo.servizio elimina lo stesso collegamento simbolico e quindi la dipendenza.

I enable ed disable i comandi non cambiano nulla per quanto riguarda lo stato attuale dei servizi. Influenzano solo ciò che accadrà al prossimo avvio. Se vuoi eseguire il servizio immediatamente, dovresti eseguire avvio del sistemactl pippo.servizio. Al contrario, puoi fermarlo con sistemactl stop pippo.servizio. Puoi anche controllare lo stato attuale di un servizio con stato systemctl pippo.servizio, che include utilmente le ultime righe del registro associato. Dopo aver modificato la configurazione di un servizio, potresti volerlo ricaricare o riavviarlo: queste operazioni si fanno con systemctl ricarica pippo.servizio ed riavvio systemctl pippo. servizio rispettivamente.


Immagine

# stato di systemctl postgresql

● postgresql.service - RDBMS PostgreSQL

Caricato: caricato (/lib/systemd/system/postgresql.service; disabilitato; preset del fornitore:

Disabilitato)

Attivo: inattivo (morto)

# ls -al /etc/systemd/system/multi-user.target.wants/postgresql.service

ls: impossibile accedere a '/etc/systemd/system/multi-user.target.wants/postgresql.service': No

tale file o directory

# systemctl abilita postgresql

[...]

# ls -al /etc/systemd/system/multi-user.target.wants/postgresql.service

lrwxrwxrwx 1 root root 38 21 aprile 16:21 /etc/systemd/system/multi-user.target.wants/

postgresql.service -> /lib/systemd/system/postgresql.service

# stato di systemctl postgresql

● postgresql.service - RDBMS PostgreSQL

Caricato: caricato (/lib/systemd/system/postgresql.service; abilitato; preset del fornitore:

Disabilitato)

Attivo: inattivo (morto)

# systemctl avvia postgresql

# stato di systemctl postgresql

● postgresql.service - RDBMS PostgreSQL

Caricato: caricato (/lib/systemd/system/postgresql.service; abilitato; preset del fornitore:

Disabilitato)

Attivo: attivo (uscito) da Thu 2016-04-21 16:22:29 EDT; 2 secondi fa Processo: 6355 ExecStart=/bin/true (code=exited, status=0/SUCCESS)

PID principale: 6355 (codice=uscita, stato=0/SUCCESSO)


Apr 21 16:22:29 kali-rolling systemd[1]: avvio di PostgreSQL RDBMS... Apr 21 16:22:29 kali-rolling systemd[1]: avvio di PostgreSQL RDBMS.

Il miglior sistema operativo cloud computing su OnWorks: