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:
[email protected]:~$ 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:
[email protected]:~ $ systemctl list-dependencies graphical.target | grep display
[email protected]:~ $
Pero incluso encontré una alternativa porque corro Ubuntu-Gnomecon lightdmla sustitución del gestor de ventanas por defecto:
[email protected]:~ $ systemctl list-dependencies graphical.target | grep lightdm
● ├─lightdm.service
graphical.targetactivo?Respuestas:
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:
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.
fuente
Del manual de redhat :
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.fuente
Inspeccionando más en detalle el primer nivel de la dependencia del árbol del objetivo
graphical.target:una comparación con el primer nivel de
multi-user.target: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.serviceapport.servicegrub-common.servicegrub-common.serviceirqbalance.servicemdadm.serviceondemand.servicesysstat.serviceya 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 demulti-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 elaccounts-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.
fuente