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

19

Sono stato un utente di Ubuntu per un po 'e al lavoro abbiamo molti server di Ubuntu VM, che eseguono tutti Ubuntu 14.04 LTS per distribuire le nostre applicazioni web, i 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, init e upstart sono stati sostituiti da Systemd , quindi sto studiando anche Systemd.

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

Ma poi ho notato che il server di test che esegue la versione di Ubuntu 16.04 Server utilizza anche graphical.target come destinazione systemd predefinita.

$ systemctl get-default
graphical.target

Quindi sono confuso. Il server non ha alcun livello grafico, quindi come è che il target predefinito è graphical.target ?

Modifica # 0

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

e la risposta è SÌ:

[email protected]:~$ systemctl get-default
graphical.target

[email protected]:~$ 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 indica che display-manager.service fa parte dell'albero delle dipendenze di graphical.target sul proprio server 16.04 e aggiunge che nessun display manager è installato o in esecuzione sul proprio computer. Ho guardato anche a questo, e in effetti, sul mio server c'è questa dipendenza:

[email protected]:~$ 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 uno verde.

E questa volta il risultato è coerente:

[email protected]:~$ 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 versione desktop, display-manager.service non è una dipendenza di graphical.target :

[email protected]:~ $ systemctl list-dependencies graphical.target | grep display
[email protected]:~ $ 

Ma ho anche trovato un'alternativa perché eseguo Ubuntu-Gnome con lightdm che sostituisce il window manager predefinito:

[email protected]:~ $ systemctl list-dependencies graphical.target | grep lightdm
● ├─lightdm.service
    
posta Rémi B. 13.10.2016 - 15:47

3 risposte

1

Ispezionando più in dettaglio il primo livello della dipendenza dell'albero del% di riferimento% co_de:

[email protected]:~$ 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 graphical.target :

[email protected]:~$ 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 rimuoviamo i target disabilitati nell'albero multi-user.target ( graphical.target , display-manager.service , systemd-update-utmp-runlevel.service ), quasi tutti quelli rimanenti:

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

sono già inclusi nel primo livello dell'albero delle dipendenze di sysstat.service .

Anche se dovremmo chiedere ancora una volta su questo fatto, perché il multi-user.target dipende dal graphical.target , non c'è bisogno di tutto questo. Suona abbastanza strano.

Ma dopo questa riduzione, rimane un servizio, il multi-user.target , come Rinzwind ha sottolineato nel suo commento .

Quindi possiamo supporre che accounts-daemon.service sia necessario per caricare graphical.target .

Tuttavia, in questo caso è ancora strano, perché se lo dilungo avrebbe più senso creare un obiettivo dedicato a tale scopo, forse qualcosa come accounts-daemon.service o qualsiasi termine corretto per descriverlo. Ad ogni modo, probabilmente gli sviluppatori Canonical avevano i loro motivi per pensare in questo modo.

Ma sono curioso di sapere le sue ragioni.

    
risposta data Rémi B. 14.10.2016 - 12:14
9

Nonostante il nome della destinazione, non c'è nulla di grafico in esecuzione su Ubuntu Server 16.04. Puoi utilizzare questo comando per controllarlo e confrontarlo con il tuo desktop, se lo desideri:

systemctl list-dependencies graphical.target 

Sul mio server Ubuntu 16.04, vedo che i target 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 una certa coerenza, anche se sono d'accordo che è confuso.

    
risposta data Mark Stosberg 13.10.2016 - 17:44
8

Dal manuale di redhat :

% Bl0ck_qu0te%

Quindi non è sbagliato impostarlo in quanto non attiva il display manager quando il servizio che gestisce il servizio di visualizzazione non è impostato.

Per un server puoi impostarlo su multi-user.target ma non è necessario. Sembra che tu finisca 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. 
    
risposta data Rinzwind 13.10.2016 - 17:29

Leggi altre domande sui tag