falke@falke-macbookair72 user]$ more sauvED.timer
[Unit]
Description=timer pour activer le shell SauveED
[Timer]
OnCalendar=*_*_* 22:25:00
[Install]
WantedBy=timers.target
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?
systemd-analyze calendar --iterations=5 '*_*_* 22:25:00'
Failed to parse calendar specification '*_*_* 22:25:00': Μη έγκυρη παράμετρος
Repaired:
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
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.
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…
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.
sauvED.timer
[Unit]
Description = does not matter
[Timer]
OnCalendar = *-*-* 22:25:00
[Install]
WantedBy = timers.target
sauvED.service
[Unit]
Description = does not matter
[Service]
Type = oneshot
ExecStart = /usr/bin/some_script
/usr/bin/some_script
#!/bin/bash
while [ "$(date '+%H:%M:%S')" != "19:15:05" ]; do
sleep 1
# do some stuff
done
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.
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
[Unit]
Description=timer pour activer le shell SauveED
[Timer]
OnCalendar=*-*-* 11:55:00
[Install]
WantedBy=timers.target
# The service
[Unit]
Description=Mon script de sauvegarde avec boucle infinie
Requires=sauvED.timer
[Service]
ExecStart=/home/falke/Bureau/tst_verif_proprio_et_sauv.sh
[Install]
WantedBy=default.target
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 runningSauveED.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.
[Service]
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.
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.
,
