I’ve already read the thread about this subject may 2025 (exactly the same “problem” here), but I couldn’t understand if there is some kind of permanent remedy to get sddm to behave in a decent way. Anyone who knows?
Sorry, but this is very difficult to interpret, let alone to start helping.
When you want to communicate that a command has some output, then please copy paste that (the command, all output) her (as code/preformatted text) so we can see what you saw.
And pointing to some other thread without providing the link is also not very helpful.
@Abigail_Donovan So this is really about sddm crashing rather than the last command output?
OK, sorry if I were unclear. I’ll try to explain what I’m after here.
Up to Leap 15.6 the command lastnever reported about crashes in tty’s. Since Leap 16.0 it does. I use last with the same options I’ve run it with in 15.6:
last -n 20 -i -awxF
What makes last tell me about crashes, as far as I can understand, after every boot?
shutdown system down Thu Apr 9 21:48:57 2026 - Thu Apr 9 21:49:16 2026 (00:00) 6.12.0-160000.27-default
root tty1 Thu Apr 9 21:46:52 2026 - Thu Apr 9 21:48:18 2026 (00:01)
reboot system boot Thu Apr 9 21:46:28 2026 - Thu Apr 9 21:48:22 2026 (00:01) 6.12.0-160000.27-default
shutdown system down Thu Apr 9 21:48:22 2026 - Thu Apr 9 21:48:41 2026 (00:00) 6.12.0-160000.27-default
marcus tty2 Thu Apr 9 21:34:43 2026 - crash :0
reboot system boot Thu Apr 9 21:34:24 2026 - Thu Apr 9 21:45:37 2026 (00:11) 6.12.0-160000.27-default
shutdown system down Thu Apr 9 21:45:37 2026 - Thu Apr 9 21:46:28 2026 (00:00) 6.12.0-160000.27-default
marcus tty2 Thu Apr 9 21:12:55 2026 - crash :0
reboot system boot Thu Apr 9 21:12:38 2026 - Thu Apr 9 21:33:18 2026 (00:20) 6.12.0-160000.27-default
It seems that only tty2 is affected. When I bypass X (ctrl+alt+F1, tty1) there is no crash.
This might not be severe and everything appears to be working in good order, but still it’s annoying. And I can’t understand why.
Hmm – your X / KDE session is probably running on tty2. Maybe that’s just a message from KDE that you ended the session. And 15.6 is using a different version of KDE.
Note that I am guessing here. I see the “crash” on tty3, which is where my Wayland-KDE session is running. Maybe I try a login to Icewm, and see if there are “crash” entries for that.
I tried with Icewm. There is no “crash” entry in the “last” output from that session. So it does seem to be from KDE.
I tried it here:
boven:~ # last -n 20 -i -awxF
henk tty1 Tue Apr 21 09:09:32 2026 - still logged in
reboot system boot Tue Apr 21 07:46:14 2026 - still running 6.12.0-160000.27-default
henk tty1 Mon Apr 20 09:08:39 2026 - Mon Apr 20 21:45:37 2026 (12:36)
reboot system boot Mon Apr 20 07:47:58 2026 - Mon Apr 20 22:46:10 2026 (14:58) 6.12.0-160000.27-default
shutdown system down Mon Apr 20 22:46:10 2026 - Tue Apr 21 07:46:14 2026 (09:00) 6.12.0-160000.27-default
henk tty1 Sun Apr 19 11:45:14 2026 - Sun Apr 19 22:07:04 2026 (10:21)
reboot system boot Sun Apr 19 11:34:11 2026 - Sun Apr 19 22:46:11 2026 (11:11) 6.12.0-160000.27-default
shutdown system down Sun Apr 19 22:46:11 2026 - Mon Apr 20 07:47:58 2026 (09:01) 6.12.0-160000.27-default
reboot system boot Sun Apr 19 07:37:04 2026 - Sun Apr 19 07:46:11 2026 (00:09) 6.12.0-160000.27-default
shutdown system down Sun Apr 19 07:46:11 2026 - Sun Apr 19 11:34:11 2026 (03:48) 6.12.0-160000.27-default
henk tty1 Sat Apr 18 09:10:56 2026 - Sat Apr 18 20:37:18 2026 (11:26)
reboot system boot Sat Apr 18 08:07:33 2026 - Sat Apr 18 22:36:10 2026 (14:28) 6.12.0-160000.27-default
shutdown system down Sat Apr 18 22:36:10 2026 - Sun Apr 19 07:37:04 2026 (09:00) 6.12.0-160000.27-default
henk tty1 Fri Apr 17 08:58:15 2026 - Fri Apr 17 22:13:48 2026 (13:15)
reboot system boot Fri Apr 17 08:16:20 2026 - Fri Apr 17 22:48:30 2026 (14:32) 6.12.0-160000.27-default
shutdown system down Fri Apr 17 22:48:30 2026 - Sat Apr 18 08:07:33 2026 (09:19) 6.12.0-160000.27-default
henk tty1 Thu Apr 16 12:11:33 2026 - Thu Apr 16 20:46:45 2026 (08:35)
reboot system boot Thu Apr 16 12:01:23 2026 - Thu Apr 16 22:26:11 2026 (10:24) 6.12.0-160000.27-default
shutdown system down Thu Apr 16 22:26:11 2026 - Fri Apr 17 08:16:20 2026 (09:50) 6.12.0-160000.27-default
reboot system boot Thu Apr 16 07:34:33 2026 - Thu Apr 16 07:46:11 2026 (00:11) 6.12.0-160000.27-default
shutdown system down Thu Apr 16 07:46:11 2026 - Thu Apr 16 12:01:23 2026 (04:15) 6.12.0-160000.27-default
henk tty1 Wed Apr 15 12:20:11 2026 - Wed Apr 15 20:54:18 2026 (08:34)
reboot system boot Wed Apr 15 12:15:05 2026 - Wed Apr 15 22:30:46 2026 (10:15) 6.12.0-160000.27-default
shutdown system down Wed Apr 15 22:30:46 2026 - Thu Apr 16 07:34:33 2026 (09:03) 6.12.0-160000.27-default
henk tty1 Wed Apr 15 08:10:08 2026 - crash
reboot system boot Wed Apr 15 07:57:18 2026 - Wed Apr 15 08:54:33 2026 (00:57) 6.12.0-160000.27-default
shutdown system down Wed Apr 15 08:54:33 2026 - Wed Apr 15 12:15:05 2026 (03:20) 6.12.0-160000.27-default
henk tty1 Tue Apr 14 08:40:45 2026 - Tue Apr 14 21:44:59 2026 (13:04)
reboot system boot Tue Apr 14 08:39:41 2026 - Tue Apr 14 22:36:11 2026 (13:56) 6.12.0-160000.27-default
shutdown system down Tue Apr 14 22:36:11 2026 - Wed Apr 15 07:57:18 2026 (09:21) 6.12.0-160000.27-default
wtmpdb begins Tue Apr 14 08:39:41 2026
boven:~ #
My conclusion: it does not happen normally on this system, but there is one on 2026-04-15. I know I was testing things around CLI and GUI logins about week ago, thus that may be it.
I also think I noticed (but I am not certain) that after 15.6 > 16.0 the usage of the virtual consoles changed. Thus that might influence things when you are using them regularly with certain assumptions.
All a bit vague, but maybe it helps.
If you are using KDE you might check if it is sddm:
journalctl |grep -A 1 SDDM::Auth::ERROR_INTERNAL
FWIW, I see it on GNOME, possibly a wayland issue…
I see this with KDE/Plasma in the journal for wayland sessions e.g.
Apr 21 18:58:04 blitz sddm[1457]: Authentication error: SDDM::Auth::ERROR_INTERNAL "Process crashed"
Apr 21 18:58:04 blitz sddm[1457]: Auth: sddm-helper (--socket /tmp/sddm-auth-2ee1b42f-805e-4f24-b998-22f779e0d4a1 --id 1 --start /usr/libexec/plasma-dbus-run-session-if-needed /usr/bin/startplasma-wayland --user rolf) crashed (exit code 1)
and X11 sessions
Apr 21 19:56:11 blitz sddm[1458]: Authentication error: SDDM::Auth::ERROR_INTERNAL "Process crashed"
Apr 21 19:56:11 blitz sddm[1458]: Auth: sddm-helper (--socket /tmp/sddm-auth-84b80922-706b-4836-87e3-48e809f478a4 --id 9 --start /usr/bin/startplasma-x11 --user rolf) crashed (exit code 1)
on multiple Leap 16.0 machines. This correleats with crash messages from the last command on tty2 for X11 and tty1 or tty3 for Wayland sessions. This occurs regardless if the machine was migrated from 15.6 or new installed. I have ignored it so far, as I have not noticed any other effects besides the messages in the journal and the last command.
I did just what you recommended me to do, and this is a part (from the latest boots) of the output:
apr 22 15:20:33 Thorax sddm[1083]: Authentication error: SDDM::Auth::ERROR_INTERNAL "Process crashed"
apr 22 15:20:33 Thorax sddm[1083]: Auth: sddm-helper (--socket /tmp/sddm-auth-d72477e0-382c-4871-b9c7-19d305442984 --id 1 --start /usr/bin/startplasma-x11 --user marcus) crashed (exit code 1)
apr 22 15:20:33 Thorax sddm[1083]: Authentication error: SDDM::Auth::ERROR_INTERNAL "Process crashed"
apr 22 15:20:33 Thorax sddm[1083]: Auth: sddm-helper exited with 1
--
apr 22 16:52:45 Thorax sddm[1089]: Authentication error: SDDM::Auth::ERROR_INTERNAL "Process crashed"
apr 22 16:52:45 Thorax sddm[1089]: Auth: sddm-helper (--socket /tmp/sddm-auth-1786bd0e-d283-461a-af17-632da9ed1fa5 --id 1 --start /usr/bin/startplasma-x11 --user marcus) crashed (exit code 1)
apr 22 16:52:45 Thorax sddm[1089]: Authentication error: SDDM::Auth::ERROR_INTERNAL "Process crashed"
apr 22 16:52:45 Thorax sddm[1089]: Auth: sddm-helper exited with 1
--
apr 23 14:55:42 Thorax sddm[1082]: Authentication error: SDDM::Auth::ERROR_INTERNAL "Process crashed"
apr 23 14:55:42 Thorax sddm[1082]: Auth: sddm-helper (--socket /tmp/sddm-auth-66ceb41c-8d54-4ba6-b26e-ae64c10096dd --id 1 --start /usr/bin/startplasma-x11 --user marcus) crashed (exit code 1)
apr 23 14:55:42 Thorax sddm[1082]: Authentication error: SDDM::Auth::ERROR_INTERNAL "Process crashed"
apr 23 14:55:42 Thorax sddm[1082]: Auth: sddm-helper exited with 1
--
apr 23 17:51:38 Thorax sddm[1085]: Authentication error: SDDM::Auth::ERROR_INTERNAL "Process crashed"
apr 23 17:51:39 Thorax avahi-daemon[795]: Leaving mDNS multicast group on interface wlp3s0.IPv4 with address 192.168.154.67.
--
apr 23 17:51:38 Thorax sddm[1085]: Authentication error: SDDM::Auth::ERROR_INTERNAL "Process crashed"
apr 23 17:51:39 Thorax avahi-daemon[795]: Leaving mDNS multicast group on interface lo.IPv4 with address 127.0.0.1.
--
apr 26 14:12:45 Thorax sddm[1084]: Authentication error: SDDM::Auth::ERROR_INTERNAL "Process crashed"
apr 26 14:12:45 Thorax sddm[1084]: Auth: sddm-helper (--socket /tmp/sddm-auth-bb690033-946d-4fe8-8b21-b152f761f5f6 --id 1 --start /usr/bin/startplasma-x11 --user marcus) crashed (exit code 1)
apr 26 14:12:45 Thorax sddm[1084]: Authentication error: SDDM::Auth::ERROR_INTERNAL "Process crashed"
apr 26 14:12:45 Thorax sddm[1084]: Auth: sddm-helper exited with 1
But still, I don’t know how to interpret it correctly. The executable startplasma-x11 seems to be the culprit here. Should I change to Wayland? If so, can somebody be kind enough to tell me how to do that? In the directory /usr/bin there is another executable, startplasma-wayland.
Should I consider the messages about crashes as merely a “cosmetic” issue?
Maybe it isn’t an issue at all. It’s just a piece of information that a session ended in an unexplained way. Use it as you wish.
1 Like
The problem is that these sdd-helpers fail to signal that the user sessions ends if triggred on shutdown/reboot. With a plasma wayland session you would probably see log messages for startplasma-wayland instead of startplasma-x11 (this at least what i see on all of my Leap/Tumbleweed machines when i try this via sddm with plasma wayland session) . These programms do not realy crash there is no coredump. They try to signal to the system that the user session ends now and get an error because the user session is alredy shutting down and so the sdd-helper mistakenly assumes that the session has been crashed. As a sideeffect no session end is writen to the wtmp.db that is used by the last command. So the last command finds sessions without a proper session end entry in wtmp.db and also assumes that the session has been crashed.
So the final conclusion is that there is nothing to worry nor care about? Still, I dislike it.
In my opinion it is unpleasant but harmless.
When I run “last” on one of my Leap 16.1 installs … every entry shown contains “crash” (except for the “reboot” entries).
…
BTW, to the folks watching this “last” command thread.
The commands “last” and “lastb” are being deprecated.
A number of distros ( Ubuntu, Debian, …) have ALREADY removed them. It’s because the “utmp” and “btmp” files are not Y2038-safe.
I just executed “lastb” (16.1) and it responds with, “command not found”.
Then I tried, “zypper in lastb” and got, “No provider of ‘lastb’ found”.
Funny … the FreeBSD team has already migrated last and lastb to be Y2038-compliant.
Well my Leap 16.0 last command is from package wtmpdb:
> rpm -qf /usr/bin/last
wtmpdb-0.74.0+git20250509.272b109-160000.2.2.x86_64
It does not provide lastb but it seems Y2038-compliant
> LANG=C zypper info wtmpdb
Loading repository data...
Reading installed packages...
Information for package wtmpdb:
-------------------------------
Repository : repo-oss (16.0)
Name : wtmpdb
Version : 0.74.0+git20250509.272b109-160000.2.2
Arch : x86_64
Vendor : SUSE LLC <https://www.suse.com/>
Installed Size : 94.2 KiB
Installed : Yes (automatically)
Status : up-to-date
Source package : wtmpdb-0.74.0+git20250509.272b109-160000.2.2.src
Upstream URL : https://github.com/thkukuk/wtmpdb
Summary : Database for recording the last logged in users and system reboots
Description :
pam_wtmpdb and wtmpdb are Y2038-safe versions of wtmp and the last
utility. pam_wtmpdb collects all data in a sqlite3 database and the
wtmpdb utility creates boot and shutdown entries or formats and
prints the contents of the wtmp database.
The “wtmpdb” package package supplies a symlink for “last” to “wtmpdb”.
At a command prompt, type “which last” and check if it’s a symlink 
The long-time “util-linux” package NO LONGER provides last and lastb. Any doubts?? Visit the “util-linux” github home site.
Lot’s more info - 'Net search, “linux is lastb deprecated”