alt Hacker News> $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 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.
Replies
>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.
> Why would that be different with systemd timers?
Because you can test if systemctl start foo.service works and if it does, you know it'll work when foo.timer triggers it.
> my main gripe with systemd and other Lennartware is the extremely low implementation quality
It doesn't stack up that poorly against other projects but it's unacceptably low for a core system component.