Dlaczego serwer Ubuntu ma graphical.target jako domyślny systemowy cel?

Od jakiegoś czasu jestem użytkownikiem Ubuntu, aw pracy mamy wiele serwerów VM Ubuntu , z których wszystkie działają w Ubuntu 14.04 LTScelu wdrażania naszych aplikacji internetowych, baz danych i innych narzędzi.

Obecnie studiuję Ubuntu 16.04 LTS, na komputerze i serwerze, aby móc w niedalekiej przyszłości zaktualizować nasze serwery produkcyjne bez powodowania problemów.

Od wersji Ubuntu 15.04 initi upstartzostały zastąpione przez Systemd, dlatego też studiuję Systemd.

Zauważyłem, że mój komputer programistyczny z systemem Ubuntu 16.04 Desktop Edition ma graphical.targetdomyślny systemowy cel, co jest logiczne.

Ale potem zauważyłem, że serwer testowy z systemem Ubuntu 16.04 Edition Edition również używa graphical.targetjako domyślnego systemowego celu.

$ systemctl get-default
graphical.target

Więc jestem zmieszany. Serwer nie ma żadnej warstwy graficznej, więc jak to jest, że domyślnym celem jest graphical.target?

Edytuj # 0

Jak sugerował Rinzwind w komentarzach, spojrzałem na cel, aby zobaczyć, czy jest aktywny, czy nie ...

a odpowiedź brzmi TAK:

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.

Więc jestem trochę bardziej zdezorientowany.

Edytuj nr 1

Odpowiedź Marka Stosberga wskazuje na fakt, że display-manager.servicejest ona częścią drzewa zależności graphical.targetna własnym serwerze 16.04 i dodaje, że żaden menedżer wyświetlania nie jest zainstalowany ani uruchomiony na jego komputerze. Też na to spojrzałem i rzeczywiście na moim serwerze istnieje zależność:

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

...

Ten cel ma czerwone kółko po lewej stronie, a większość pozostałych zależności ma zielony.

I tym razem wynik jest spójny:

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

Ale display-manager.servicejest jeszcze jedna dziwna rzecz: w moim wydaniu na komputery stacjonarne nie ma zależności graphical.target:

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

Ale nawet znalazłem alternatywę, ponieważ biegnę Ubuntu-Gnomez lightdmzastąpieniem domyślnego menedżera okien:

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

Pomimo nazwy celu, na Ubuntu Server 16.04 nie ma nic graficznego. Możesz to polecenie sprawdzić i porównać z pulpitem, jeśli chcesz:

systemctl list-dependencies graphical.target 

Na moim serwerze Ubuntu 16.04 widzę, że cele zależą od „display-manager.service”, ale żaden menedżer ekranu nie jest zainstalowany ani uruchomiony.

Oczekuję, że serwery Ubuntu są ustawione w ten sposób dla pewnego rodzaju spójności, chociaż zgadzam się, że jest to mylące.

Z podręcznika redhat :

Na przykład jednostka graphical.target, która służy do uruchamiania sesji graficznej, uruchamia usługi systemowe, takie jak Menedżer wyświetlania GNOME (gdm.service) lub Usługa kont (account-daemon.service), a także aktywuje wielu użytkowników. jednostka docelowa. Podobnie jednostka multi-user.target uruchamia inne istotne usługi systemowe, takie jak NetworkManager (NetworkManager.service) lub D-Bus (dbus.service) i aktywuje inną jednostkę docelową o nazwie basic.target.

Dlatego ustawianie go nie jest błędem, ponieważ nie aktywuje menedżera wyświetlania, gdy usługa obsługująca usługę wyświetlania nie jest ustawiona.

W przypadku serwera można go ustawić, multi-user.targetale nie jest to konieczne. Wygląda na to, że skończysz na poziomie 4, jeśli to zrobisz, i na poziomie 5, jeśli nie.

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. 

Sprawdzając bardziej szczegółowo pierwszy poziom zależności drzewa od celu 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

porównanie z pierwszym poziomem 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

...

Zauważyłem, że jeśli usuniemy cele niepełnosprawnym w graphical.targetdrzewo ( display-manager.service, systemd-update-utmp-runlevel.service, ureadahead.service), prawie wszystkich pozostałych:

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

są już uwzględnione na pierwszym poziomie drzewa zależności multi-user.target.

Chociaż powinniśmy ponownie zapytać o ten fakt, ponieważ graphical.targetzależy to od tego multi-user.target, nie ma potrzeby, aby wszystkie te rzeczy. Brzmi dość dziwnie.

Ale po tej redukcji pozostaje ona jedną usługą accounts-daemon.service, jak wskazał Rinzwind w swoim komentarzu .

Możemy więc założyć, że graphical.targetjest potrzebny do załadowania accounts-daemon.service.

Jednak w tym przypadku jest to znowu dziwne, ponieważ myślę, że bardziej sensownym byłoby stworzenie dedykowanego celu do tego celu, być może czegoś w rodzaju accounts.targetlub dowolnego poprawnego terminu na jego opisanie. W każdym razie, prawdopodobnie programiści Canonical mieli powody, aby tak myśleć.

Ale jestem ciekawa, jakie są tego powody.