network & systemd timers (e.g. reflector, archlinux-keyring-wkd-sync)

cfr · 2022-12-18 02:34:48

Some systemd timers run services which require the network e.g. reflector and archlinux-keyring-wkd-sync. It quite often happens on my machine that no network is available when the associated services are run. As a result, the service fails, but the timer unit still counts the service as having been appropriately run. This means that it will be another week before the service is triggered again, at which time the service may again fail.

In almost all cases, my laptop is only off the network for a brief time, but I still see cases where jobs have not actually run for two or more weeks.

Now, obviously, I can always run the jobs manually, but that means I have to remember to check what the timers have done and there is not even a quick at-a-glance method of doing this. Moreover, it somewhat undermines the point of using timers, which is precisely that my computer is better at remembering to do things than I am.

What is a good way of managing these kinds of services on a laptop in this kind of situation? Or are systemd timers not really the best tool for the job?

What I want is that the service gets triggered again in a few hours, say, if it fails due to some transient condition, such as lack of network.

Last edited by cfr (2022-12-18 02:36:07)

seth · 2022-12-18 11:07:38

https://unix.stackexchange.com/question … nnectivity but I guess that won't cut it for cases where a flaky network (or any other condition) fails the execution of the service.
So you probably want to "harden" the service itself against interim failure, either by having it eg.

while ! ping -qc1 google.com > /dev/null 2>&1; do sleep 1; done

or allow the service to restart: https://stackoverflow.com/questions/392 … 30-seconds

cfr · 2022-12-18 14:48:23

So, as a first step, I'd want something like

[Unit]
Description=Refresh Pacman mirrorlist weekly with Reflector.
After=network-online.target

[Timer]
OnCalendar=weekly
Persistent=true
AccuracySec=1us
RandomizedDelaySec=12h

[Install]
WantedBy=timers.target

and

[Unit]
Description=Refresh existing PGP keys of archlinux-keyring regularly
After=network-online.target

[Timer]
OnCalendar=weekly
Persistent=true
RandomizedDelaySec=1week

[Install]
WantedBy=timers.target

Is the appropriate method to create new reflector.timer and archlinux-keyring-wkd-sync.timer files under /etc somewhere and then to install those after removing the current versions? I guess I'm not meant to edit the original files.

Unless it would be appropriate to request this change as a feature request? I guess it would be useful for other people running Arch on laptops, for example?

saf1 · 2022-12-18 15:07:17

cfr wrote:

Is the appropriate method to create new reflector.timer and archlinux-keyring-wkd-sync.timer files under /etc somewhere and then to install those after removing the current versions? I guess I'm not meant to edit the original files.
Unless it would be appropriate to request this change as a feature request? I guess it would be useful for other people running Arch on laptops, for example?

You can create a drop-in files

3beb6e7c46a615a · 2022-12-18 15:10:22

Can't you use "systemctl edit" on these units to create override files?

But I'm not sure whether this improves things at lot. Even if dependencies on timer units work like you intend (I'm not sure), it'd still fail on unreliable or walled networks (e.g. captive portals, proxies, etc.)

I'd rather fix this the other way around: Don't try to make the timer units fail-safe. Instead try to start the services whenever you connect to reliable networks, i.e. write a network manager dispatcher script (provided you use network manager) to start the reflector and keyring sync services whenever you're connected to your stable home or work networks.

cfr · 2022-12-18 16:04:29

saf1 wrote:

You can create a drop-in files

These are great. I think I need to relearn systemd as it seems to have sprouted facilities since I tried to get to grips with it originally. Thank-you.

lunaryorn wrote:

I'd rather fix this the other way around: Don't try to make the timer units fail-safe. Instead try to start the services whenever you connect to reliable networks, i.e. write a network manager dispatcher script (provided you use network manager) to start the reflector and keyring sync services whenever you're connected to your stable home or work networks.

Thanks for the systemctl edit suggestion. I didn't know about that. I don't use network manager, but netctl. (Even though I use KDE - network manager is masked.) However, I'm not quite sure how this would work since it wouldn't make sense to refresh the keyring and mirrors (and whatever else) every time I connect to a particular network. Nor does being on my home LAN guarantee internet access. Both the ISP's service and the ISP's router are on the flaky side. To workaround that, I'd need something like seth's suggestion, but I figure I can at least make the timer units a bit more robust in the meantime.

Last edited by cfr (2022-12-18 16:07:38)

Arch Linux

#1 2022-12-18 02:34:48

network & systemd timers (e.g. reflector, archlinux-keyring-wkd-sync)

#2 2022-12-18 11:07:38

Re: network & systemd timers (e.g. reflector, archlinux-keyring-wkd-sync)

#3 2022-12-18 14:48:23

Re: network & systemd timers (e.g. reflector, archlinux-keyring-wkd-sync)

#4 2022-12-18 15:07:17

Re: network & systemd timers (e.g. reflector, archlinux-keyring-wkd-sync)

#5 2022-12-18 15:10:22

Re: network & systemd timers (e.g. reflector, archlinux-keyring-wkd-sync)

#6 2022-12-18 16:04:29

Re: network & systemd timers (e.g. reflector, archlinux-keyring-wkd-sync)

Board footer