251–260 of 309 posts
Earlier quoted context omitted.
> That's true, but most people don't know the numbered manual sections, so they get the docs for the cron table command not the cron table config file. No `man man`? ;)
Man Man: the man with the strength of two men.
I haven't used systemd timers enough to disagree, but > Ambiguous $PATH settings make cron script execution difficult to predict. What makes you say that? You can set the PATH right in the crontab. Is that harder to "predict" than it being set in /etc/bashrc, ~/.bashrc, ~/.profile, ~/.bash_profile, /etc/systemd/…, or wherever else? > You might feel cool knowing the scheduling grammar by heart I've used Linux since 19…
problem with vars is that they apply to any subsequent entry in the file so you need to take that into consideration; the nice thing about timers is that all settings are self contained and not affected by previous entries. The standard /10 and similar cron expressions also have thundering herd problem when on bunch of servers, tho some variants like in Jenkins use variant H/10 (H standing for hash) where the thing i…
There will always be a default. Is systemd timer's default inherently correct for all users any more than cron's is?
I'm just playing devil's advocate here, but why not just change cron, then? Good for the goose is good for the gander?
I haven't used systemd timers enough to disagree, but > Ambiguous $PATH settings make cron script execution difficult to predict. What makes you say that? You can set the PATH right in the crontab. Is that harder to "predict" than it being set in /etc/bashrc, ~/.bashrc, ~/.profile, ~/.bash_profile, /etc/systemd/…, or wherever else? > You might feel cool knowing the scheduling grammar by heart I've used Linux since 19…
> What makes you say that? You can set the PATH right in the crontab. OK but I don't want to hardcode $PATH in the crontab just so I can test the cronjob. Barring the hardcode, $PATH is one thing when cron runs and another when you try out the command yourself. systemctl start foo.service starts the command inside with the same environment as when the timer fires so you know it'll work the same. On the flip side, you…
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 future. :-P
Not sure adding that feature justifies a complete rewrite, but certainly a nice addition.
> due to logic bugs in systemd
Yeah my main gripe with systemd and other Lennartware is the extremely low implementation quality, not necessarily the ideas. Though the idea of killing tmux/screen on logout is downright criminal. And the fd passing nonsense[1] for system services is clearly just the idea of a child that found a tool and is misusing it.
[1] which is an awesome and underused feature (https://blog.habets.se/2025/10/The-strange-webserver-hot-pot...), but completely misapplied by systemd.
I haven't used systemd timers enough to disagree, but > Ambiguous $PATH settings make cron script execution difficult to predict. What makes you say that? You can set the PATH right in the crontab. Is that harder to "predict" than it being set in /etc/bashrc, ~/.bashrc, ~/.profile, ~/.bash_profile, /etc/systemd/…, or wherever else? > You might feel cool knowing the scheduling grammar by heart I've used Linux since 19…
> You can set the PATH right in the crontab. Yes, but people don't. I've had to debug other's crontabs many times over the last umpteen years.
Two environments that set the PATH differently won't have the same value set, either way.
Is this about "yes, but cron doesn't let me trigger through its environment, and systemd timers do"?
I haven't used systemd timers enough to disagree, but > Ambiguous $PATH settings make cron script execution difficult to predict. What makes you say that? You can set the PATH right in the crontab. Is that harder to "predict" than it being set in /etc/bashrc, ~/.bashrc, ~/.profile, ~/.bash_profile, /etc/systemd/…, or wherever else? > You might feel cool knowing the scheduling grammar by heart I've used Linux since 19…
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…
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 default path is, or recommend setting it.
Send a PR. This doesn't seem like an inherent problem.
> - if you need to add something to the path for a single script, you either need to wrap it with a call to env, set it in a wrapper script, or set the path before the entry and reset it afterwards
Or on the line, right?
* * * * * FOO=bar $HOME/bin/foo.sh
> - you can't use ~ or $HOME in the path, you have to write out the full absolute path. Which is particularly annoying for user crontabs.
This is incorrect. You can definitely use $HOME in user crontabs.
I'm still not seeing something that warrants a rewrite. (except what you did not mention, which is the ability to run "trigger this now" as a missing feature)
Earlier quoted context omitted.
Epson Ecotank. I’ve been using mine for years and I only had to buy new ink once. And I printed a lot of photos, notes, documents, etc
Those will still get their nozzles clogged if you don't run them.
The only bad thing is that it can get messy if you select the wrong paper type and the ink will not be absorbed by the paper, making the rollers dirty. That’s annoying but fixable, and preventable by not selecting the wrong paper type.
Earlier quoted context omitted.
>The conversation from the core devs ran through the pattern that one gets used to seeing when one runs into SystemD bugs that are caused by extremely complex unanticipated interactions between parts of the project >SystemD contains an enormous -and ever-growing- amount of accidental complexity, and has a set of core maintainers who are generally disinterested in either documenting the places where one or more comple…
> ... imagine my surprise to learn that Systemd was causing my long standing frustration with changing my dns settings. and further surprise to learn that server admins have this same issue and many switch away from using systemd-resolved. That's introductory course to systemd's shenanigans. People are going to tell you that you're not doing it properly, that there's of course this setting (unless that other setting…
Did you know that it will convert the answer to a relative query [0] that has generated an NXDOMAIN into a REFUSED? It doesn't do this for fully-qualified queries, and it doesn't do this for relative queries that return something other than NXDOMAIN.
Why do they do this... even if ALL of the resolvers configured in resolved return NXDOMAIN for the query? «Because we believe that the standards say that resolvers can return REFUSED for any reason at all. This is any reason. Now get lost.». Why don't they do this for fully-qualified queries? «chirping cricket noises»
[0] I think this might also be known as a "zero dots" query. Assume that your DHCP-provided search domain is home.arpa. You can do 'ping pc' and every resolver I remember using will convert that hostname into 'pc.home.arpa' and do a lookup with that name, rather than the one you entered.
systemd is complex on first view, but after using it you didn't want to use anything else. It's handy to manage everything using systemctl
There are still some weird things/choices in its design I don't fully understand. For example, why do unit definitions have to be actual files on disk? Then, all of these files are reloaded when the daemon reloads, not just changed ones. But, why couldn't there be an API letting me add units programmatically? (There kind of is but it's constrained/inflexible) Or, why can't I declare multiple units in the same file? I…
Earlier quoted context omitted.
I designed a tool for flying. It's only designed for flying. It is based on the principles of the brick.
Cron. Initial release May 1975; 51 years ago It is succesfully flying 51 year. And will work next 50 years. Systemd probably will changes syntax in next 2 years. Modern development mindset: if tool is not rewritten last month - it is outdated and we need to reinvent it. Probably using blockchanin and AI.
Earlier quoted context omitted.
I found the systemd time spec syntax you referenced to be logical and well thought out. Cron syntax is simpler for the easy cases because cron tries to do less. It ignores years and seconds entirely, and doesn't try to adhere roughly to ISO8601 ordering and field separators, instead using space universally for field separation and euro-style least-to-most significant field ordering. I like ISO8601, so I get along wit…
> But good luck doing that in one line in cron. Two options: 0 0 25-31 5 1 or, if your cron supports „L“: 0 0 L 5 1