I'm going crazy with these timers

hi, first the timer :

falke@falke-macbookair72 user]$ more sauvED.timer 
Description=timer pour activer le shell SauveED 

OnCalendar=*_*_* 22:25:00


My problem :

… it is supposed to trigger a service (which launches a shell in an infinite loop, which stops however with an internal shell check of the time)

if I launch this shell manually, it exits at the desired time. Launched with cron programming, it also works. P

the problem is that with management via systemd timers, my shell as you see it now (1:55 p.m.) is not supposed to launch. And yet, it does ! I don’t understand it anymore. Maybe the timer syntax is wrong?

Could you please help me? Thanks

1 Like

Maybe yes.

systemd-analyze calendar --iterations=5 '*_*_* 22:25:00'
Failed to parse calendar specification '*_*_* 22:25:00': Μη έγκυρη παράμετρος


systemd-analyze calendar --iterations=5 '*-*-* 22:25:00'
Normalized form: *-*-* 22:25:00
    Next elapse: Thu 2023-06-29 22:25:00 EEST
       (in UTC): Thu 2023-06-29 19:25:00 UTC
       From now: 5h 18min left
   Iteration #2: Fri 2023-06-30 22:25:00 EEST
       (in UTC): Fri 2023-06-30 19:25:00 UTC
       From now: 1 day 5h left
   Iteration #3: Sat 2023-07-01 22:25:00 EEST
       (in UTC): Sat 2023-07-01 19:25:00 UTC
       From now: 2 days left
   Iteration #4: Sun 2023-07-02 22:25:00 EEST
       (in UTC): Sun 2023-07-02 19:25:00 UTC
       From now: 3 days left
   Iteration #5: Mon 2023-07-03 22:25:00 EEST
       (in UTC): Mon 2023-07-03 19:25:00 UTC
       From now: 4 days left

Would I be rude if I said RTFMMMM? :rofl:

Σας ευχαριστώ :smile:,

I omitted to correct the _ in - before posting :

out of desperation I put underscores,

but it didn’t work with - either.

Would I be rude if I said RTFMMMM? :rofl:

yes, I think so, on a user-friendly forum :wink:



I sleep with this under my pillow :sweat_smile:

What is the corresponding service file? Is it type oneshot or does it relaunch when the main process exits?

Yes, but we also provide education to new users. RTFM means that most answers are found when manuals and wikis/docs are carefully read. :wink:

The Manual suggests

See systemd.time(7) for more information on the syntax of calendar event expressions.

which, among exhausting explanations and examples, says

Use the timestamp command of systemd-analyze(1) to validate and normalize timestamps for testing purposes.

Testing is the main tool for a dev. If after successfully testing the time value that you insert in the unit’s OnCalendar key, the unit doesn’t work, then we have a bug.

ok, could you retest that please, allways false … I cannot see what’s wrong

Description=timer pour activer le shell SauveED 

OnCalendar='*-*-* 23:50:00'


service name is sauvED.service

I regret to say that is not possible, since I have no access to your machine.
Would you mind testing it yourself, since you obviously have access to it?

I guess it is already proven I was not rude at all… :crying_cat_face:

then, I don’t understand or I’m tired, could you check the syntax in your first answer ??

good morning,

I’m relaunching, because my units are correctly configured and working.

The problem is the same: the timer task starts even though the start time has not yet arrived.

it’s a unit --user but I have the impression that it’s the system that takes control of what I want to do.

In my service unit, however, I’ve tested two solutions,

Required by timer.target ou default.target

you’re right, let’s be constructive,
the shell launched is a loop with an exit condition based on the time (to respect the rules of prudence concerning infinite processes).

I want to start it every morning with systemd and I’ve created the timer and service units for that.

It works with cron, which is what I use at work. So ok.

I’m just trying to understand (as a personal curiosity) why the process starts automatically before the hour with systemd at home.

One solution would be to remove the internal shell timer, and start/stop the service with systemd itself.

