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