I've been an Ubuntu user for a while, and at work we have many Ubuntu VM servers, all of which run Ubuntu 14.04 LTS to deploy our web applications, databases, and other tools.

I'm currently studying Ubuntu 16.04 LTS, desktop and server, to be able to upgrade our production servers in the near future without causing problems.

Since Ubuntu 15.04, init and upstart have been replaced by Systemd, so I'm studying Systemd too.

I noticed that my development computer running Ubuntu 16.04 Desktop edition has graphical.target as the default systemd target, which is logical.

But then I noticed that the testing server running Ubuntu 16.04 Server edition also uses graphical.target as the default systemd target.

$ systemctl get-default
graphical.target

So I'm confused. The server doesn't have any graphical layer, so how it is that the default target is graphical.target?

Edit #0

Like Rinzwind suggested in the comments, I looked at the target to see whether it's active or not...

and the response is YES:

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.

So I'm a bit more confused.

Edit #1

The Mark Stosberg's answer point the fact that display-manager.service is part of the dependency tree of the graphical.target on its own 16.04 server, and he adds that no display manager is installed or running on its machine. I looked at that too, and indeed, on my server this dependency is there:

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

...

And this target has a red circle on the left, where most of the other dependencies have a green one.

And this time the result is consistent:

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

But here is an other strange thing: on my desktop edition, the display-manager.service is not a dependency of graphical.target:

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

But I even found an alternative because I run Ubuntu-Gnome with lightdm replacing the default window manager:

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

migrated from unix.stackexchange.com Oct 13 '16 at 13:52

This question came from our site for users of Linux, FreeBSD and other Un*x-like operating systems.

  • You are missing 1 vital piece of information: is graphical.target active? – Rinzwind Oct 13 '16 at 14:40
  • Thanks for your comment. But in fact, yes, it's active! What does it mean ? – Rémi B. Oct 13 '16 at 14:55
  • Hmm found something relevant. – Rinzwind Oct 13 '16 at 15:24
  • the part that might make sense: "... or accounts-daemon.service" Server will need this too I would assume. Confusing though to say the least. – Rinzwind Oct 13 '16 at 19:27

Despite the name of the target, there is nothing graphical running on Ubuntu Server 16.04. You can this command to check and compare it with your desktop if you like:

systemctl list-dependencies graphical.target 

On my Ubuntu 16.04 server, I see that the targets depends on "display-manager.service", but no display manager is installed or running.

I expect Ubuntu servers are set this way for some kind of consistency, although I agree it's confusing.

  • Agreed on the confusing pary. Someone probably thinks not setting a de is enough – Rinzwind Oct 13 '16 at 16:31
  • @Rinzwind, I don't understand your phrase "not setting a de is enough" (the english isn't my primary language) – Rémi B. Oct 14 '16 at 9:12
  • You're probably right about the need of consistency. Is the server edition built from the desktop instead of with an alternate way from debian ? – Rémi B. Oct 14 '16 at 9:18
  • 'de' means desktop environment. I remember a notice from a few years ago where it said Ubuntu started using1 base system; but I do not know if they use a server to create the desktop or if they use a desktop to create a server. "graphical.target" sets the desktop service; it can have a value of "" and then not start a DE but confusing it is (I'd expect that to hold a value and the server to use "multi-user.target" – Rinzwind Oct 14 '16 at 9:24
  • @Rinzwind Ok thanks. Yes I'd expect that too – Rémi B. Oct 14 '16 at 9:38

From the redhat manual:

For example, the graphical.target unit, which is used to start a graphical session, starts system services such as the GNOME Display Manager (gdm.service) or Accounts Service (accounts-daemon.service) and also activates the multi-user.target unit. Similarly, the multi-user.target unit starts other essential system services such as NetworkManager (NetworkManager.service) or D-Bus (dbus.service) and activates another target unit named basic.target.

So it is not wrong for it to be set since it does not activate the display manager when the service that handles the display service is not set.

For a server you can set it to multi-user.target but it is not needed. Looks like you end up on runlevel 4 if you do and runlevel 5 when you don't.

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. 
  • I would appreciate feedback on the downvote. – Rinzwind Oct 14 '16 at 7:08
up vote 1 down vote accepted

Inspecting more in details the first level of the tree dependency of the target 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

an comparing it with the first level of the 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

...

I notice that if we remove the disabled targets in the graphical.target tree (display-manager.service, systemd-update-utmp-runlevel.service, ureadahead.service), almost all of the remaining ones :

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

are already included in the first level of the dependency tree of the multi-user.target.

Although, we should ask again about this fact, because the graphical.target depends of the multi-user.target, there is no need to all this stuff. It sound enough weird.

But after this reduction, it remains one service, the accounts-daemon.service, like Rinzwind pointed out in its comment.

So we can assume that the graphical.target is needed to load the accounts-daemon.service.

However, in that case its again weird, because I thin it would make more sense to create a dedicated target for that purpose, perhaps something like accounts.target or any correct term to describe it. Anyway, probably Canonical developers had their reasons to make thinks like that.

But I'm stay curious to know its reasons.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.