I have absolutely no idea how your script or systemd files look like because you have not shared them yet.
But the minimum functionality that you describe can be achieved with this.

Description = does not matter

OnCalendar = *-*-* 22:25:00

WantedBy = timers.target
Description = does not matter

Type = oneshot
ExecStart = /usr/bin/some_script

while [ "$(date '+%H:%M:%S')" != "19:15:05" ]; do
    sleep 1
    # do some stuff

You have to enable the timer systemctl enable sauvED.timer (not the service).
If there is more in your files then you have to share it because otherwise we can only guess.

I have cleaned up this topic. Please try to keep the conversation focused on the problem with this script/service/timer.

1 Like

great! You really helped me out :slight_smile:

the problem came from the fact that I thought that once the (service) timer and the service calling the shell had been activated, both had to be enabled in order to work. Stupid mistake. As a result, it wasn’t the timer itself that activated the service ahead of time, but the service itself!

Quick question: if I want to do without the shell’s internal timer to stop the task, I’d have to create a timer.enable and a timer.disable to activate the timersauvED?

I’m putting my two configuration files here, can you tell me if they’re well written?

# The timer
Description=timer pour activer le shell SauveED 

OnCalendar=*-*-* 11:55:00

# The service 
Description=Mon script de sauvegarde avec boucle infinie



This is not right. A systemd timer requires corresponding service file but you do not enable the service. You only enable the timer. Therefore there should be no Requires=sauvED.timer and neither [Install] section nor WantedBy= (maybe in some special case but I have never used it).
If you have [Install] in the service and you enable the service then the service starts as soon as your computer starts which means the timer is pointless.
Arch wiki is a good reference for the systemd timers.

Not timer.enable/timer.disable more like 2 timers exec script/killall script. But then you have to solve a problem how to gracefully kill the scipt.
Timer.enable and timer.disable only set a trigger condition. So if enabled then the service will run when the system clock reach OnCalendar=*-*-* 11:55:00 and when you call systemctl disable SauveED.timer it will not trigger next day at 11:55:00 but also it will not kill already running SauveED.service.

But I think this may be an XY-problem.
What is running in your script that has to start on a precise time (with timer) and stop at a different time? I would assume a normal condition for a script to stop is when all the work is done. Having a timestamp for a script termination is unusual for me.

I would also recommend to use type oneshot.


If you do not specify type then it is Type=simple. The advantage of oneshot is that it is blocking and you can get some info whether the script is running or returned with an error by running systemctl status sauvED.service. And you should be able to kill the script by also calling systemctl stop sauvED.service.

What is running in your script that has to start on a precise time (with timer) and stop at a different time? I would assume a normal condition for a script to stop is when all the work is done. Having a timestamp for a script termination is unusual for me.

here’s what the script does:

users create edit files. These grow in size as editions are requested. When the user finally decides to print on the printer, they disappear once the print job is complete. This is my problem, as I’d like to be able to retrieve this file and start editing myself. This allows me to create a prn file with all the editions of a user, which I convert into a pdf. These pdfs are then sent to a number of users in pj format.

If ever the user makes the mistake of launching the edition, I lose track of the document allowing me to work. That’s why my shell works like a daemon that sniffs the edition files of a certain number of selected users, making an incremental backup, allowing me to get my hands on their file if ever a print is launched by mistake. However, I want to take a few precautions to ensure that this shell doesn’t mobilize resources unnecessarily beyond a day’s work, and then return the next day for a new day.


Thanks for these very detailed explanations.

I have the impression that the management of such a situation is manageable but quite complex with systemd.

In a context of using systemd timers, it seems to me that it’s better to stick to a timer to start, and let the script manage the output, based on an internal timer. This way, you can be sure that it will finish correctly. However, an error can always occur in between, in which case there are no logs (…?) .

Well, I wanted to test the pros/cons / cron/systemd. And in this case the cron task seems much simpler to maintain.

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