¿Por qué un servidor Ubuntu tiene graphical.target como objetivo predeterminado de systemd?

He sido usuario de Ubuntu por un tiempo, y en el trabajo tenemos muchos servidores Ubuntu VM , todos los cuales se ejecutan Ubuntu 14.04 LTSpara implementar nuestras aplicaciones web, bases de datos y otras herramientas.

Actualmente estoy estudiando Ubuntu 16.04 LTS, escritorio y servidor, para poder actualizar nuestros servidores de producción en un futuro cercano sin causar problemas.

Desde Ubuntu 15.04, inity upstarthe sido reemplazado por Systemd, así que también estoy estudiando Systemd.

Noté que mi computadora de desarrollo que ejecuta Ubuntu 16.04 Desktop Edition tiene graphical.targetcomo objetivo predeterminado systemd, lo cual es lógico.

Pero luego noté que el servidor de prueba que ejecuta Ubuntu 16.04 Server edition también se usa graphical.targetcomo el objetivo predeterminado de systemd.

$ systemctl get-default
graphical.target

Entonces estoy confundido. El servidor no tiene ninguna capa gráfica, entonces, ¿cómo es que es el objetivo predeterminado graphical.target?

Editar # 0

Como Rinzwind sugirió en los comentarios, miré el objetivo para ver si está activo o no ...

y la respuesta es SI:

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.

Entonces estoy un poco más confundido.

Editar # 1

La respuesta de Mark Stosberg señala el hecho de que display-manager.servicees parte del árbol de dependencias del graphical.targetservidor 16.04, y agrega que no se instaló ni ejecutó ningún administrador de pantalla en su máquina. También miré eso, y de hecho, en mi servidor esta dependencia está ahí:

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

...

Y este objetivo tiene un círculo rojo a la izquierda, donde la mayoría de las otras dependencias tienen uno verde.

Y esta vez el resultado es consistente:

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

Pero aquí hay otra cosa extraña: en mi edición de escritorio, display-manager.serviceno depende de graphical.target:

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

Pero incluso encontré una alternativa porque corro Ubuntu-Gnomecon lightdmla sustitución del gestor de ventanas por defecto:

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

A pesar del nombre del objetivo, no hay nada gráfico en ejecución en Ubuntu Server 16.04. Puede usar este comando para verificarlo y compararlo con su escritorio si lo desea:

systemctl list-dependencies graphical.target 

En mi servidor Ubuntu 16.04, veo que los objetivos dependen de "display-manager.service", pero no hay ningún administrador de pantalla instalado o en ejecución.

Espero que los servidores Ubuntu estén configurados de esta manera para algún tipo de consistencia, aunque estoy de acuerdo en que es confuso.

Del manual de redhat :

Por ejemplo, la unidad graphical.target, que se utiliza para iniciar una sesión gráfica, inicia servicios del sistema como el Administrador de pantalla GNOME (gdm.service) o el Servicio de cuentas (accounts-daemon.service) y también activa el multiusuario. unidad objetivo Del mismo modo, la unidad multiusuario.target inicia otros servicios esenciales del sistema, como NetworkManager (NetworkManager.service) o D-Bus (dbus.service) y activa otra unidad objetivo llamada basic.target.

Por lo tanto, no está mal que se configure ya que no activa el administrador de pantalla cuando el servicio que maneja el servicio de pantalla no está configurado.

Para un servidor, puede configurarlo, multi-user.targetpero no es necesario. Parece que terminas en el nivel de ejecución 4 si lo haces y en el nivel de ejecución 5 cuando no lo haces.

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. 

Inspeccionando más en detalle el primer nivel de la dependencia del árbol del objetivo 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

una comparación con el primer nivel de 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

...

Me he dado cuenta de que si quitamos los objetivos de movilidad reducida en el graphical.targetárbol ( display-manager.service, systemd-update-utmp-runlevel.service, ureadahead.service), casi todas las restantes:

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

ya están incluidos en el primer nivel del árbol de dependencias de multi-user.target.

Aunque, deberíamos preguntar nuevamente sobre este hecho, porque graphical.targetdepende de multi-user.target, no hay necesidad de todo esto. Suena bastante raro.

Pero después de esta reducción, sigue siendo un servicio accounts-daemon.service, como señaló Rinzwind en su comentario .

Por lo tanto, podemos suponer que graphical.targetse necesita para cargar el accounts-daemon.service.

Sin embargo, en ese caso es nuevamente extraño, porque creo que tendría más sentido crear un objetivo dedicado para ese propósito, tal vez algo así accounts.targeto cualquier término correcto para describirlo. De todos modos, probablemente los desarrolladores de Canonical tenían sus razones para pensar así.

Pero tengo curiosidad por saber sus razones.