[systemd-devel] systemd-udevd and services with DefaultDependencies=no

Thomas HUMMEL thomas.hummel at pasteur.fr
Thu Nov 28 18:49:59 UTC 2024


On 11/25/24 3:07 PM, Thomas HUMMEL wrote:
> On 11/25/24 2:50 PM, Andrei Borzenkov wrote:
>> On Mon, Nov 25, 2024 at 4:39 PM Thomas HUMMEL 
>> <thomas.hummel at pasteur.fr> wrote:
>>>
>>> Hello,
>>>
>>> I've got a somehow silly question:
>>>
>>> Am I right to think that a service unit I wrote meant to format and
>>> mount a localdisk at boot having the following properties :
>>>
>>> Wants=local-fs.target
>>> Before=local-fs.target
>>>
>>> + DefaultDepenencies=no may be racing against udevd in a way the device
>>> (/dev/nvme0) would not be there yet ?
>>>
>>
>> Yes.
>>
>>> If so, would adding After=systemd-udevd suffice ?
>>>
>>
>> No.
>>
>> Either invoke your service from within udev rule (SYSTEMD_WANTS or
>> even systemctl start), or configure your service with
>>
>> Requires=dev-nvme0.device
>> After=dev-nvme0.device
>>
>> Actually, you probably want to do it even when invoking by udev rules.
>>
>> This assumes that /dev/nvme0 is reasonably stable. You may want to use
>> some other available /dev/disk/by-... stable alias.
> 
> Ok, thanks for your reply.
> 
> 

Hello,

coming back to the topic (sorry, I had an actual physical issue with the 
device which blurred my analysis):

1. On a system where /dev/nvme0, /dev/nvme0n1 and /dev/nvme0n1p1 files 
exist, systemctl list-units --type=device | grep -i nvme only list 
physical path ones such as 
sys-devices-pci0000:a0-0000:a0:03.1-0000:a1:00.0-nvme-nvme0-nvme0n1.device 
for instance.

Did you assume something I do not have by evoking dev-nvme.device ?

2. on the udev rule way of doing things:

man states:

"Starting daemons or other long-running processes is not appropriate for 
udev; the forked processes, detached or not, will be unconditionally 
killed after the event handling has finished."

and

"Note that running programs that access the network or mount/unmount 
filesystems is not allowed inside of udev rules, due to the default 
sandbox that is enforced on systemd-udevd.service."

What defines "event handling has finished". Typically the external 
program I'd consider running would be a) partition disk b) format (mkfs) 
disk : would that be considered a long-running process in the context of 
udev ?

Finally the last statement obviouly means my program could not - as the 
current service I'm using does - mount the partition - but this could be 
handled elsewhere

Thanks for your help

-- 
Thomas HUMMEL
HPC Group
Institut PASTEUR
Paris, FRANCE


More information about the systemd-devel mailing list