5 ms·
Process and service management is not a simple problem space, especially with POSIX semantics. Try doing something like "stop apache". It turns out that trying
by Jasper_ 13y ago
Process and service management is not a simple problem space, especially with POSIX semantics.
Try doing something like "stop apache". It turns out that trying to simply kill the Apache processes isn't going to work right, as Apache forks out lots of worker processes that won't be guaranteed to be killed when the Apache process stops. And now since the parent has gone away, they're reparented to PID1, so there's all these worker processes littering your system.
systemd uses cgroups to tag every single forked out process with a service file, so that all of the processes associated with a service can be stopped at once.
- regularfry 13y agoRight, but is systemd necessary for that, or can you use a cgroup from within a conventional sysvinit script?
- bkor 13y agosystemd also logs stderr + stdout, so if some daemon fails to start up, you can easily see it in 'service $SERVICE status'. A lot of things could theoretically be done by putting that all in a sysvinit script. That means duplicating that in every sysvinit script. Bugs galore :P
- thwarted 13y agoinitscripts have used libraries of routines since like forever. Good programming methodology applies equally to shell programming and initscripts as it does to programming anything else.
- bkor 13y agoInitscripts are specific to one distribution. A bug in an initscript in one distribution is not fixed in another distribution. This is practical real life example that has happened for 10+ years. With systemd, there is just a configuration file that is used. The logic is within the daemon and bugs are fixed in one place, then shared across distributions (+ embedded world and others). Maybe you could redo what systemd does by changing those libraries. I very much doubt it though, I also do not see the point of reimplementing this. Systemd way guarantees consistensy, you're proposing something which may or may not work, depending on the init script. Does not seem like a good practice, nor a good alternative to propose. But all means, go for it.
- thwarted 13y agoMany initscripts are provided by the software and distributions replace them with their own. The distributions themselves are at fault for not using an upstream initscript. There is also nothing stopping a distribution from replacing the software provided systemd config file, which themselves can contain snippets of executable shell code and thus not reap the benefits of upstream fixed bugs.
- bashinator 13y agoOooh, if I'm understanding right, if a daemon fails to start correctly for whatever reason, that status request will give me the stdout/stderr of the failure? That's a genuine improvement if systemd handles that consistently for all services.
- Jasper_ 13y agoThat's part of what the systemd journal provides, yes.
- Shish2k 13y agoIs a modern browser necessary for browsing HTML5 websites, or can you just write your own parsing / rendering / interaction engines in IE5-compatible javascript?
- ambrop7 13y agoShell scripts are a terrible language for any kind of event handling. Consider that: - You're probably going to be starting a new process for handling each event. - You'll be using the filesystem to store state between events. - You'll be using helper programs to access various kernel resources. - To keep such resources around, you'll have to keep the helpers running during events. Compared to implementing whatever you're doing in a single process with an event-driven design, or in multiple processes with their responsibilities split well, the shell script approach will be orders of magnitude slower and less reliable (the latter due to lots of race conditions).
- asveikau 13y agoman pkill
- bkor 13y agoTry doing that reliably with loads of workers and cgi scripts. Maybe possible at one point, but systemd does that reliably by default.
- Jasper_ 13y agoWhat about it? If my CGI scripts are Python scripts, how do I kill the CGI processes that Apache launched without killing any that lighttpd launched, or some silly script I wrote to monitor something else?
- caf 13y agoIn my opinion it's up to the authors of Apache to provide a supported and tested method to shut Apache down.
- Jasper_ 13y agoUsually when you kill a service, it's because it's not working properly. If a service is in a broken state, it's not the job of the service to try and cleanly shut itself down; it's the job of the service manager.