Por que um servidor Ubuntu tem o graphical.target como destino padrão do systemd?

Question

Sou usuário do Ubuntu há algum tempo e, no trabalho, temos muitos servidores do Ubuntu VM, todos executando Ubuntu 14.04 LTS para implantar nossos aplicativos da Web, bancos de dados e outras ferramentas.

Atualmente, estou estudando Ubuntu 16.04 LTS , área de trabalho e servidor, para poder atualizar nossos servidores de produção em um futuro próximo, sem causar problemas.

Desde o Ubuntu 15.04, init e upstart foram substituídos por Systemd , então também estou estudando o Systemd.

Notei que meu computador de desenvolvimento que executa o Ubuntu 16.04 Desktop edition possui graphical.target como o destino systemd padrão, o que é lógico.

Mas então eu notei que o servidor de teste rodando o Ubuntu 16.04 Server edition também usa graphical.target como alvo systemd padrão.

$ systemctl get-default
graphical.target

Então estou confuso. O servidor não tem nenhuma camada gráfica, então como é que o alvo padrão é graphical.target ?

Editar # 0

Como Rinzwind sugeriu nos comentários, eu olhei para o alvo para ver se ele está ativo ou não ...

e a resposta é SIM:

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.

Então estou um pouco mais confuso.

Editar # 1

A resposta de Mark Stosberg aponta o fato de que display-manager.service é parte da árvore de dependências do graphical.target em seu próprio servidor 16.04, e ele acrescenta que nenhum gerenciador de exibição está instalado ou em execução em sua máquina. Eu olhei para isso também, e de fato, no meu servidor esta dependência está lá:

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

...

E este alvo tem um círculo vermelho à esquerda, onde a maioria das outras dependências tem um verde.

E desta vez o resultado é consistente:

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

Mas aqui está outra coisa estranha: na minha edição para desktop, o display-manager.service não é uma dependência de graphical.target :

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

Mas até encontrei uma alternativa porque executo Ubuntu-Gnome com lightdm substituindo o gerenciador de janelas padrão:

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

    

Answer 1

Inspecionando mais detalhes no primeiro nível da dependência de árvore do destino 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

uma comparação com o primeiro nível do 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

...

Noto que, se removermos os destinos desativados na árvore graphical.target ( display-manager.service , systemd-update-utmp-runlevel.service , ureadahead.service ), quase todos os restantes:

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

já estão incluídos no primeiro nível da árvore de dependências do multi-user.target .

Embora, devemos perguntar novamente sobre esse fato, porque o graphical.target depende do multi-user.target , não há necessidade de todas essas coisas. Soa estranho o suficiente.

Mas após essa redução, resta um serviço, o accounts-daemon.service , como Rinzwind apontou em seu comentário .

Portanto, podemos supor que o graphical.target é necessário para carregar o accounts-daemon.service .

No entanto, neste caso, é novamente estranho, porque eu emagreceria faria mais sentido criar um alvo dedicado para essa finalidade, talvez algo como accounts.target ou qualquer termo correto para descrevê-lo. De qualquer forma, os desenvolvedores da Canonical provavelmente tiveram suas razões para pensar assim.

Mas estou curioso para saber suas razões.

    

Answer 2

Apesar do nome do alvo, não há nada gráfico rodando no Ubuntu Server 16.04. Você pode usar este comando para verificar e comparar com sua área de trabalho, se desejar:

systemctl list-dependencies graphical.target 

No meu servidor Ubuntu 16.04, vejo que os destinos dependem de "display-manager.service", mas nenhum gerenciador de exibição está instalado ou em execução.

Espero que os servidores Ubuntu sejam configurados dessa forma para algum tipo de consistência, embora eu concorde que seja confuso.

    

Answer 3

Do manual do redhat :

  

Por exemplo, a unidade graphical.target, que é usada para iniciar uma sessão gráfica, inicia serviços do sistema, como o GNOME Display Manager (gdm.service) ou Serviço de Contas (accounts-daemon.service) e também ativa o multi -user.target unit. Da mesma forma, a unidade multi-user.target inicia outros serviços essenciais do sistema, como NetworkManager (NetworkManager.service) ou D-Bus (dbus.service) e ativa outra unidade de destino denominada basic.target.

Portanto, não é errado configurá-lo, pois ele não ativa o gerenciador de exibição quando o serviço que manipula o serviço de exibição não está configurado.

Para um servidor, você pode configurá-lo para multi-user.target , mas não é necessário. Parece que você acaba no nível de execução 4 se você faz e runlevel 5 quando você não faz.

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.