Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#31602 - [systemd] The default target should be multi-user.target

Attached to Project: Arch Linux
Opened by Steven (Stebalien) - Tuesday, 18 September 2012, 15:27 GMT
Last edited by Tom Gundersen (tomegun) - Thursday, 20 September 2012, 22:29 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Dave Reisner (falconindy)
Tom Gundersen (tomegun)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

As Arch does not provide a graphical environment by default, multi-user.target should replace graphical.target as the default systemd target. This would be consistent with the default run-level in /etc/inittab.

This currently requires patching Makefile.in but really should be a ./configure flag (upstream bug?).

Relevant: https://bbs.archlinux.org/viewtopic.php?pid=1162977
This task depends upon

Closed by  Tom Gundersen (tomegun)
Thursday, 20 September 2012, 22:29 GMT
Reason for closing:  Won't implement
Additional comments about closing:  See discussion.
Comment by Dave Reisner (falconindy) - Tuesday, 18 September 2012, 15:43 GMT
This is simply a packaging change. There's no need to "fix" the upstream makefile.
Comment by Tom Gundersen (tomegun) - Tuesday, 18 September 2012, 18:37 GMT
Why would we not use grahpical.target as default? In case you do not have a graphical environment installed (and enabled), then graphical and multi-user are the same. If you do have a graphical environment enstalled (and enabled), then using multi-user means you will still not be booted into it, which is surprising.

We currently default to runlevel 3 in sysvinit. However, for us that corresponds more to graphical.target than multi-user.target, as all our daemons are started (including kdm/gdm/...) regardless of the runlevel.
Comment by Steven (Stebalien) - Tuesday, 18 September 2012, 19:28 GMT
Because graphical.target isn't a 'run-level'. It corresponds to run-level 5 for legacy reasons but it's really just the boot target for a graphical environment. Also, graphical.target wants display-manager.service. If no display manager is enabled, display-manager.service doesn't exist and systemd prints an error. While this isn't fatal, it's still an error.

Read the systemd.special man page (sections on multi-user.target, graphical.target, runlevel5.target, and display-manager.service) if you still aren't convinced.
Comment by Dave Reisner (falconindy) - Tuesday, 18 September 2012, 19:38 GMT
> Because graphical.target isn't a 'run-level'. It corresponds to run-level 5 for legacy reasons but it's really just the boot target for a graphical environment.
And no one is arguing this. The point is that the current systemd setup provides equivalent behavior to enabling a DM in /etc/rc.conf.

> While this isn't fatal, it's still an error.
Which the user has all the power in the world to fix if it really bothers them.

> Read the systemd.special man page (sections on multi-user.target, graphical.target, runlevel5.target, and display-manager.service) if you still aren't convinced.
Convinced of what, exactly? I don't see a strong reason to deviate from upstream here.
Comment by Steven (Stebalien) - Tuesday, 18 September 2012, 19:50 GMT
This isn't deviating, it's conforming to the upstream spec:
> graphical.target
> A special target unit for setting up a *graphical login screen*.

It's only the default because most distributions ship with a display manager.
Comment by Tom Gundersen (tomegun) - Thursday, 20 September 2012, 22:29 GMT
Most of our users will have a graphical login, so this is the right choice for them. For the few who do not it still does not cause problems (except for the warning), and they can easily change to multi-user.target.

Making this change would cause unnecessary confusion amongst the majority of our users. I don't see the benefit... Closing.

Loading...