Return to Answer

The timer will say Trigger: n/a as long as the unit it triggers is still running. It will not attempt to schedule a service service which is already running. The timer trigger will be set for the next appropriate time when the service stops.

If it takes 12 minutes for your mail.service to execute, the timer will trigger it once, the service will execute for 12 minutes, then the timer will schedule it 3 minutes later, causing 15 minutes between the calls.

Here's an example:

# mytime.service [Service] Type=oneshot ExecStart=/bin/sleep 10 # mytime.timer [Timer] OnCalendar=*:0/1 

When I systemctl start mytime.timer we will see this:

$ systemctl --user status mytime.timer mytime.service ● mytime.timer - Test timer Active: active (waiting) since Sat 2021-06-12 10:56:01 CEST; 725ms ago Trigger: Sat 2021-06-12 10:57:00 CEST; 59s left ● mytime.service Active: inactive (dead) 

While the service is executing, we will see:

$ systemctl --user status mytime.timer mytime.service ● mytime.timer - Test timer Active: active (running) since Sat 2021-06-12 10:56:01 CEST; 1min ago Trigger: n/a ● mytime.service Active: activating (start) since Sat 2021-06-12 10:57:00 CEST; 10ms ago CGroup: /user.slice/user-1000.slice/[email protected]/app.slice/mytime.service └─11346 /bin/sleep 10 

Then after once sleep 10 has exited, the trigger will be set:

$ systemctl --user status mytime.timer mytime.service ● mytime.timer - Test timer Active: active (waiting) since Sat 2021-06-12 10:56:01 CEST; 1min 11s ago Trigger: Sat 2021-06-12 10:58:00 CEST; 49s left ● mytime.service Active: inactive (dead) since Sat 2021-06-12 10:57:10 CEST; 1s ago Process: 11346 ExecStart=/bin/sleep 10 (code=exited, status=0/SUCCESS) 

The timer will say Trigger: n/a as long as the unit it triggers is still running. It will not attempt to schedule a service service which is already running. The timer trigger will be set for the next appropriate time when the service stops.

If it takes 12 minutes for your mail.service to execute, the timer will trigger it once, the service will execute for 12 minutes, then the timer will schedule it 3 minutes later, causing 15 minutes between the calls.

So, the answer is "be patient". When mail.service completes, then it will start again at the next 5 min timepoint.

Here's an example:

# mytime.service [Service] Type=oneshot ExecStart=/bin/sleep 10 # mytime.timer [Timer] OnCalendar=*:0/1 

When I systemctl start mytime.timer we will see this:

$ systemctl --user status mytime.timer mytime.service ● mytime.timer - Test timer Active: active (waiting) since Sat 2021-06-12 10:56:01 CEST; 725ms ago Trigger: Sat 2021-06-12 10:57:00 CEST; 59s left ● mytime.service Active: inactive (dead) 

While the service is executing, we will see:

$ systemctl --user status mytime.timer mytime.service ● mytime.timer - Test timer Active: active (running) since Sat 2021-06-12 10:56:01 CEST; 1min ago Trigger: n/a ● mytime.service Active: activating (start) since Sat 2021-06-12 10:57:00 CEST; 10ms ago CGroup: /user.slice/user-1000.slice/[email protected]/app.slice/mytime.service └─11346 /bin/sleep 10 

Once sleep 10 has exited, the trigger will be set:

$ systemctl --user status mytime.timer mytime.service ● mytime.timer - Test timer Active: active (waiting) since Sat 2021-06-12 10:56:01 CEST; 1min 11s ago Trigger: Sat 2021-06-12 10:58:00 CEST; 49s left ● mytime.service Active: inactive (dead) since Sat 2021-06-12 10:57:10 CEST; 1s ago Process: 11346 ExecStart=/bin/sleep 10 (code=exited, status=0/SUCCESS) 

The timer will say Trigger: n/a as long as the unit it triggers is still running. It will not attempt to start a running service. The timer trigger will be set for the next appropriate time when the service stops.

If it takes 12 minutes for your mail.service to execute, the timer will trigger it once, the service will execute for 12 minutes, then the timer will schedule it 3 minutes later, causing 15 minutes between the calls.

Here's an example:

# mytime.service [Service] Type=oneshot ExecStart=/bin/sleep 10 # mytime.timer [Timer] OnCalendar=*:0/1 

When I systemctl start mytime.timer we will see this:

$ systemctl --user status mytime.timer mytime.service ● mytime.timer - Test timer Active: active (waiting) since Sat 2021-06-12 10:56:01 CEST; 725ms ago Trigger: Sat 2021-06-12 10:57:00 CEST; 59s left ● mytime.service Active: inactive (dead) 

While the service is executing, we will see:

$ systemctl --user status mytime.timer mytime.service ● mytime.timer - Test timer Active: active (running) since Sat 2021-06-12 10:56:01 CEST; 2min ago Trigger: n/a ● mytime.service Active: activating (start) since Sat 2021-06-12 10:58:01 CEST; 10ms ago CGroup: /user.slice/user-1000.slice/[email protected]/app.slice/mytime.service └─11346 /bin/sleep 10 

Then after once sleep 10 has exited, the trigger will be set:

$ systemctl --user status mytime.timer mytime.service ● mytime.timer - Test timer Active: active (waiting) since Sat 2021-06-12 10:56:01 CEST; 2min 11s ago Trigger: Sat 2021-06-12 10:59:00 CEST; 49s left ● mytime.service Active: inactive (dead) since Sat 2021-06-12 10:58:11 CEST; 1s ago Process: 11346 ExecStart=/bin/sleep 10 (code=exited, status=0/SUCCESS) 

