3 ms·

That’s true. But once you get it set up, you can check the status, see when it last ran, when it will run next, the logs from the last run, if it failed last ti

by pkulak 2y ago

That’s true. But once you get it set up, you can check the status, see when it last ran, when it will run next, the logs from the last run, if it failed last time, why, etc. You can stop it, start it, restart it, disable it. Simeone just needs to write some CLI for making really simple timers.

johnchristopher 2y ago
> Simeone just needs to write some CLI for making really simple timers. That's a post-it or a simple-systemd-timers.txt though. Don't bother Simeone with that :).
- pkulak 2y ago
  lol. I must have been on mobile.
fragmede 2y ago
Open a terminal and then in bash: while true; do date; ./doit.sh; sleep 300; done | tee doit.log if you want to get fancy, you can do: date "+%Y.%M.%dT%H:%m:%s-%Z`./doit.sh`" to get it all on one line.
- zitsarethecure 2y ago
  For doing things like this I like using the "watch" command.
- fodkodrasz 2y ago
  Yeah, it is almost at feature parity. The following bloat is not needed at all: 1. Ensure commands are ran after you close the terminal you just opened. 2. Trigger actions when the process did fail (OnFailure=) 3. ensure the scheduling job survives system restarts 4. have proper scheduling, and handling of missed schedule doe to downtime (eg. for notebooks) 5. run the process in cgoups, under other user's context, or in a chroot, etc. 6. apply randomized jitter to the schedule to avoid crating overload and cascading failures resulting from that 7. Timing out tasks 8. Handle service dependencies... just to name few from the top of my head... cron is great, and systemd timers are also good, and even more refined solution to the task scheduling problem. Your propsal does not solve even the basics (configurable schedule). As other comment notes your script is more like the watch command.
MrDrMcCoy 2y ago
Don't forget one of the best reasons timers are great: they won't cause long-running jobs to overlap. I can't tell you how many systems I've had to unbreak because a job took too long and spiraled out of control.

by pkulak 2y ago

johnchristopher 2y ago

> Simeone just needs to write some CLI for making really simple timers. That's a post-it or a simple-systemd-timers.txt though. Don't bother Simeone with that :).

pkulak 2y ago
lol. I must have been on mobile.

fragmede 2y ago

Open a terminal and then in bash: while true; do date; ./doit.sh; sleep 300; done | tee doit.log if you want to get fancy, you can do: date "+%Y.%M.%dT%H:%m:%s-%Z`./doit.sh`" to get it all on one line.

zitsarethecure 2y ago
For doing things like this I like using the "watch" command.
fodkodrasz 2y ago
Yeah, it is almost at feature parity. The following bloat is not needed at all: 1. Ensure commands are ran after you close the terminal you just opened. 2. Trigger actions when the process did fail (OnFailure=) 3. ensure the scheduling job survives system restarts 4. have proper scheduling, and handling of missed schedule doe to downtime (eg. for notebooks) 5. run the process in cgoups, under other user's context, or in a chroot, etc. 6. apply randomized jitter to the schedule to avoid crating overload and cascading failures resulting from that 7. Timing out tasks 8. Handle service dependencies... just to name few from the top of my head... cron is great, and systemd timers are also good, and even more refined solution to the task scheduling problem. Your propsal does not solve even the basics (configurable schedule). As other comment notes your script is more like the watch command.

MrDrMcCoy 2y ago

Don't forget one of the best reasons timers are great: they won't cause long-running jobs to overlap. I can't tell you how many systems I've had to unbreak because a job took too long and spiraled out of control.