[systemd-devel] systemd-devel Digest, Vol 178, Issue 26

Joanne Norman joanne.norman at spectralogic.com
Wed Feb 26 16:16:40 UTC 2025


> Date: Sat, 22 Feb 2025 08:22:18 +0300
> From: Andrei Borzenkov <mailto:arvidjaar at gmail.com>
> To: mailto:systemd-devel at lists.freedesktop.org
> Subject: Re: [systemd-devel] PID 1 "crashes" during boot, disabling
> systemd-coredump, but system boots normally anyway
> Message-ID: <mailto:c8218ba6-2ead-4649-ad1d-14b72eb7a578 at gmail.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed

>> root at intel-corei7-64:~# coredumpctl info 102
>> PID: 102 (udevd)
>> UID: 0 (root)
>> GID: 0 (root)
>> Signal: 6 (ABRT)
>> Timestamp: Thu 2025-02-20 22:29:28 UTC (30min ago)
>> Command Line: udevd --daemon
>> Executable: /usr/bin/udevadm
>> Control Group: /init.scope
>> Unit: init.scope

>This is the reason for this message. Normally only systemd itself should 
>be in this cgroup. How exactly do you start systemd?

In the process of trying to answer this question, I believe I have resolved
the issue. As it turns out, our Linux distribution uses a customized initramfs 
which was scripted incorrectly - it starts `udevd --daemon` first thing followed 
by some udevadm commands to populate the device tree, but failed to 
terminate udevd before calling switch_root to launch the real /sbin/init. 
Simply adding `udevadm control -e` to the script in question appears to have 
fixed the issue. Feeling lucky(?) that disabled coredumps were the *only*
symptom...

Thank you and the others in this message thread for putting me on the right trail!

PS. Apologies if this reply doesn't thread correctly; I'm not familiar with 
how to properly interact with mailing lists like these.



More information about the systemd-devel mailing list