4 ms·

I’ve come to appreciate the ease of creating “init scripts” with systemd, and also make regular use of the lightweight monitoring/auto-restart features. Likewi

I’ve come to appreciate the ease of creating “init scripts” with systemd, and also make regular use of the lightweight monitoring/auto-restart features. Likewise for running multiple instances of the same software. But I do think the project suffers a bit of scope creep as it starts replacing cron, syslog, network device management, etc. I can understand the reasons to centralize things, but I’d be happier if systemd “did one thing well” instead of trying to do it all.

rootbear 6y ago
Scope creep is my biggest problem with systemd. I'm not excited about the recently announced homed, for example. I'm not sure it's the right solution, nor am I sure that there is an actual problem to be solved.
vimax 6y ago
I've become a big fan of systemd timers over cron jobs. The command itself is separated out into a service with all the isolation and journalling features of a service. You're able to test the command and know 100% it will run with the exact same environment. You can choose to disable a timer and invoke the service manually. You can setup alternate or multiple timers for the same call. It supports all the timing options of cron and expands them. You can explicitly state cron job ordering and dependencies. I've seen too many systems where the system is only fully up after several @reboot cron jobs start in some unspecified order. Don't worry about syslog going anywhere. Journald's scope is defined at providing journalling for standard out and standard error of services. In the past this output was typically sent to /dev/null or a custom log file and if you didn't bother to specify then maybe your system would be configured to send throw it away or pipe it to a file or send it to syslog. With systemd/journald, it is collecting only standard out and standard error. It holds it in a rotating journal, and then forwards everything to syslog for any actual log management and persistence.

rootbear 6y ago

Scope creep is my biggest problem with systemd. I'm not excited about the recently announced homed, for example. I'm not sure it's the right solution, nor am I sure that there is an actual problem to be solved.

vimax 6y ago

I've become a big fan of systemd timers over cron jobs. The command itself is separated out into a service with all the isolation and journalling features of a service. You're able to test the command and know 100% it will run with the exact same environment. You can choose to disable a timer and invoke the service manually. You can setup alternate or multiple timers for the same call. It supports all the timing options of cron and expands them. You can explicitly state cron job ordering and dependencies. I've seen too many systems where the system is only fully up after several @reboot cron jobs start in some unspecified order. Don't worry about syslog going anywhere. Journald's scope is defined at providing journalling for standard out and standard error of services. In the past this output was typically sent to /dev/null or a custom log file and if you didn't bother to specify then maybe your system would be configured to send throw it away or pipe it to a file or send it to syslog. With systemd/journald, it is collecting only standard out and standard error. It holds it in a rotating journal, and then forwards everything to syslog for any actual log management and persistence.