281–290 of 309 posts
Earlier quoted context omitted.
You can add units programmatically. Google it!
Downvoting makes no sense. https://www.google.com/search?q=systemd+add+units+programmat... You can do it either via the CLI (systemd-run), or via the D-Bus API (StartTransientUnit).
SystemD has no dearth of programmable options.
Earlier quoted context omitted.
The first one works in that specific case, but not more generically. For example, "Last Monday in February", or "last Monday of the month" for multiple months unless they're all 30 or all 31 days.
This was fun to cook up and may (or may not!) break if one's locale changes: # Run a command on the last day of the month. Only starts checking at midnight towards the end of the month. Assumes GNU date, which is fair if we're discussing a Linux-only cron-alike. 0 0 28-31 * * if [ $(date +\%d) -eq $(date --date="$(date +\%m)/1 + 1 month - 1 day" +\%d) ]; then /usr/local/bin/runCommand.sh; fi I bet one could do someth…
It ultimately doesn't matter "for real", because almost nobody without some horrific legacy system to integrate with would need to use anything more than lists, ranges, and increments. There's a reason nobody's added these features to system crons. Clever trigger times for events that don't really need to be triggered at clever times... sure, but lacking that capability wouldn't change anything, the trigger would just be a more boring one.
Events like "last Friday of the month" or "nearest weekday to the 1st of the month" or even "Friday the 13th" are more for business logic, not system crontabs.
Earlier quoted context omitted.
b) Or you could take the compiled units from /etc/systemd and copy them wherever
I believe that probably won’t work unfortunately; the generated unit files have a bunch of hardcoded Nix store paths.
Earlier quoted context omitted.
You can add units programmatically. Google it!
Downvoting makes no sense. https://www.google.com/search?q=systemd+add+units+programmat... You can do it either via the CLI (systemd-run), or via the D-Bus API (StartTransientUnit).
I have tried available options including generators.
Earlier quoted context omitted.
I wouldn't say that the PATH is ambiguous , but cron does have some problems with PATH: - the default value is missing some values you would expect, like /use/local/bin and /usr/sbin for root. - on some distributions (for example Arch Linux) the man page doesn't even say what the default path is, or recommend setting it. - if you need to add something to the path for a single script, you either need to wrap it with a…
> - the default value is missing some values you would expect, like /use/local/bin and /usr/sbin for root. What do you mean by "you would expect", that doesn't also apply to systemd timers? /opt/foo/bin is not in the path. Would you expect that? And if this is an objective problem, can we just change the cron default PATH? > - on some distributions (for example Arch Linux) the man page doesn't even say what the defau…
I mean it should include things that are usually on the path, like /usr/local/bin. And for the root user it should include sbin.
I don't really expect /opt/foo/bin to be there, but if you want to have it available by default everywhere then you can just add it to systemd once, rather than having to remember to add it to crontab as well.
> Or on the line, right?
Oh you're right. I forgot cron evaluates the command with the shell (which has its own set of issues...)
> This is incorrect. You can definitely use $HOME in user crontabs.
You can in the command itself, because that is evaluated by a shell, but not when setting an environment variable. From the Ubuntu crontab(5) manpage:
> The value string is not parsed for environmental substitutions or replacement of variables or tilde(~) expansion
Maybe it depends on the cron implementation though. The cronie documentation doesn't say either way.
Earlier quoted context omitted.
> I found the systemd time spec syntax you referenced to be logical and well thought out. I found this amusing when in combination with > The only thing that threw me for a loop and seems like "special magic" was but -regardless- a careful reader notes that I never said that the Timer scheduling syntax was illogical or poorly thought out. It's at least as complicated as crontab-style time syntax, which was my entire…
Obviously you can do additional time & date checking in a shell wrapping the script or binary cron ultimately runs, just as you could do the time & date checking in the script or binary itself. That's far more complex. Systemd enables cleaner, simpler syntax for common cases. Instead of "59 23 * * *", simply "23:59". Instead of "0 0 * * sun[day]", simply "sun[day]". 1st of the month and don't care exactly what time?…
I disagree. It's all a matter what you're accustomed to. On top of that, what's at least as important as clear syntax for simple cases is the establishing of a handful of rules that well serve both the simple and complex cases. Consistency that leads to complicated cases being made easy should not be avoided just to make the simple cases extremely welcoming to the newcomer. Note that I'm not saying that 'systemd-crond' falls into this trap, but I am saying that oh so many tools that aim to be "approachable by newcomers" enthusiastically throw themselves into it.
> Cron syntax is more of a mess than I thought.
Nah. It's just there are a very large number of cron implementations. If The Systemd Project were actually a thing that people could make an independent reimplementation of, we'd see at least as much inconsistency in 'systemd-cron' scheduling syntax as people extended it in their reimplementations to meet their needs.
> What would you prefer for 3rd friday of the month? Cron (5-field, quartz syntax)
I don't understand why the "day of month" column has a "?" instead of a "*", and I don't understand why "fri#3" isn't rendered as "Fri/3", but whatevz. I prefer that to the systemd syntax.
FWIW, I think you can directly translate your systemd scheduler line into this for most crons:
* * 15-21 * Fri
Note: The day of a command’s execution can be specified in the following two fields — ’day of month’, and ’day of week’. If both
fields are restricted (i.e., do not contain the "*" character), the command will be run when either field matches the current time.
For example,
"30 4 1,15 * 5" would cause a command to be run at 4:30 am on the 1st and 15th of each month, plus every Friday.
Earlier quoted context omitted.
This was fun to cook up and may (or may not!) break if one's locale changes: # Run a command on the last day of the month. Only starts checking at midnight towards the end of the month. Assumes GNU date, which is fair if we're discussing a Linux-only cron-alike. 0 0 28-31 * * if [ $(date +\%d) -eq $(date --date="$(date +\%m)/1 + 1 month - 1 day" +\%d) ]; then /usr/local/bin/runCommand.sh; fi I bet one could do someth…
I am curious whether there's a more capable system cron that supports that kind of thing. Quartz job scheduler (java), AWS, and CF obviously wouldn't qualify. I think this is only possible if you're using a heavyweight job scheduler like those. Or... systemd. It ultimately doesn't matter "for real", because almost nobody without some horrific legacy system to integrate with would need to use anything more than lists,…
I am no cron scholar, nor am I young enough to have the energy required to do an exhaustive survey... so -sadly- I don't know of one. It seems like there'd be one being used internally in at least one business in the world, though, yanno? That just seems like the sort of thing that at least one bored programmer would take a few days to crank out.
> Events like "last Friday of the month" or "nearest weekday to the 1st of the month" or even "Friday the 13th" are more for business logic, not system crontabs.
Oh quite possibly, yeah. But, system crons are quite fine for one-shot things that are re-run on a regular schedule... as well as things that don't have complicated scheduling and/or retry requirements. If you're working on a Big Enterprise Project [0], then you're almost certainly going to have a scheduler inside of you, and -IME- you're very likely to use it to do a lot of that BEP's scheduled tasks. [1]
[0] Or a tiny one wearing the clothes of a BEP
[1] ...if for no other reason than it requires little effort to get the BEP's data and code into its internal scheduler, and can be a huge pain in the ass to get it into an external one.
Earlier quoted context omitted.
Has it actually served you well? Because it hasn't served me well at all. I am not the biggest fan of systemd, but today I will always reach for a systemd timer over cron simply due to the sheer amount of bad experiences I've had with cron. Hours upon hours wasted trying to troubleshoot crons that weren't working due to some stupid obscure issue, having to use dirty hacks to monitor for success or retry failed jobs.…
Let me state once again: "within its very clear limitations". Once you learn that env in cron is not same as in your shell and once you learn to redirect output to loggers - it works just fine. It would be a lie to say that I never debugged cron and sure it's annoying. > and the script just died halfway through for no reason Unrelated to cron. Bad script.
Earlier quoted context omitted.
Let me state once again: "within its very clear limitations". Once you learn that env in cron is not same as in your shell and once you learn to redirect output to loggers - it works just fine. It would be a lie to say that I never debugged cron and sure it's annoying. > and the script just died halfway through for no reason Unrelated to cron. Bad script.
If the script is bad, surely cron will give you a way to test that? Right? Right??????
Earlier quoted context omitted.
> $PATH is one thing when cron runs and another when you try out the command yourself. Why would that be different with systemd timers? If my ~/.bashrc adds /opt/foo/bin, that's also not part of the systemd timer's PATH, right? But I guess you're saying the ability to trigger the systemd timer off-schedule is the difference? Yeah, it's annoying with cron to have to temporarily set the trigger two minutes into the fut…
>But I guess you're saying the ability to trigger the systemd timer off-schedule is the difference? Yeah, it's annoying with cron to have to temporarily set the trigger two minutes into the future. :-P >Not sure adding that feature justifies a complete rewrite, but certainly a nice addition. If there is a feature that justifies using a completely different tool it's obviously this one.
You should not see a missing killer feature and go directly to the conclusion of rewriting.
Sure, greenfield is fun. So there's that.