0

It has been confirmed that systemd timers won't start the .service if previous run hasn't finished. However, for unknown reason this blocks some Type=oneshot backup processes on my machine (they seem to still be in activating state, perhaps a race condition, but that's probably irrelevant).

If a systemd timer runs OnCalendar=hourly is there any way to tell it to run EVERY TIME regardless what happened in the previous runs (so to be sure backups will in face run and won't unexpectedly destroy everything you love)?

5
  • I'm having trouble understanding the question. Doesn't backup run, stop, run, stop, like every other process. Commented Aug 6, 2023 at 17:19
  • It should, but you know, sometimes things just don't work and you don't know why. In this case you still want to be sure that timers will continue to work, instead of like dying silently without any warning. Commented Aug 6, 2023 at 17:31
  • Backup progs vary greatly in quality, because they're so easy to write. I think Clonezilla is the best, and then bacula. Commented Aug 6, 2023 at 21:35
  • Type=oneshot units are always in "activating" state while doing their work; they skip "active" completely. Are you sure what you're seeing is actually a problem? Commented Aug 7, 2023 at 4:30
  • 1
    As far as I know: no. If you need this, you'll probably want to look at cron. Commented Aug 7, 2023 at 7:07

1 Answer 1

1

if a systemd timer runs OnCalendar=hourly is there any way to tell it to run EVERY TIME regardless what happened in the previous runs (so to be sure backups will in face run and won't unexpectedly destroy everything you love)?

Those timers actually DO their jobs and do run, they just don't "restart" the backup service they are meant to activate, because that service still has the trigger state of being "activated" or "active" in case it is still running...

  • To make it clear that the behavior is correct:
    1. What would you expect to happen when it actually did start another instance of the same service while the service in question was already running?
      Would it be acceptable to have two backup services run at same time and thus overwrite each other's files at same time in parallel?
      I think not right?
    2. You are trying to switch a light bulb "on" using button "B" while it already is "on" due to button "A", which of-course has no effect.

So...to make sure your timer "restarts" your service, make sure the backup service gets less than 1 hour time to finish and thus lose the active state... See RuntimeMaxSec= in man systemd.service for the explanation of that. Or use a longer timer if the backup does need more time, because a half or non finished backup is same as no backup at all right?

To give a better answer it would help if you posted the contents of those "Type=oneshot" backup service files, because i think they need changes anyhow.

5
  • Theoretically I agree, but practically processes like restic or rclone may get stuck for whatever reason in activating state causing you to lose backups. Commented Sep 5, 2023 at 21:58
  • For that reason I gave up on trying to use systemd timers for backups - it's just too unreliable. Rewrote it to a regular crontab job and it just works™. Commented Sep 5, 2023 at 21:59
  • RuntimeMaxSec makes sense until one day you have a massive backup on a slow internet connection that so just happens will take more than an hour to complete. Commented Sep 5, 2023 at 22:00
  • @Daniel, AFAIK systemd does automatic crontab translation to timer units. So are you sure cron is actually performing those self or does systemd indirectly? Commented Sep 6, 2023 at 8:44
  • I think so, it was necessary to install core/cron package (cronie) to run crontab -e and after removing .service and .timer units they no longer appear in the systemctl list-timers view. So I think it's cron/anacron now. Commented Sep 6, 2023 at 11:27

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.