Bug#1051805: systemd-cron: shell redirect not working in crontab entries

[наб]

On Wed, Sep 13, 2023 at 12:00:51AM +0200, Alexandre Detiste wrote:
> 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.
I don't. Users love putting stuff in /usr/local/{,s}bin. And then
removing it. That's kinda what it's there for. Not a huge ask to have
"@daily nodejs pee poo" behave correctly regardless of whether I
recently (un)installed upstream node (not a hypothetical scenario).

> 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
Don't use random undocumented internals challenge 2020
(difficulty degree: impossible).

> But on the other hand having this exact path of the launched program
> in the generated .service make it much easier to debug.
To debug when it inevitably breaks because it's hard-coded
instead of being behind a path lookup like was written ‒ certainly.

If only we could put a big banner somewhere with the full job
definition in systemd! Then we wouldn't need to resort to this aid; alas.

And this is moot anyway since we only inline single-word programs,
so we could only do this transformation for single-word programs.
I cannot imagine anything that would be affected if we do /that/,
since there aren't any programs that are useful when you run them with
no arguments from a crontab /and/ you're managing them like that.

I.e. prefix
  if(auto pgm = this->which(this->command[0]); pgm && *pgm != this->command[0]) {
with
  if(this->command.size() == 1)
and you get maximum optimisation and usefulness without
‒ realistically ‒ any of the oddities.

> >  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.
Yes, leave /that/ in, and axe everything after that imo.
That's my idyllic take.

> > 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.
They want to run the shell program they wrote where a >/dev/null is the
same as a>/dev/null is the same as a> /dev/null is the same as
a > /dev/null; is the same as a > /dev/null && : is the same as…

Just because it's driving a generator instead of a persistent daemon
doesn't make the configuration any less configurationy.

(This also means that a>/dev/null may mean four different things:
   '/bin/a>/dev/null'
   /bin/sh -c 'a>/dev/null'
   /bin/a
   /bin/sh -c 'a'
 but. y'know. No-one calls programs this.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20230913/24cc96f4/attachment-0001.sig>