Description of problem: Ending a GNOME session under Wayland results in a black screen of death (monitor is going forever to power saving mode). No inputs (keyboard and mouse) can wake it up, though magic SysRq are still working to reboot the computer. It happens both if you try to simply close the session (GDM greeter should appear) or indirectly if you choose to stop the computer from the GNOME shell menu (Plymouth is expected in that case, even if the computer is properly shutting down). The system is still alive and reachable from an SSH connection, but I havenât found something relevant in the logs. BTW, I had the same issue when switching to another user session (still from the GNOME shell menu) or when reaching the limit of input inactivity, but that is now fixed since I removed gnome-screensaver package (urpmi told me that it was ophan, perhaps it should be removed from Mageia as Wayland doesnât seem to like screen savers) and restored âAlwaysRestartServer=trueâ in /etc/X11/gdm/custom.confâ¦
(In reply to Davy Defaud from comment #0) > but I > havenât found something relevant in the logs. > Which logs did you check? If the journalctl logs: did you check them as root?
Assignee: bugsquad => gnomeKeywords: (none) => NEEDINFOCC: (none) => marja11
Created attachment 8945 [details] Excerpt of the journal when closing GNOME session
Created attachment 8946 [details] Remaining processes after the end of the GNOME session
Actually, I found something that could be relevant. See my attached journal excerpt. Iâve also attached the list of gdm and wayland processes that are remaining after exiting my (davy) GNOME session. As you can see, gdm is still running, my session has been ended and another GNOME session (julien) is also still running (as expected). One more annoying thing is that I canât restart gdm to get the display back. From an SSH connection, neither âsystemctl restart prefdmâ nor âsystemctl restart gdmâ are respawning the display, and I canât get any virtual console. I just can use the magic SysRq or reboot from an SSH connection. Thatâs why Iâve called the bug âBlack screen of deathâ.
These Redâ¯Hat and GNOME bug reports seems to be related : - https://bugzilla.redhat.com/show_bug.cgi?id=1272737 - https://bugzilla.gnome.org/show_bug.cgi?id=756926 It could be related to COGL. As we are two micro versions late from upstream (2.22.2 vs 2.22.4), may I suggest an upgrade of COGL to version 2.22.4?
We're on the latest cogl release, which is version 1.22.2.
CC: (none) => olav
The funny thing is that Iâm not even able to find the source of my confusion⦠:-/ Shame on me. Sorry for the noise.
I also checked the other patch and seems it was already included. There was some resize patch, I added this but I doubt it'll help anything.
As you presumed, the patch doesnât help. Anyway, thank you for help. I hope weâll find a fix to this nasty bug that, IMHO, should be considered as a blocker one for Mageia 6 releaseâ¦
I actually think I noticed this recently. Meaning: last few days (since a reboot). If I lock my pc it'll keep in standby. I thought it was my USB hub acting up... but sounds pretty similar.
Attachment 8946 mime type: application/postscript => text/plain Attachment 8946 filename: processes_running_after_logout.ps => processes_running_after_logout_ps
I also had problem with suspend: when the PC wakes up, display is showing the unlock dialog for a couple of second then the screen goes to standby. Ctrl-Alt-Syst-B Magic SysRq isnât rebooting, but acts as a new wake up. The screen goes back to the unlock dialog, but this time the screen doesnât go to standby and the computer remains usable. Another suspend goes the exact same way: the screen goes to standby a couple of seconds after the wake up, and Magic SysRq reboot is acting as a new wake up without the standby problem. Can you reproduce that trouble too?
My problem is suddenly gone. No clue why :-( Could you post more of the logs? Various seem to be caused by the session closing. Maybe there's a better cause a bit earlier.
Still there with GNOME 3.24.
Are you using any kind of extensions? Can you reproduce if you create a new userid and login with that?
Yes, I use some extensions (OpenWeather, Caffeine,Pidgin im integration and System-monitor), but some of them (System-monitor and OpenWeather) donât start since the upgrade to GNOMEÂ 3.24. Anyway, I tried with a fresh user with default options, and even when heâs the first and only one running a GNOME session, the bug is still there. :-(
Created attachment 9537 [details] Excerpt of the journal when closing GNOME session, with GNOME_SESSION_DEBUG=1 GDM debug enabled This is a richer journal excerpt with GNOME_SESSION_DEBUG=1 and debug mode activated in /etc/X11/gdm/custom.conf
The most “relevant” error I’ve seen is: > Jul 30 15:16:47 darkvador /usr/libexec/gdm-wayland-session[2598]: Activated service 'org.freedesktop.systemd1' failed: Process org.freedesktop.systemd1 exited with status 1 I found this hint: https://github.com/systemd/systemd/issues/5247 According to Lennart, “this suggests [you] aren’t actually running dbus from the systemd --user instance”. > [davy@darkvador ~]$ systemctl --user status dbus.service > Failed to dump process list, ignoring: Unit dbus.service not found. > Warning: dbus.service changed on disk. Run 'systemctl --user daemon-reload' to r > ● dbus.service > Loaded: not-found (Reason: No such file or directory) > Active: inactive (dead) Whereas I’m supposed to have something like: > $ systemctl --user status dbus.service > ● dbus.service - D-Bus User Message Bus > Loaded: loaded (/usr/lib/systemd/user/dbus.service; static; vendor preset: enabled) > Active: active (running) since Sun 2017-03-19 05:58:41 CET; 4h 49min ago > Docs: man:dbus-daemon(1) > Main PID: 1773 (dbus-daemon) > CGroup: /user.slice/user-1000.slice/user@1000.service/dbus.service > └─1773 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation Here are the dbus processes running on my system: > message+ 848 1 0 15:43 ? 00:00:02 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation > gdm 1776 1774 0 15:43 tty1 00:00:00 dbus-daemon --print-address 3 --session > gdm 2249 2244 0 15:43 tty1 00:00:00 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3 > davy 2532 2530 0 15:44 tty2 00:00:00 dbus-daemon --print-address 3 --session > davy 2660 2655 0 15:44 tty2 00:00:00 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3 > root 3727 1 0 15:55 tty2 00:00:00 dbus-launch --autolaunch=6685d25a9fec473f8e1d139f4f84068d --binary-syntax --close-stderr > root 3728 1 0 15:55 ? 00:00:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session Is this something relevant?
I have some news about this old and annoying bug. I’ve just changed my antique (11 yo) graphic board (Radeon X1900 XT, driven by r300g graphics driver) and the bug miraculously vanished. The bug is still relevant (so I let it opened for the record), but now we know that it’s a graphics driver bug. Even though I guess it probably won’t be fixed upstream, because nowadays very few people are running this old kind of hardware and the Radeon graphics developers have more exciting stuff to work on…
Hi, thanks for reporting this bug. We are sorry, but we no longer maintains this version of Mageia. Please upgrade to the latest version and reopen this bug against that version if this bug exists there. As a result we are setting this bug to RESOLVED:OLD
Status: NEW => RESOLVEDResolution: (none) => OLD