The timer will say Trigger: n/a as long as the unit it triggers is still running. It will not attempt to schedule a service service which is already running. The timer trigger will be set for the next appropriate time when the service stops.

If it takes 12 minutes for your mail.service to execute, the timer will trigger it once, the service will execute for 12 minutes, then the timer will schedule it 3 minutes later, causing 15 minutes between the calls.

Here's an example:

# mytime.service [Service] Type=oneshot ExecStart=/bin/sleep 10 # mytime.timer [Timer] OnCalendar=*:0/1 

When I systemctl start mytime.timer we will see this:

$ systemctl --user status mytime.timer mytime.service ● mytime.timer - Test timer Active: active (waiting) since Sat 2021-06-12 10:56:01 CEST; 725ms ago Trigger: Sat 2021-06-12 10:57:00 CEST; 59s left ● mytime.service Active: inactive (dead) 

While the service is executing, we will see:

$ systemctl --user status mytime.timer mytime.service ● mytime.timer - Test timer Active: active (running) since Sat 2021-06-12 10:56:01 CEST; 1min ago Trigger: n/a ● mytime.service Active: activating (start) since Sat 2021-06-12 10:57:00 CEST; 10ms ago CGroup: /user.slice/user-1000.slice/[email protected]/app.slice/mytime.service └─11346 /bin/sleep 10 

Then after once sleep 10 has exited, the trigger will be set:

$ systemctl --user status mytime.timer mytime.service ● mytime.timer - Test timer Active: active (waiting) since Sat 2021-06-12 10:56:01 CEST; 1min 11s ago Trigger: Sat 2021-06-12 10:58:00 CEST; 49s left ● mytime.service Active: inactive (dead) since Sat 2021-06-12 10:57:10 CEST; 1s ago Process: 11346 ExecStart=/bin/sleep 10 (code=exited, status=0/SUCCESS) 

The timer will say Trigger: n/a as long as the unit it triggers is still running. It will not attempt to start a running service. The timer trigger will be set for the next appropriate time when the service stops.

If it takes 12 minutes for your mail.service to execute, the timer will trigger it once, the service will execute for 12 minutes, then the timer will schedule it 3 minutes later, causing 15 minutes between the calls.

Here's an example:

# mytime.service [Service] Type=oneshot ExecStart=/bin/sleep 10 # mytime.timer [Timer] OnCalendar=*:0/1 

When I systemctl start mytime.timer we will see this:

$ systemctl --user status mytime.timer mytime.service ● mytime.timer - Test timer Active: active (waiting) since Sat 2021-06-12 10:56:01 CEST; 725ms ago Trigger: Sat 2021-06-12 10:57:00 CEST; 59s left ● mytime.service Active: inactive (dead) 

While the service is executing, we will see:

$ systemctl --user status mytime.timer mytime.service ● mytime.timer - Test timer Active: active (running) since Sat 2021-06-12 10:56:22 CEST; 1min 38s ago Trigger: n/a ● mytime.service Active: activating (start) since Sat 2021-06-12 10:58:01 CEST; 10ms ago CGroup: /user.slice/user-1000.slice/[email protected]/app.slice/mytime.service └─11346 /bin/sleep 10 

Then after once sleep 10 has exited, the trigger will be set:

$ systemctl --user status mytime.timer mytime.service ● mytime.timer - Test timer Active: active (waiting) since Sat 2021-06-12 10:56:22 CEST; 1min 53s ago Trigger: Sat 2021-06-12 10:59:00 CEST; 44s left ● mytime.service Active: inactive (dead) since Sat 2021-06-12 10:58:11 CEST; 4s ago Process: 11346 ExecStart=/bin/sleep 10 (code=exited, status=0/SUCCESS) 

The timer will say Trigger: n/a as long as the unit it triggers is still running. It will not attempt to start a running service. The timer trigger will be set for the next appropriate time when the service stops.

If it takes 12 minutes for your mail.service to execute, the timer will trigger it once, the service will execute for 12 minutes, then the timer will schedule it 3 minutes later, causing 15 minutes between the calls.

Here's an example:

# mytime.service [Service] Type=oneshot ExecStart=/bin/sleep 10 # mytime.timer [Timer] OnCalendar=*:0/1 

When I systemctl start mytime.timer we will see this:

$ systemctl --user status mytime.timer mytime.service ● mytime.timer - Test timer Active: active (waiting) since Sat 2021-06-12 10:56:01 CEST; 725ms ago Trigger: Sat 2021-06-12 10:57:00 CEST; 59s left ● mytime.service Active: inactive (dead) 

While the service is executing, we will see:

$ systemctl --user status mytime.timer mytime.service ● mytime.timer - Test timer Active: active (running) since Sat 2021-06-12 10:56:01 CEST; 2min ago Trigger: n/a ● mytime.service Active: activating (start) since Sat 2021-06-12 10:58:01 CEST; 10ms ago CGroup: /user.slice/user-1000.slice/[email protected]/app.slice/mytime.service └─11346 /bin/sleep 10 

Then after once sleep 10 has exited, the trigger will be set:

$ systemctl --user status mytime.timer mytime.service ● mytime.timer - Test timer Active: active (waiting) since Sat 2021-06-12 10:56:01 CEST; 2min 11s ago Trigger: Sat 2021-06-12 10:59:00 CEST; 49s left ● mytime.service Active: inactive (dead) since Sat 2021-06-12 10:58:11 CEST; 1s ago Process: 11346 ExecStart=/bin/sleep 10 (code=exited, status=0/SUCCESS)