Pourquoi un serveur Ubuntu a-t-il graphical.target comme cible systemd par défaut?

Je suis un utilisateur Ubuntu depuis un certain temps, et au travail, nous avons de nombreux serveurs VM Ubuntu , qui fonctionnent tousUbuntu 14.04 LTS pour déployer nos applications Web, nos bases de données et d'autres outils.

J'étudie actuellement Ubuntu 16.04 LTS , bureau et serveur, pour pouvoir mettre à niveau nos serveurs de production dans un futur proche sans causer de problèmes.

Depuis Ubuntu 15.04, initet upstartont été remplacés par Systemd, donc j'étudie aussi Systemd.

J'ai remarqué que mon ordinateur de développement exécutant Ubuntu 16.04 Desktop Edition a graphical.targetcomme cible systemd par défaut, ce qui est logique.

Mais ensuite, j'ai remarqué que le serveur de test exécutant Ubuntu 16.04 Server edition utilise également graphical.targetcomme cible systemd par défaut.

$ systemctl get-default
graphical.target

Je suis donc confus. Le serveur n'a pas de couche graphique, alors comment se fait-il que la cible par défaut soit graphical.target?

Modifier # 0

Comme Rinzwind l'a suggéré dans les commentaires, j'ai regardé la cible pour voir si elle est active ou non ...

et la réponse est OUI:

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.

Je suis donc un peu plus confus.

Éditer # 1

La réponse de Mark Stosberg souligne le fait qu'il display-manager.servicefait partie de l'arborescence des dépendances de graphical.targetson propre serveur 16.04, et il ajoute qu'aucun gestionnaire d'affichage n'est installé ou en cours d'exécution sur sa machine. J'ai aussi regardé cela, et en effet, sur mon serveur, cette dépendance est là:

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

...

Et cette cible a un cercle rouge sur la gauche, où la plupart des autres dépendances ont un cercle vert.

Et cette fois, le résultat est cohérent:

[email protected]:~$ systemctl status display-manager.service 
● display-manager.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

Mais voici une autre chose étrange: sur mon édition de bureau, ce display-manager.servicen'est pas une dépendance de graphical.target:

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

Mais j'ai même trouvé une alternative car je lance Ubuntu-Gnomeen lightdmremplaçant le gestionnaire de fenêtres par défaut:

[email protected]:~ $ systemctl list-dependencies graphical.target | grep lightdm
● ├─lightdm.service

Malgré le nom de la cible, il n'y a rien de graphique en cours d'exécution sur Ubuntu Server 16.04. Vous pouvez cette commande pour le vérifier et le comparer avec votre bureau si vous le souhaitez:

systemctl list-dependencies graphical.target 

Sur mon serveur Ubuntu 16.04, je vois que les cibles dépendent de "display-manager.service", mais aucun gestionnaire d'affichage n'est installé ou en cours d'exécution.

Je m'attends à ce que les serveurs Ubuntu soient configurés de cette façon pour une sorte de cohérence, bien que je convienne que cela prête à confusion.

Du manuel redhat :

Par exemple, l'unité graphical.target, qui est utilisée pour démarrer une session graphique, démarre les services système tels que le gestionnaire d'affichage GNOME (gdm.service) ou le service de comptes (accounts-daemon.service) et active également le multi-utilisateur. unité cible. De même, l'unité multi-user.target démarre d'autres services système essentiels tels que NetworkManager (NetworkManager.service) ou D-Bus (dbus.service) et active une autre unité cible nommée basic.target.

Il n'est donc pas faux de le définir car il n'active pas le gestionnaire d'affichage lorsque le service qui gère le service d'affichage n'est pas défini.

Pour un serveur, vous pouvez le définir multi-user.targetmais ce n'est pas nécessaire. On dirait que vous vous retrouvez au niveau d'exécution 4 si vous le faites et au niveau d'exécution 5 lorsque vous ne le faites pas.

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. 

En examinant plus en détail le premier niveau de la dépendance de l'arborescence de la cible 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

une comparaison avec le premier niveau du multi-user.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

...

Je remarque que si nous enlevons les cibles handicapés dans l' graphical.targetarbre ( display-manager.service, systemd-update-utmp-runlevel.service, ureadahead.service), presque tous les autres:

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

sont déjà inclus dans le premier niveau de l'arborescence de dépendances du multi-user.target .

Cependant, nous devrions nous interroger à nouveau sur ce fait, car graphical.targetlamulti-user.target , il n'est pas nécessaire de tout cela. Cela semble assez bizarre.

Mais après cette réduction, il reste un service accounts-daemon.service, comme l' a souligné Rinzwind dans son commentaire .

Nous pouvons donc supposer que le graphical.targetest nécessaire pour charger leaccounts-daemon.service .

Cependant, dans ce cas, c'est à nouveau bizarre, car je pense qu'il serait plus logique de créer une cible dédiée à cet effet, peut-être quelque chose comme accounts.target ou n'importe quel terme correct pour le décrire. Quoi qu'il en soit, les développeurs de Canonical avaient probablement leurs raisons de penser ainsi.

Mais je reste curieux de connaître ses raisons.