0) I d like to hear what our dear user(s) think about this matter
or more generally about systemd-cron before going further.
John:
I see that you use a "cron-monthly-000loaddelay.timer",
and I guess it's purpose from it's name;
and this workflow may need to be tweaked;
the /etc/cron.{hourly|daily|monthly}/ are not anymore
run in sequence through a single run-parts invocation;
but through individual .timer / .service pairs.
1) I mixed up "1" and "2" in my last sentence:
I still prefer not to gratuitously break
past assumptions without a clear gain.
I think that the risk that some user start by themselves moving around
some programs
around the PATH directories and expect nothing to break is quiet moot.
And I'm pretty sure I/we already broke some scripts everywhere without
caring too much.
I do was using boot_daily directly from /lib/systemd/ ;
that broke when the scripts were moved to /usr/libexec:
https://www.mail-archive.com/debian-devel@lists.debian.org/msg377086.html
This guy using mail_on_failure has certainly some .service to adapt now:
https://bugs.launchpad.net/ubuntu/+source/systemd-cron/+bug/1583743
But on the other hand having this exact path of the launched program
in the generated .service make it much easier to debug.
> Concretely, we already killed stuff like this:
> in the C++ rewrite as "brittle damage" ‒
> https://github.com/systemd-cron/systemd-cron/pull/101#issuecomment-1673266966.
The comment was about the removed part.
> IMO we should trim the whole function ... KSH_SHELLS
The ~/ path expansion was requested and provided by wavexx
and is a really nice feature and will stay.
> needless magic (like this)
generators are mostly built on magic by design;
if people would not want automagic solution
they would had been writing .service / .timer pairs
for ten years already.
I'd like to close this bug before 2.1.2-1 hit testing.
Waiting for other bugs to pop up in the short time window :-)
Cheers
