how to disable gdm3 via systemctl?

[Harald Dunkel]

Hi folks,

what is the recommended procedure to disable gmd3 using
systemctl in Buster?

"systemctl mask gdm" does not work as advertised. The "masked"
seems to be ignored.


Every helpful hint is highly appreciated
Harri

[john doe]

Post by Harald Dunkel
Hi folks,
what is the recommended procedure to disable gmd3 using
systemctl in Buster?
"systemctl mask gdm" does not work as advertised. The "masked"
seems to be ignored.

What about 'systemctl disable gdm'?

https://wiki.debian.org/GDM#systemd

--
John Doe

[Harald Dunkel]

Post by john doe
https://wiki.debian.org/GDM#systemd

PS: Changing the default target is not an option (but it
works, AFAICT).


Regards
Harri

[john doe]

Post by Harald Dunkel
Hi folks,
what is the recommended procedure to disable gmd3 using
systemctl in Buster?
"systemctl mask gdm" does not work as advertised. The "masked"
seems to be ignored.

What about 'systemctl disable gdm'?

--
John Doe

[Harald Dunkel]

What about 'systemctl disable gdm'?

Doesn't work, either.

"systemctl status gdm" claims that gdm is masked (or disabled),
but nevertheless it *is* started.

***@usbpc:~# systemctl status gdm
* gdm.service - GNOME Display Manager
Loaded: loaded (/lib/systemd/system/gdm.service; masked; vendor preset: enabled)
Active: active (running) since Mon 2020-01-13 11:23:37 CET; 49s ago
Process: 10440 ExecStartPre=/usr/share/gdm/generate-config (code=exited, status=0/SUCCESS)
Main PID: 10446 (gdm3)
Tasks: 3 (limit: 4915)
Memory: 7.0M
CGroup: /system.slice/gdm.service
`-10446 /usr/sbin/gdm3

Jan 13 11:23:37 usbpc systemd[1]: Starting GNOME Display Manager...
Jan 13 11:23:37 usbpc systemd[1]: Started GNOME Display Manager.
Jan 13 11:23:37 usbpc gdm-launch-environment][10454]: pam_unix(gdm-launch-environment:session): session opened for user Debian-gdm by (uid=0)


The man page for "systemctl mask" says

"Mask one or more units, as specified on the command line. This will
link these unit files to /dev/null, making it impossible to start
them. This is a stronger version of disable, since it prohibits all
kinds of activation of the unit, including enablement and manual
activation."

"impossible" and "prohibits all kinds of activation of the unit" seems
to be unambigous to me.


Harri

[Curt]

Post by Harald Dunkel
Hi folks,
what is the recommended procedure to disable gmd3 using
systemctl in Buster?

https://wiki.debian.org/GDM

systemctl set-default multi-user.target

(Boots you to the console as a result.)

Post by Harald Dunkel
"systemctl mask gdm" does not work as advertised. The "masked"
seems to be ignored.

I dunno. Here on Stretch, /lib/systemd/system/gdm3.service -> gdm.service
(symlink). Perhaps irrelevant.

There's also a unit called 'display-manager.service' (which starts my
lightdm.service).

Post by Harald Dunkel
Every helpful hint is highly appreciated
Harri

[Andrei POPESCU]

Post by Harald Dunkel
Hi folks,
what is the recommended procedure to disable gmd3 using
systemctl in Buster?
"systemctl mask gdm" does not work as advertised. The "masked"
seems to be ignored.

Display Managers are handled a little bit different than "regular"
services, since only one can run at a time (if you have several
installed), but at least one should be running (to not leave a
potentially inexperienced user in front of a text console).

#764607 (still open) has some background info. Not sure exactly what the
current status in Debian is.

Kind regards,
Andrei

[Harald Dunkel]

Hi Andrei,

On 2020-01-13 23:40, Andrei POPESCU wrote:>

Post by Andrei POPESCU
Display Managers are handled a little bit different than "regular"
services, since only one can run at a time (if you have several
installed), but at least one should be running (to not leave a
potentially inexperienced user in front of a text console).

I don't see any reason why it should be impossible to run lightdm on
tty1 and tty2, gdm3 on a vnc session and yet another one on xvfb, all
in parallel (just as an example). Wouldn't you agree that this is a
config issue, i.e the job of the admin to decide? I can handle an
error message triggered by a second dm on tty1, but what chance do I
have, if systemctl doesn't work as documented anymore?


Regards
Harri