Warum hat ein Ubuntu-Server graphical.target als Standardsystemziel?


20

Ich bin seit einiger Zeit ein Ubuntu-Benutzer und bei der Arbeit haben wir viele Ubuntu-VM- Server , die alle ausgeführt werden Ubuntu 14.04 LTS, um unsere Webanwendungen, Datenbanken und andere Tools bereitzustellen.

Derzeit studiere ich Ubuntu 16.04 LTSDesktop und Server, um in naher Zukunft ein problemloses Upgrade unserer Produktionsserver durchführen zu können.

Seit Ubuntu 15.04 initund upstartwurde ersetzt durch Systemd, also studiere ich auch Systemd.

Ich habe festgestellt, dass mein Entwicklungscomputer, auf dem Ubuntu 16.04 Desktop Edition ausgeführt wird, graphical.targetstandardmäßig das systemd-Ziel hat, was logisch ist.

Aber dann bemerkte ich, dass der Testserver, auf dem Ubuntu 16.04 Server Edition ausgeführt wird, auch graphical.targetals Standardsystemziel verwendet wird.

$ systemctl get-default
graphical.target

Also bin ich verwirrt. Der Server hat keine grafische Ebene. Wie lautet also das Standardziel graphical.target?

Bearbeiten Sie # 0

Wie Rinzwind in den Kommentaren vorgeschlagen hat, habe ich mir das Ziel angesehen, um zu sehen, ob es aktiv ist oder nicht ...

und die Antwort lautet JA:

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.

Also bin ich etwas verwirrter.

Bearbeiten Sie # 1

Die Antwort von Mark Stosberg weist darauf hin, dass dieser display-manager.serviceTeil des Abhängigkeitsbaums des graphical.targeteigenen 16.04-Servers ist, und er fügt hinzu, dass auf seinem Computer kein Display-Manager installiert ist oder ausgeführt wird. Ich habe mir das auch angesehen, und tatsächlich gibt es auf meinem Server diese Abhängigkeit:

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

...

Und dieses Ziel hat links einen roten Kreis, während die meisten anderen Abhängigkeiten einen grünen Kreis haben.

Und dieses Mal ist das Ergebnis konsistent:

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

Aber hier ist eine andere seltsame Sache: Auf meiner Desktop-Edition ist das display-manager.servicekeine Abhängigkeit von graphical.target:

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

Aber ich fand auch eine Alternative , weil ich laufen Ubuntu-Gnomemit lightdmÄnderung des Standard - Window - Manager:

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

Ihnen fehlt eine wichtige Information: ist graphical.targetaktiv?
Rinzwind

Vielen Dank für Ihren Kommentar. Aber tatsächlich ist es aktiv! Was heißt das ?
Rémi B.

Hmm fand etwas relevantes.
Rinzwind

Der Teil, der Sinn machen könnte: "... oder accounts-daemon.service" Server wird dies auch brauchen, würde ich annehmen. Verwirrend, um es gelinde auszudrücken.
Rinzwind

Antworten:


10

Trotz des Namens des Ziels läuft auf Ubuntu Server 16.04 nichts Grafisches. Mit diesem Befehl können Sie Folgendes überprüfen und mit Ihrem Desktop vergleichen:

systemctl list-dependencies graphical.target 

Auf meinem Ubuntu 16.04-Server sehe ich, dass die Ziele von "display-manager.service" abhängen, aber kein Display-Manager installiert ist oder ausgeführt wird.

Ich gehe davon aus, dass Ubuntu-Server auf diese Art und Weise auf Konsistenz eingestellt sind, obwohl ich der Meinung bin, dass dies verwirrend ist.


Einverstanden über die verwirrende Pary. Jemand denkt wahrscheinlich, dass es nicht ausreicht, ein de zu setzen
Rinzwind

@Rinzwind, ich verstehe deine Redewendung "Ein De nicht zu setzen ist genug" nicht (das Englisch ist nicht meine Muttersprache)
Rémi B.

Sie haben wahrscheinlich Recht mit dem Bedürfnis nach Konsistenz. Wird die Server-Edition vom Desktop anstatt auf eine andere Weise von Debian erstellt?
Rémi B.

'de' bedeutet Desktop-Umgebung. Ich erinnere mich an eine Nachricht von vor ein paar Jahren, in der Ubuntu begann, ein Basissystem zu verwenden. Ich weiß jedoch nicht, ob sie einen Server zum Erstellen des Desktops verwenden oder ob sie einen Desktop zum Erstellen eines Servers verwenden. "graphical.target" legt den Desktop-Dienst fest; es kann den Wert "" haben und dann kein DE starten, ist aber verwirrend (ich würde erwarten, dass das einen Wert enthält und der Server "multi-user.target" verwendet
Rinzwind

8

Aus dem Redhat-Handbuch :

Beispielsweise startet die Einheit graphical.target, mit der eine grafische Sitzung gestartet wird, Systemdienste wie GNOME Display Manager (gdm.service) oder Accounts Service (accounts-daemon.service) und aktiviert auch den Mehrbenutzer. Zieleinheit. In ähnlicher Weise startet die Einheit multi-user.target andere wichtige Systemdienste wie NetworkManager (NetworkManager.service) oder D-Bus (dbus.service) und aktiviert eine andere Zieleinheit namens basic.target.

Das Festlegen ist also nicht falsch, da der Display-Manager nicht aktiviert wird, wenn der Dienst, der den Display-Dienst verarbeitet, nicht festgelegt ist.

Für einen Server können Sie ihn festlegen multi-user.target, er wird jedoch nicht benötigt. Sieht so aus, als ob du auf Runlevel 4 landest und auf Runlevel 5, wenn du es nicht tust.

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. 

Ich würde mich über ein Feedback zur Ablehnung freuen.
Rinzwind

1

Detaillierteres Untersuchen der ersten Ebene der Baumabhängigkeit des Ziels 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

ein Vergleich mit der ersten Ebene der 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

...

Ich stelle fest , dass , wenn wir die deaktivierten Ziele im entfernen graphical.targetBaum ( display-manager.service, systemd-update-utmp-runlevel.service, ureadahead.service), die fast alle der verbleibenden:

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

sind bereits in der ersten Ebene des Abhängigkeitsbaums der enthalten multi-user.target.

Allerdings sollten wir noch einmal nachfragen, denn die graphical.target von abhängt multi-user.target, gibt es keine Notwendigkeit für all diese Sachen. Es hört sich schon komisch an.

Aber nach dieser Reduzierung bleibt es eine Leistung, die accounts-daemon.service, wie Rinzwind in seinem Kommentar hervorhob .

Wir können also davon ausgehen, dass die graphical.targetzum Laden der benötigt wirdaccounts-daemon.service .

In diesem Fall ist es jedoch wieder seltsam, da es meiner Meinung nach sinnvoller wäre, ein spezielles Ziel für diesen Zweck zu erstellen, vielleicht so etwas wie accounts.target oder einen korrekten Begriff, um es zu beschreiben. Wie auch immer, wahrscheinlich hatten Canonical-Entwickler ihre Gründe, solche Überlegungen anzustellen.

Aber ich bin gespannt auf die Gründe.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.