This very much reminds me of how old Slackware systems used to operate. It was workable, but had a number of problems:
(1) I want to stop "service1" for a few minutes, without affecting other services, how do I do this?
(2) I want to disable "service1" completely, or pass it an extra parameter, without affecting other services. How do I do this? Note you cannot edit the init file and restart, this'll restart all the other services as well.
(3) I just typed "my-package-manager install service4", and I want service4 to start right away (and naturally have full functionality - keep restarting on failure, save logs, etc..). How do I do this?
(4) service2 had a emitted too many log lines, and my log disk is full. How do I clean existing logs without restarting the service? (Note even if you remove the file, it'll still take up the disk space)
(5) You were debugging service3 performance, and noticed it has printed "ERROR out of foobars" to its log but didn't print the timestamp.. When did this happen?
(6) service2 needs to be started after NFS volume is mounted. service3 is responsible for cpu fans and should be started as early as possible. service1 will re-generate the userdb if the data directory is missing, so it should not be started automatically if that's the case.
(7) new version of service1 changes command-line and default restart interval. How do I apply this change to my heavily customized startup file?
I could go on and on. All of those are real problems, and before systemd, they were solved with tons of bespoke code. Either C/C++ code (making a trivial daemons complex beasts), or shell code of init system, with was typically highly distribution dependent. And of course it was fragile and full of bugs.
Thanks! This is exactly the sort of stuff I was looking for.
So maybe this is too reductive, but basically:
- Tools for mutation of a running system
- Dealing with hard dependencies that don't cause errors when unavailable (like nfs in your example, or fan control, but also enumerating devices as I mentioned earlier, or for security, firewall rules since firewall starts entirely permissive)
- Standard packaging (edit: er, composability via standard packaging, or modularity with standard packaging for modules)
I think the logging stuff (datetimes, clearing, etc) is probably more the domain of a logger like journald, whose purpose seems is more concrete to me.
(1) I want to stop "service1" for a few minutes, without affecting other services, how do I do this?
(2) I want to disable "service1" completely, or pass it an extra parameter, without affecting other services. How do I do this? Note you cannot edit the init file and restart, this'll restart all the other services as well.
(3) I just typed "my-package-manager install service4", and I want service4 to start right away (and naturally have full functionality - keep restarting on failure, save logs, etc..). How do I do this?
(4) service2 had a emitted too many log lines, and my log disk is full. How do I clean existing logs without restarting the service? (Note even if you remove the file, it'll still take up the disk space)
(5) You were debugging service3 performance, and noticed it has printed "ERROR out of foobars" to its log but didn't print the timestamp.. When did this happen?
(6) service2 needs to be started after NFS volume is mounted. service3 is responsible for cpu fans and should be started as early as possible. service1 will re-generate the userdb if the data directory is missing, so it should not be started automatically if that's the case.
(7) new version of service1 changes command-line and default restart interval. How do I apply this change to my heavily customized startup file?
I could go on and on. All of those are real problems, and before systemd, they were solved with tons of bespoke code. Either C/C++ code (making a trivial daemons complex beasts), or shell code of init system, with was typically highly distribution dependent. And of course it was fragile and full of bugs.