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

[Andrei Borzenkov]

28.11.2024 21:49, Thomas HUMMEL wrote:
> 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 ?
> 

Try

systemctl -t device -a

> 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
> 

I never suggested doing it from within udev rule. I suggested starting 
systemd service which runs outside of event handler.