Bug 2057419

Proposed as a Blocker for 36-beta by Fedora user lruzicka using the blocker tracking app because:

 I am proposing this as a blocker because it violates the Login, logout Beta criterion.

https://fedoraproject.org/wiki/Fedora_36_Beta_Release_Criteria#Shutdown.2C_reboot.2C_login.2C_logout

I do not currently have any bare metal machine to test if this also happens there.

Can you get a backtrace of the crash? Does it get caught by coredumpd or abrt?

(In reply to Adam Williamson from comment #3)
> Can you get a backtrace of the crash? Does it get caught by coredumpd or
> abrt?

No, I believe that the problem cannot be caught by those means. 
I have cleaned all the problems from abrt and reproduced the issue and this was the only error that was caught by Abrt:

Id            7ab269a  
Component     xdg-desktop-portal-kde  
Count         1  
Time          2022-02-24 10:50:07  
Command line  /usr/libexec/xdg-desktop-portal-kde  
Package       xdg-desktop-portal-kde-5.24.1-1.fc36  
User id       1000 (depard)  
Path          /var/spool/abrt/ccpp-2022-02-24-10:50:07.2281-2383

It cannot be reported because "./coredump is not a coredump". Also, the retrace server does not work for Fedora 36.
By the way, this inability to retrace the branched Fedora is a problem we regularly face and that would tremendously help if retracing *was* possible. 

I also found out that restarting sddm using "systemctl start sddm" does not fix the problem and no SDDM is ready on TTY1. The system must be newly rebooted to make it work again.

Not to get sidetracked, but FWIW I don't think the issue there is with retracing, it's with the coredump generation - when I ran into that problem, I looked at the coredump and it was a 0-length file. So to me it seems like the issue's elsewhere in the whole abrt complex, whatever's generating the coredumps.

Did you check coredumpctl? That's a separate mechanism from abrt. Try `coredumpctl list`.

+4 in https://pagure.io/fedora-qa/blocker-review/issue/625 , marking accepted.

(In reply to Adam Williamson from comment #5)
> Not to get sidetracked, but FWIW I don't think the issue there is with
> retracing, it's with the coredump generation - when I ran into that problem,
> I looked at the coredump and it was a 0-length file. So to me it seems like
> the issue's elsewhere in the whole abrt complex, whatever's generating the
> coredumps.
> 
> Did you check coredumpctl? That's a separate mechanism from abrt. Try
> `coredumpctl list`.

I've seen Plasma 5.24.0-5.24.2 on Wayland log out to just a terminal login without sddm appearing sometimes in a Fedora 36 KDE Plasma installation with sddm-0.19.0^git20220130.85cbf3f-2.fc36. I've also seen sddm crash when logging in as a second user and Plasma didn't start with the same versions https://bugzilla.redhat.com/show_bug.cgi?id=2056308 The lack of core dumps in abrt on my system was because abrt-server ran coredumpctl which was denied reading the core dumps by SELinux as I reported at https://bugzilla.redhat.com/show_bug.cgi?id=2056200 These types of denials happened after crashes of maliit-keyboard, gutenprint53+usb https://bugzilla.redhat.com/show_bug.cgi?id=2055504 , plasmashell, xdg-desktop-portal-kde, and others with the same abrt errors and missing core dumps in gnome-abrt. The abrt server might not be able to accept reports for programs which produce core dumps because the core dumps are missing. The abrt error was Error: File './coredump' is not a coredump as Lukas mentioned. The crashes did appear in coredumpctl with the core dumps present.

sddm-0.19.0^git20220130.85cbf3f-2.fc36 on Wayland had the sddm-greeter crash like Lukas reported when I logged in to Plasma 5.24.2 on Wayland, but core dumps didn't appear in the journal or coredumpctl (possibly because the exit code was 1). sddm-greeter wasn't running, so when logging out of Plasma, sddm might not have been able to appear and the terminal login appeared instead.

Feb 24 21:25:35 sddm[982]: Error from greeter session: "Process crashed"
Feb 24 21:25:35 sddm[982]: Auth: sddm-helper (--socket /tmp/sddm-authcd9945e0-1eb0-42bf-9e33-f8790d43bc4d --id 2 --start /usr/bin/sddm-greeter --socket /tmp/sddm--HRhBLA --theme /usr/share/sddm/themes/breeze --user sddm --display-server kwin_wayland --no-lockscreen --inputmethod maliit-keyboard --greeter) crashed (exit code 1)
Feb 24 21:25:35 sddm[982]: Error from greeter session: "Process crashed"
Feb 24 21:25:35 sddm[982]: Auth: sddm-helper exited with 15
Feb 24 21:25:35 systemd-logind[869]: Session c1 logged out. Waiting for processes to exit.

The virtual keyboard maliit-keyboard in sddm on Wayland also didn't appear when I clicked on it. The Sleep, Restart, Shut down, Other options were missing unless I clicked on the virtual keyboard box. The screen flickered when clicking on the keyboard layout which was stuck on af or the desktop session setting. Some of these problems were reported at https://bugzilla.redhat.com/show_bug.cgi?id=2054016 https://bugzilla.redhat.com/show_bug.cgi?id=2055627 The sddm-greeter crash might be related to those graphical problems.

I switched from sddm on Wayland to sddm on X with sudo dnf swap sddm-wayland-plasma sddm-x11 as described at https://fedoraproject.org/wiki/Changes/WaylandByDefaultForSDDM I logged out of Plasma on Wayland to sddm on X normally, and the sddm-greeter crash wasn't shown in the journal. This problem might be specific to sddm on Wayland. I didn't see this logout problem with sddm-0.19.0-19.fc36 on X from koji either.

coredumpctl list -> No coredumps found.

Looks like openQA hit this too, now the bug that was preventing us getting this far in the tests is fixed:

https://openqa.fedoraproject.org/tests/1148410

we log in as one user, log out and expect to get back to SDDM, but instead we find ourselves at a tty.

It looks like there *might* be fixes in SDDM git develop, so let me prepare a new build to see if that helps.

FEDORA-2022-40bbeceace has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-40bbeceace

I've updated to 5ad9f19d958e69e9c3f08baa9161794ceafe4da7, can someone see if this helps?

At the advice of Aleix, I've backported another patch that's currently sitting as a PR. However, the update is currently locked, so here's the Koji build: https://koji.fedoraproject.org/koji/buildinfo?buildID=1924850

FEDORA-2022-40bbeceace has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-40bbeceace`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-40bbeceace

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

(In reply to Neal Gompa from comment #13)
> I've updated to 5ad9f19d958e69e9c3f08baa9161794ceafe4da7, can someone see if
> this helps?

With sddm on Wayland from sddm-0.19.0^git20220224.5ad9f19-1.fc36 and sddm-0.19.0^git20220224.5ad9f19-2.fc36, logging out of Plasma on Wayland showed the text login prompt or a black screen with a just a blinking cursor. With sddm on X from sddm-0.19.0^git20220224.5ad9f19-2.fc36, logging out of Plasma on Wayland showed sddm normally once or black screen with a blinking cursor twice. plasmashell, powerdevil, xdg-desktop-portal-kde sometimes aborted repeatedly when logging out of Plasma on Wayland with errors that the Wayland connection had broken. I'm unsure if those crashes are related.

FEDORA-2022-40bbeceace has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-40bbeceace`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-40bbeceace

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

This is still broken with the latest build from the update. Also, looking at the logs from that failure, sddm actually crashes shortly after the first login succeeds - it's already crashed long before we log out again. It should stay running the whole time, AIUI. I'll attach the log from the failed test of the update.

Created attachment 1863619 [details]
/var/log/messages from a failed test with sddm-0.19.0^git20220228.c257a40-1.fc36

Timings there: we hit 'enter' on the login screen at around 17:55:06, and reach the desktop around 17:55:20. We log out around 17:55:41. But sddm crashes at 17:55:17 - before the desktop even loaded fully.

As Lukas said, I can't find any coredump from the crash anywhere. /var/log/sddm.log has just a single line, from after the initial crash (around the time we log out):

[17:55:41.841] (EE) HELPER: Failed to take control of "/dev/tty2" ("root"): Operation not permitted

FEDORA-2022-40bbeceace has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-40bbeceace`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-40bbeceace

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

I updated the update with a build that has https://github.com/sddm/sddm/pull/1522 backported, and that looks like it fixes the problem in early testing here.

FEDORA-2022-40bbeceace has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-40bbeceace`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-40bbeceace

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2022-40bbeceace has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.