Differenza tra i comandi systemctl e service

systemdci fornisce la systemctlsuite di comandi utilizzata principalmente per consentire l'avvio dei servizi all'avvio. Possiamo anche avviare, arrestare, ricaricare, riavviare e controllare lo stato dei servizi con l'aiuto di systemctl.

Possiamo fare, ad esempio sudo systemctl enable service_name, e service_namesi avvierà automaticamente all'avvio. Possiamo anche disabilitare i servizi per non avviarli all'avvio.

L'unica differenza tra i comandi servicee systemctlche è systemctlpossibile utilizzare per abilitare l'avvio dei servizi in fase di esecuzione? Possiamo usare systemctlsu qualsiasi servizio? Quali altre differenze significative ci sono?

Il servicecomando è uno script wrapper che consente agli amministratori di sistema di avviare, arrestare e controllare lo stato dei servizi senza preoccuparsi troppo dell'effettivo sistema init utilizzato. Prima dell'introduzione di systemd, era un wrapper per gli /etc/init.dscript e il initctlcomando di Upstart , e ora è un wrapper per questi due e systemctl pure.

Usa la fonte, Luke!

Verifica Upstart:

# Operate against system upstart, not session
unset UPSTART_SESSION
if [ -r "/etc/init/${SERVICE}.conf" ] && which initctl >/dev/null \
   && initctl version 2>/dev/null | grep -q upstart \
   && initctl status ${SERVICE} 2>/dev/null 1>/dev/null
then
   # Upstart configuration exists for this job and we're running on upstart

Se non funziona, cerca systemd:

if [ -d /run/systemd/system ]; then
   is_systemd=1
fi

...

# When this machine is running systemd, standard service calls are turned into
# systemctl calls.
if [ -n "$is_systemd" ]
then

E se anche questo fallisce, ricade negli /etc/init.dscript di System V :

run_via_sysvinit() {
   # Otherwise, use the traditional sysvinit
   if [ -x "${SERVICEDIR}/${SERVICE}" ]; then
      exec env -i LANG="$LANG" LANGUAGE="$LANGUAGE" LC_CTYPE="$LC_CTYPE" LC_NUMERIC="$LC_NUMERIC" LC_TIME="$LC_TIME" LC_COLLATE="$LC_COLLATE" LC_MONETARY="$LC_MONETARY" LC_MESSAGES="$LC_MESSAGES" LC_PAPER="$LC_PAPER" LC_NAME="$LC_NAME" LC_ADDRESS="$LC_ADDRESS" LC_TELEPHONE="$LC_TELEPHONE" LC_MEASUREMENT="$LC_MEASUREMENT" LC_IDENTIFICATION="$LC_IDENTIFICATION" LC_ALL="$LC_ALL" PATH="$PATH" TERM="$TERM" "$SERVICEDIR/$SERVICE" ${ACTION} ${OPTIONS}
   else
      echo "${SERVICE}: unrecognized service" >&2
      exit 1
   fi
}

...
run_via_sysvinit

Poiché il servicecomando è un wrapper abbastanza semplice, supporta solo un sottoinsieme limitato di azioni rispetto a quello che potrebbe fornire il vero sistema init.

Per la portabilità su varie versioni di Ubuntu, gli utenti possono utilizzare in modo affidabile il servicecomando per avviare, arrestare, riavviare o esaminare lo stato di un servizio. Per le attività più complesso, tuttavia, il comando effettivo in uso, sia che initctlo systemctlo /etc/init.dscript potrebbe essere utilizzato direttamente.

Inoltre, essendo un wrapper, servicein alcuni casi lo script fa anche più di quanto potrebbe fare il comando diretto equivalente. Per esempio:

• Esegue sempre gli /etc/init.dscript in un ambiente pulito. (Nota la lunga env chiamata di comando nella run_via_sysvinitfunzione sopra.)
• restartEsegue il mapping sui sistemi Upstart su una combinazione di stop/ start, poiché un semplice initctl restarterrore si spegne se il servizio non è già in esecuzione.

• Arresta i socket quando interrompe i servizi di sistema che hanno socket associati:

  case "${ACTION}" in
    restart|status)
       exec systemctl $sctl_args ${ACTION} ${UNIT}
    ;;
    start|stop)
       # Follow the principle of least surprise for SysV people:
       # When running "service foo stop" and foo happens to be a service that
       # has one or more .socket files, we also stop the .socket units.
       # Users who need more control will use systemctl directly.

I servizi di avvio sono stati abilitati direttamente nel file di configurazione del servizio (o disabilitati tramite override) e gli script di System V sono stati abilitati o disabilitati con il update-rc.dcomando (che gestiva i collegamenti simbolici nelle /etc/rc*directory), quindi il servicecomando non è mai stato coinvolto nell'abilitazione o disabilitazione dei servizi all'avvio .

• systemd è retrocompatibile con SysV.
• carica i servizi parallelamente all'avvio
• fornisce l'attivazione su richiesta di un servizio
• è basato sulla dipendenza
• e molto altro immagino ...

Ci sono molto di più di quello che hai menzionato di cui systemctlè capace.

systemd funziona con le unità, ci sono diversi tipi di unità: obiettivi, servizi, socket, ecc. gli obiettivi sono lo stesso concetto dei runlevel, sono un insieme di unità.

È possibile utilizzare systemctlper impostare o ottenere la destinazione di sistema predefinita.

systemctl get-default

Puoi andare in altri obiettivi:

systemctl isolate multiuser.target

Altri obiettivi sono: multiutente, grafico, recue, di emergenza, riavvio, spegnimento.

Come hai detto, puoi utilizzare systemctlper gestire i servizi, alcuni degli altri comandi relativi alla gestione dei servizi di cui sono a conoscenza sono:

# Restarts a service only if it is running.
systemctl try-restart name.service

# Reloads configuration if it's possible.
systemctl reload name.service

# try to reload but if it's not possible restarts the service
systemctl reload-or-restart name.service

Puoi usarlo per scoprire lo stato di un servizio:

systemctl status name.service

systemctl is-active name.service # running
systemctl is-enabled name.service # will be activated when booting
systemctl is-failed name.service # failed to load

Puoi mascherare o smascherare un servizio:

systemctl mask name.service
systemctl unmask name.service

Quando mascherate un servizio a cui sarà collegato /dev/null, quindi manualmente o automaticamente altri servizi non possono attivarlo / abilitarlo. (dovresti prima smascherarlo).

Un altro uso di systemctl è di elencare le unità:

systemctl list-units

Che elenca tutti i tipi di unità, caricate e attive.

Elenco delle unità di servizio:

systemctl list-units --type=service

Oppure per elencare tutte le unità disponibili non solo quelle caricate e attivate:

systemctl list-unit-files

È possibile creare alias o persino controllare macchine remote

systemctl --host ravexina@192.168.56.4 list-units

D'altra parte servicefa quello che deve fare, gestire i servizi e non avere nulla a che fare con gli affari degli altri;)