[solved] Don't start gdm at multi-user.target

matse · 2017-03-28 22:19:13

Hello,
I don't know what's wrong with my system, but somehow gdm is always started, if I enable it.
Basically what I want is the following behaviour (which I believe worked some time ago):

I want 2 entries in syslinux:

1. Arch Linux
2. Arch Linux Multi User

So that I can decide, if I want a graphical login (with GDM) or not (boot into console)
I want to achieve this basically about this kernel command line parameters (shortened) via syslinux:

    MENU LABEL Arch Linux
    APPEND [...] systemd-unit=graphical.target rw

    MENU LABEL Arch Linux Multi User
    APPEND [...] systemd.unit=multi-user.target rw

What actually happens is that with both entries I end up with a started gdm.

Of course I have installed and enabled gdm:

# systemctl enable gdm
Created symlink /etc/systemd/system/display-manager.service → /usr/lib/systemd/system/gdm.service.

At the moment this is my default target:

# systemctl get-default 
multi-user.target

but it doesn't matter if I change it to graphical.target or not. GDM always starts, if it is enabled.
Only method to boot directly into console is to disable gdm and reboot. But I would like to have the choice in syslinux.

I really believe this worked some time... but now it doesn't anymore. Any ideas why?

Greetings,
matse

Last edited by matse (2017-03-29 08:04:58)

loqs · 2017-03-28 22:53:14

What is the output from the following when booting to multi-user.target

$ systemctl --reverse list-dependencies gdm.service
$ systemctl status graphical.target
$ systemctl status gdm.service

edit:
Grammar removed "of" added "from the following"

Last edited by loqs (2017-03-28 22:54:24)

matse · 2017-03-29 07:52:11

That's it!

$ systemctl --reverse list-dependencies gdm.service
gdm.service
● └─graphical.target
● └─sundtek.service

revealed sundtek.service as cause of all my trouble!
Disabling it solved the problem and the behaviour is as expected. It's a servie belonging to my tv-stick.
Thanks so much for the help!
Greetings
matse

sundtek · 2017-03-29 10:52:59

Does it work for you without the Wants=graphical.target line?

[Unit]
Description=Sundtek MediaTV
Wants=graphical.target

I think this was initially added to register the tuners as late as possible.

Trilby · 2017-03-29 11:01:32

Sundtek, thanks for joining - it's always good to seem upstream so quick to respond.

That line is only in one of three otherwise redundant versions of the service file in the package. The problem may be from the "Wants" but definitely so with the "WantedBy" line:

[Install]
WantedBy=multi-user.target

I suspect instead of "Wants" you mean to use "After". And if this is to only start at the end of graphical startup it should be WantedBy graphical.target not multi-user.target. Being pulled in by graphical.target and in turn pulling in a different target is the cause of the problem.

If it only makes sense for this service to run when a graphical target is selected, change the WantedBy line. This is not likely the case though, as many users will boot to multi-user.target and start a graphical session manually (or automaticaly from bash_profile).

If it makes sense to have this run for either mutli-user or graphical targets, then you definitely can't require graphical.target in a "Wants" line.

More to the root of the problem: why do you want to register the tuners "as late as possible"? Really we want everything to happen as early as possible. As early as possible, but no earlier. I suspect there may be something that actually is required to be done first in order for setting up the tuners to work properly. Do not try to make the service run "as late as possible" in hopes that this prerequisite will be coincidentally met by that time: code in the prerequisite specifically. What is it exactly that is needed?

sundtek · 2017-03-29 12:11:37

The reason why we want to register the tuner as late as possible is to give the system enough time to load legacy drivers.
Since we provide our own drivers the strategy is to "add" additional drivers, not to interfere with them.
Some of our tuners support AnalogTV / S-Video / Composite, the node for that is /dev/videoN; while on most systems /dev/video0 will be the webcam, our tuner should register /dev/video1
The legacy webcam is registered via the Kerneldriver, while our driver simulates the entire interface on application level, the application based driver has no knowledge about the kernel drivers, and the kernel drivers have no knowledge about the application based drivers so we just add our drivers once the kerneldrivers are done with their initialization.
Also our drivers work nearly everywhere with any kernel version the challenge is to have something that will work with everything and virtually everywhere.

The key advantage of our drivers is that they will survive a kernel update and are independent of the running kernel (and they're extremely easy to install on any architecture).

I think about removing the graphical target form our service file, I checked the history of it in our repository it was added in 2012 and there hasn't been any modification to it since then. I think there's no reasonable reason to keep it inside.

Last edited by sundtek (2017-03-29 20:10:03)

Arch Linux

#1 2017-03-28 22:19:13

[solved] Don't start gdm at multi-user.target

#2 2017-03-28 22:53:14

Re: [solved] Don't start gdm at multi-user.target

#3 2017-03-29 07:52:11

Re: [solved] Don't start gdm at multi-user.target

#4 2017-03-29 10:52:59

Re: [solved] Don't start gdm at multi-user.target

#5 2017-03-29 11:01:32

Re: [solved] Don't start gdm at multi-user.target

#6 2017-03-29 12:11:37

Re: [solved] Don't start gdm at multi-user.target

Board footer