4 ms·

> 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. Barr

> 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, your cron job will run at the time you specify in the crontab. Your systemd timer, on the other hand, may fire at the specified time (and most of the time, it will), but it can also suddenly stop firing once it has fired on a February 29th and then never fire again, due to logic bugs in systemd, or it may or may not fire when you "restart" the timer unit, due to logic bugs in systemd (that's when it only has OnCalendar, so yes, definitely a bug).

thomashabets2 4mo ago
> $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-potato-sending-file-descriptors.html https://blog.habets.se/2025/10/The-strange-webserver-hot-pot...), but completely misapplied by systemd.
- imtringued 4mo ago
  >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.
  - thomashabets2 4mo ago
    Are you making the assumption that it's impossible to add that feature to cron? You should not see a missing killer feature and go directly to the conclusion of rewriting. Sure, greenfield is fun. So there's that.
- mike_hock 4mo ago
  > 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.
  - thomashabets2 4mo ago
    > Because you can test if systemctl start foo.service works and if it does, you know it'll work when foo.timer triggers it. It's a better workflow than the one I mentioned for cron, yes, but it's nothing inherent. I would not call the difference one of being "predictable", though. The article and thread is full of complaints about cron that are either just missing features that could be added (like this one, trigger on demand), exactly the same ("the time spec is too complex"), or just plain "no you can already do that with cron". It wasn't until this comment (https://news.ycombinator.com/item?id=48385824 https://news.ycombinator.com/item?id=48385824) that I saw viable reasons why one would need to start from scratch. Except, of course, that "green field is more fun than improving things". > I don't want to hardcode $PATH in the crontab just so I can test the cronjob How is this different? Any way you slice it, you have to configure it somewhere if you're not lucky enough for the default to be acceptable. > [Lennartware] doesn't stack up that poorly against other projects but it's unacceptably low for a core system component. Well put.
    - mike_hock 4mo ago
      > How is this different? Any way you slice it, you have to configure it somewhere if you're not lucky enough for the default to be acceptable. It's a workaround for a design flaw. If you forget it you'll notice when it fails in production. There should rarely be a need to change the default path (just specify the full path if necessary), it should just be the same when you test and when it runs by itself. Trigger on demand would of course solve that. > exactly the same ("the time spec is too complex") Of course, the timespec complaint is bullshit. Both have manpages that will tell you immediately if you don't have it memorized.

thomashabets2 4mo ago

> $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-potato-sending-file-descriptors.html https://blog.habets.se/2025/10/The-strange-webserver-hot-pot...), but completely misapplied by systemd.

imtringued 4mo ago
>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.
- thomashabets2 4mo ago
  Are you making the assumption that it's impossible to add that feature to cron? You should not see a missing killer feature and go directly to the conclusion of rewriting. Sure, greenfield is fun. So there's that.
mike_hock 4mo ago
> 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.
- thomashabets2 4mo ago
  > Because you can test if systemctl start foo.service works and if it does, you know it'll work when foo.timer triggers it. It's a better workflow than the one I mentioned for cron, yes, but it's nothing inherent. I would not call the difference one of being "predictable", though. The article and thread is full of complaints about cron that are either just missing features that could be added (like this one, trigger on demand), exactly the same ("the time spec is too complex"), or just plain "no you can already do that with cron". It wasn't until this comment (https://news.ycombinator.com/item?id=48385824 https://news.ycombinator.com/item?id=48385824) that I saw viable reasons why one would need to start from scratch. Except, of course, that "green field is more fun than improving things". > I don't want to hardcode $PATH in the crontab just so I can test the cronjob How is this different? Any way you slice it, you have to configure it somewhere if you're not lucky enough for the default to be acceptable. > [Lennartware] doesn't stack up that poorly against other projects but it's unacceptably low for a core system component. Well put.
  - mike_hock 4mo ago
    > How is this different? Any way you slice it, you have to configure it somewhere if you're not lucky enough for the default to be acceptable. It's a workaround for a design flaw. If you forget it you'll notice when it fails in production. There should rarely be a need to change the default path (just specify the full path if necessary), it should just be the same when you test and when it runs by itself. Trigger on demand would of course solve that. > exactly the same ("the time spec is too complex") Of course, the timespec complaint is bullshit. Both have manpages that will tell you immediately if you don't have it memorized.