[systemd-devel] Antw: Re: Mutually exclusive (timer-triggered) services

[Ulrich Windl]

>>> Alexander Koch <mail at alexanderkoch.net> schrieb am 15.10.2019 um 21:48 in
Nachricht <39b05185c3bdf699f7f00c23e0a4a9a5 at alexanderkoch.net>:
>> > * flock leaves the lock file behind so you'd need some type of
>>> cleanup in case you really want the jobs to be trace-free. This is
>>> not as trivial is it might seem, e.g. you cannot do it from the
>>> service units themselves in `ExecStartPost=` or similar.
>> An
>> 
>> ExecStartPost=-/usr/bin/flock -F /path/to/lock.file \
>>               /usr/bin/rm /path/to/lock.file
>> 
>> should solve this issue.
> 
> So you can remove a file other processes are blocked lock-waiting on? 
> Didn't
> expect this to work, thanks for the hint.

It's a common misconception (especially when grown up with Windows) that "rm" removes a file: Actually it "unlinks" the name from the inode. As long as the inode is opened by the kernel, the file (as seen from the kernel's perspective) still exists.

> 
>> If your units are actually dependent on each other, than maybe you
>> should think about your approach in general. But to be able to help you
>> with that we need more information about the actual dependencies of the
>> applications started by your units and at which interval they shall
>> run.
> 
> Okay I guess I should come up with the actual scenario, here we go:
> 
> On my Arch Linux workstation I've got three .timer triggered .service 
> units
> that do package manager housekeeping (I don't know if you're familiar 
> with
> Arch/Pacman so I'll annotate their purposes):
> 
> 1) Synchronize package database (equivalent of `apt-get update` on 
> Debian)
> 
>      [Timer]
>      OnCalendar=8-17/2:00
>      Persistent=true
> 
>      [Service]
>      ExecStart=/usr/bin/pacman -Syq
> 
> 2) Update file database (equivalent of `apt-file update`)
> 
>      [Timer]
>      OnCalendar=weekly
>      Persistent=true
> 
>      [Service]
>      ExecStart=/usr/bin/pacman -Fyq
> 
> 3) Purge old packages from cache (something like `apt-get autoclean`)
> 
>      [Timer]
>      OnCalendar=daily
>      Persistent=true
> 
>      [Service]
>      ExecStart=/bin/sh -c 'paccache -r -k 2; paccache -r -k 0 -u'
> 
> As you can see, I'd like to have different execution intervals for all 
> of
> these tasks so I'd like to keep them as separate services (which also 
> seems
> the intuitive approach to me).
> 
> I must admit that I haven't tried, but I'm pretty sure that at least 1 
> and
> 2 do lock the ALPM database so if you try to issue one of these Pacman 
> calls
> while the other is running it will fail, complaining about a lock file 
> being
> present.
> 
> My current workaround for this is using `RandomizedDelaySec=15m` in
> conjunction with `AccuracySec=1` in the .timer units to spread the 
> triggers.
> 
> While this does work I'm really curious about the 'proper' way of 
> modeling
> this. Is it such an academic problem to have the need of ensuring that 
> two
> timers (or services) don't fire simultaneously? I had thought this to be
> really simple with such an elaborate service manager like systemd, with 
> all
> its graph theory power and the-like.
> 
> (If I were a heretic I'd say 'We can do DNS, DHCP and NTP with systemd
> without any third party software but we need additional utilities to 
> ensure
> that two things don't happen at the same time??' ;) )
> 
> I think there are plenty of other scenarios, e.g. ideally I'd like my 
> backup
> service not to kick in while btrfs-scrub at home.service is running... or 
> maybe
> it's just me seeing this need ;)
> 
> 
> Best regards,
> 
> Alex
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org 
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel