4 ms·

+100 if I could. Reasons why I generally don't cron: * I don't want to rewrite log or dependency management * I really don't want to troubleshoot whe

+100 if I could. Reasons why I generally don't cron: * I don't want to rewrite log or dependency management * I *really* don't want to troubleshoot when it fails to function, presumably the work was important * I barely want to set the job up at all! What service is deficient to beget this babysitting? Most of my automated jobs do work that depends on other things. Services, mounts, or even the novel idea of a functional network. Things managed and exposed by the manager, systemd. Go forth and recreate 'After=' and 'Requires=' for your cronjob and make it equally visible and robust, if you want, I guess. A command pipeline of all the right things and intimate knowledge/trust in their return codes will do. I'll go do something more productive or at least rewarding. Embrace the two files, template them and never mind it again. I promise it can be worth it. I'd argue the Unix Philosophy is paradoxical, if not simply just argued in uncooperative/unproductive ways. Idealistic and impractical if lived truly. Doing 'one thing' and doing it well actually requires doing the thing and telling others how it went... so really it's two things conflated, if not more! Enter 'systemd does too much': it's for our benefit, truly. It's not a complete endorsement, of course. There are plenty of things I think are underdeveloped or out of bounds: spare the sniping

bravetraveler 2y ago
Grandstanding: Pit me against some legacy holdout. Give us both a set of services and complex work to do in a real-world, representative, environment. I don't care what it is. I guarantee my setup using "timers" will be delivered earlier and prove to be more robust; it's already been written and battle tested. It's ready as soon as I can SSH or clone my repository. I just hear a bunch of self-selecting [read: made up] surface level complaints. Why is anyone editing these jobs so much to care if it's one file or two? Why not zero? Around two decades after 'cron' the concept of 'Configuration Management' was established. What's more, interfacing to disable/stop on the regular isn't required with dependencies or relationships defined; the result is implicit. I didn't even mention 'PartOf=' or 'OnFailure=', more settings that allow for handling external influence. The system will work for you, let it. I've soared through the ranks with this one simple trick: adaptation. The work isn't as unique as it is presented.

+100 if I could. Reasons why I generally don't cron: * I don't want to rewrite log or dependency management * I *really* don't want to troubleshoot whe

bravetraveler 2y ago

Grandstanding: Pit me against some legacy holdout. Give us both a set of services and complex work to do in a real-world, representative, environment. I don't care what it is. I guarantee my setup using "timers" will be delivered earlier and prove to be more robust; it's already been written and battle tested. It's ready as soon as I can SSH or clone my repository. I just hear a bunch of self-selecting [read: made up] surface level complaints. Why is anyone editing these jobs so much to care if it's one file or two? Why not zero? Around two decades after 'cron' the concept of 'Configuration Management' was established. What's more, interfacing to disable/stop on the regular isn't required with dependencies or relationships defined; the result is implicit. I didn't even mention 'PartOf=' or 'OnFailure=', more settings that allow for handling external influence. The system will work for you, let it. I've soared through the ranks with this one simple trick: adaptation. The work isn't as unique as it is presented.