Control: found -1 249.7-1 Control: severity -1 important
Am 12.01.22 um 18:20 schrieb Christian Weeks:
I don't see anything in the journal, I've had a fairly long look. I do not have the coredump utility installed. As I have mentioned, rebooting fixed whatever caused the problem during the upgrade, so I have no idea how I can help you further. In looking at my running system since, I notice that systemd isn't defaulting to running, so I guess the problem was actually that dbus was failing to activate systemd properly, during the upgrade. I have found a core file, but it's dated from 10 days ago, not today, which is weird. There was no activity on the computer at the time, I believe, and this went unnoticed, perhaps for 10 days?!
As said, systemd freezes execution when it crashes. If PID 1 actually crashed, the kernel would panic and you'd notice :-)
Jan 2 10:14:48 cheesypuffs kernel: [336844.954825] systemd[1]: segfault at 18 ip 000055bd29c926ea sp 00007ffdcd0c56c8 error 4 in systemd[55bd29c38000+d9000] ls -l /core -rw------- 1 root root 22482944 Jan 2 10:14 /core I can share this core file with you if you wish (how?), though perhaps it's not so related to the upgrade anymore?
Given the timestamps match, it's pretty certain, that the core file belongs to the segfault. It also shows that PID 1 crashing is not actually affecting the running services. As long as you don't interact with systemd (e.g. via systemctl), your system should continue to run fine.
I'm thus downgrading the severity.As it is not actually related to the upgrade, I'm marking it as found in 249.7-1.
You can attach the core file to the bug report (gzipped) or mail it to me directly. I will try to see if a backtrace reveals something.
Michael
OpenPGP_signature
Description: OpenPGP digital signature
