GNOME Bugzilla – Bug 764665
sudo systemctl restart gdm fails
Last modified: 2018-05-24 11:22:22 UTC
Created attachment 325458 [details] gdm's journal logs Say there's an update to the xserver and I want to restart gdm rather than reboot completely. If I restart the gdm service, it fails to start and I have to switch to another tty to reboot. This is on 3.20.0, but I beleive the same issue existed on 3.18. I seem to recall that this did work at some point, but I may be mistaken. I've attached gdm's logs.
I have the same issue on openSUSE Tumbleweed. When we try to restart the gdm as a system service, we will stop it by send SIGTERM signal to gdm daemon and start it by executing /usr/sbin/gdm. I can see these issues after we do a "systemctl stop" operation: 1. Gdm daemon only sends SIGTERM signal to gdm-x-session(user-session) which is logging in right now. But gdm-x-session(gdm-session) is still alive. 2. After process gdm-x-session(user-session) receives "SIGTERM", it finishes itself quickly, but all his child processes do not quit peacefully, and are adopted by pid one. Then if we start it in this situation, gdm startup process will fail, because the old gdm-session(launch-environment) process is still alive and possess the resources.
For the issue 2 in my last comment, it is caused by commit: 6b8586958a97c0a72b9c8bae3c73b945089dfa3d
(In reply to tyang from comment #2) > For the issue 2 in my last comment, it is caused by commit: > 6b8586958a97c0a72b9c8bae3c73b945089dfa3d Gdm-x-session process exits immediately when it got "SIGTERM" signal. I think it is a bad idea that process chooses to exit but not release other resources, especially its child processes. For the issue 1 in my comment#1, there's a logical mistake in code base. I will provide a patch to fix that issue later. So if these two issues could be solved, then we can restart gdm successfully. Thanks
This might be a duplicate of https://bugzilla.gnome.org/show_bug.cgi?id=780213 See my workaround at https://bugzilla.gnome.org/show_bug.cgi?id=780213#c5 If you are using Fedora, the gdm user is likely to be called differently and you need to adjust the ExecStopPost= accordingly. As it seems, stopping gdm doesn't doesn't seem to signal the running gdm session to stop, so it keeps running in its own session scope, not releasing access to DRI devices.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gdm/issues/255.