System.d service scheduled at specific time but being triggered after login

Support
1

Hello,

I have created a system.d time unit to trigger a backup of my home folder but I am seeing a minor issue with it. The issue I see is that the script is being run as soon as log into my laptop and not respecting the scheduled times (weekdays at 09:00 and 15:00).
I had initially used @daily with Persistence in my .timer file, but I had seen a couple of failures with that approach (I suspect it was because the network was not ready when the script was running, thus I changed it to scheduled times).

Anyway, this is the status output showing that it ran at 08:33:38 and triggered by backup-data.timer:

$ systemctl --user status backup-data.service                                          ✔ 
â—‹ backup-data.service - A job to backup the /home folder using borg
     Loaded: loaded (/home/rmoledo/.config/systemd/user/backup-data.service; enabled; vendor preset>
     Active: inactive (dead) since Thu 2022-05-19 08:33:38 CEST; 15min ago
TriggeredBy: â—Ź backup-data.timer
    Process: 1263 ExecStart=/usr/bin/sh /home/rmoledo/workspace/scripts/backup.sh (code=exited, sta>
   Main PID: 1263 (code=exited, status=0/SUCCESS)
        CPU: 8.338s

And this is the content of backup-data.timer

$ cat .config/systemd/user/backup-data.timer
[Unit]
Description=Schedule a daily backup of /home folder using borg

[Timer]
OnCalendar=Mon..Fri *-*-* 09:00:00
OnCalendar=Mon..Fri *-*-* 15:00:00
Unit=backup-data.service

[Install]
WantedBy=timers.target

I did systemctl --user daemon-reload (and the laptop has been rebooted many times since then as well) and the timer scheduling works fine, but it still annoys me that the backup is also triggered when I log in as that should not be happening…

$ systemctl --user list-timers
NEXT                         LEFT          LAST PASSED UNIT              ACTIVATES          
Thu 2022-05-19 09:00:00 CEST 2min 54s left n/a  n/a    backup-data.timer backup-data.service

1 timers listed.

Any ideas as to what the issue might be?

Thanks.

2

That line is cut off, but it does look like you explicitly enabled the service?

3

You don’t need to enable the service because it will be started by the timer. So you must disable the service:
systemctl --user disable backup-data.service

The problem is that systemd will see that the timer needed to run in the meantime, so it start it as soon as possible.
Usually, that is disabled with the Persistent=false setting. (Which is the default, so it’s not needed.)

1 Like
4

The problem is misconfigured .service file. OP probably has [Installed]section which enables him to enable the service. So it runs after whichever target he has specified in .service PLUS when .timer expires.

This is a .timer setting and as you say, if enabled, it runs .service right after the boot if computer was off when the service should actually run. But this isn’t OP’s problem.

5

You are correct. Let’s wait for OP to check our suggestions.

6

So, the problem seemed to be that I had enabled the .service besides the .timer! I have disabled the .service and after rebooting my laptop, I see that the script has not been triggered this time after log in to my account.
Thanks!

7

The .service file is this one:

$ cat .config/systemd/user/backup-data.service
[Unit]
Description=A job to backup the /home folder using borg

[Service]
Type=oneshot
ExecStart=/usr/bin/sh /home/rmoledo/workspace/scripts/backup.sh

[Install]
WantedBy=default.target
8

As I said, services triggered by timers shouldn’t have this section at all.

9

Got it, thanks for your feedback!

10

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.