Perché un server Ubuntu ha graphical.target come destinazione predefinita systemd?

Sono stato un utente Ubuntu per un po ', e al lavoro abbiamo molti server Ubuntu VM , tutti eseguiti Ubuntu 14.04 LTSper distribuire le nostre applicazioni web, database e altri strumenti.

Attualmente sto studiando Ubuntu 16.04 LTS, desktop e server, per poter aggiornare i nostri server di produzione nel prossimo futuro senza causare problemi.

Da Ubuntu 15.04, inite upstartsono stato sostituito da Systemd, quindi sto studiando anche Systemd.

Ho notato che il mio computer di sviluppo con Ubuntu 16.04 Desktop edition ha graphical.targetcome destinazione predefinita systemd, che è logico.

Ma poi ho notato che il server di test che esegue Ubuntu 16.04 Server edition utilizza anche graphical.targetcome destinazione systemd predefinita.

$ systemctl get-default
graphical.target

Quindi sono confuso. Il server non ha alcun livello grafico, quindi com'è la destinazione predefinita graphical.target?

Modifica # 0

Come ha suggerito Rinzwind nei commenti, ho guardato l'obiettivo per vedere se è attivo o no ...

e la risposta è SÌ:

admin@server1604:~$ systemctl get-default
graphical.target

admin@server1604:~$ systemctl status graphical.target
● graphical.target - Graphical Interface
Loaded: loaded (/lib/systemd/system/graphical.target; static; vendor preset: enabled)
Active: active since jeu. 2016-10-13 16:03:18 CEST; 46min ago
Docs: man:systemd.special(7)

oct. 13 16:03:18 fdea systemd[1]: Reached target Graphical Interface.

Quindi sono un po 'più confuso.

Modifica n. 1

La risposta di Mark Stosberg sottolinea il fatto che display-manager.servicefa parte dell'albero delle dipendenze del graphical.targetproprio server 16.04 e aggiunge che nessun gestore della visualizzazione è installato o in esecuzione sulla sua macchina. Ho visto anche quello, e in effetti sul mio server questa dipendenza è lì:

admin@server1604:~$ systemctl list-dependencies graphical.target 
graphical.target
● ├─accounts-daemon.service
● ├─apache2.service
● ├─apport.service
● ├─display-manager.service

...

E questo bersaglio ha un cerchio rosso sulla sinistra, dove la maggior parte delle altre dipendenze ha un cerchio verde.

E questa volta il risultato è coerente:

admin@server16.04:~$ systemctl status display-manager.service 
● display-manager.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

Ma ecco un'altra cosa strana: sulla mia edizione desktop, display-manager.servicenon c'è una dipendenza di graphical.target:

me@desktop16.04:~ $ systemctl list-dependencies graphical.target | grep display
me@desktop16.04:~ $ 

Ma ho anche trovato un'alternativa perché corro Ubuntu-Gnomecon lightdmla sostituzione del window manager di default:

me@desktop16.04:~ $ systemctl list-dependencies graphical.target | grep lightdm
● ├─lightdm.service

Nonostante il nome del target, non c'è nulla di grafico in esecuzione su Ubuntu Server 16.04. Puoi usare questo comando per controllarlo e confrontarlo con il tuo desktop se ti piace:

systemctl list-dependencies graphical.target 

Sul mio server Ubuntu 16.04, vedo che le destinazioni dipendono da "display-manager.service", ma nessun display manager è installato o in esecuzione.

Mi aspetto che i server Ubuntu siano impostati in questo modo per un certo tipo di coerenza, anche se sono d'accordo che sia confuso.

Dal manuale di redhat :

Ad esempio, l'unità graphical.target, che viene utilizzata per avviare una sessione grafica, avvia servizi di sistema come GNOME Display Manager (gdm.service) o Accounts Service (accounts-daemon.service) e attiva anche l'utente multiutente. unità bersaglio. Allo stesso modo, l'unità multi-user.target avvia altri servizi di sistema essenziali come NetworkManager (NetworkManager.service) o D-Bus (dbus.service) e attiva un'altra unità target denominata basic.target.

Quindi non è sbagliato che sia impostato poiché non attiva il display manager quando il servizio che gestisce il servizio display non è impostato.

Per un server è possibile impostarlo su multi-user.targetma non è necessario. Sembra che finirai sul runlevel 4 se lo fai e runlevel 5 quando non lo fai.

Runlevel    Target Units    Description
0   runlevel0.target, poweroff.target   Shut down and power off the system.
1   runlevel1.target, rescue.target     Set up a rescue shell.
2   runlevel2.target, multi-user.target     Set up a non-graphical multi-user system.
3   runlevel3.target, multi-user.target     Set up a non-graphical multi-user system.
4   runlevel4.target, multi-user.target     Set up a non-graphical multi-user system.
5   runlevel5.target, graphical.target  Set up a graphical multi-user system.
6   runlevel6.target, reboot.target     Shut down and reboot the system. 

Ispezionando più in dettaglio il primo livello della dipendenza dell'albero del bersaglio graphical.target:

admin@server1604:~$ systemctl list-dependencies graphical.target 
graphical.target
● ├─accounts-daemon.service
● ├─apache2.service
● ├─apport.service
● ├─display-manager.service              (disabled)
● ├─grub-common.service
● ├─irqbalance.service
● ├─mdadm.service
● ├─ondemand.service
● ├─sysstat.service
● ├─systemd-update-utmp-runlevel.service (disabled)
● ├─ureadahead.service                   (disabled)
● └─multi-user.target

un confronto con il primo livello di multi-user.target:

admin@server16.04:~$ systemctl list-dependencies multi-user.target
multi-user.target
● ├─apache2.service
● ├─apport.service
● ├─atd.service
● ├─cron.service
● ├─dbus.service
● ├─grub-common.service
● ├─irqbalance.service
● ├─lxcfs.service
● ├─lxd-containers.service
● ├─mdadm.service
● ├─networking.service
● ├─ondemand.service
● ├─open-vm-tools.service

...

Ho notato che se togliamo gli obiettivi disabili nel graphical.targetalbero ( display-manager.service, systemd-update-utmp-runlevel.service, ureadahead.service), quasi tutti i rimanenti:

• apache2.service
• apport.service
• grub-common.service
• grub-common.service
• irqbalance.service
• mdadm.service
• ondemand.service
• e sysstat.service

sono già inclusi nel primo livello dell'albero delle dipendenze di multi-user.target.

Anche se, dovremmo chiedere di nuovo su questo fatto, poiché graphical.targetdipende da ciò multi-user.target, non c'è bisogno di tutte queste cose. Sembra abbastanza strano.

Ma dopo questa riduzione, rimane un servizio accounts-daemon.service, come ha sottolineato Rinzwind nel suo commento .

Quindi possiamo supporre che graphical.targetsia necessario per caricare il file accounts-daemon.service.

Tuttavia, in quel caso è di nuovo strano, perché mi assottigliare avrebbe più senso creare un obiettivo dedicato a tale scopo, forse qualcosa di simile accounts.targeto un termine corretto per descriverlo. Ad ogni modo, probabilmente gli sviluppatori canonici avevano i loro motivi per pensare in quel modo.

Ma sono curioso di conoscerne le ragioni.