3 ms·
While I agree with all of your points, I don't necessarily understand why reverting away from systemd would fix this. Because, you know, hundreds of user-maint
by cookiengineer 6y ago
While I agree with all of your points, I don't necessarily understand why reverting away from systemd would fix this.
Because, you know, hundreds of user-maintained shitty shell scripts for init.d are the opposite of what you're aiming to achieve, too.
Apache binds sigwinch signals to shutdown for a reason, and those were not good reasons to begin with.
A more sophisticated alternative daemon would need to improve on the signals concept in the kernel beforehand, which certainly has to change; as kernel signalling currently is not even remotely made for such a use case (of a system daemon).
...so I kind of understand poettering's harsh statements, and why linus and him don't get along so well due to both of 'em having very opinionated and probably opposite views.
I think in order to improve at least some of your points, maybe some systemd modules and integration APIs would be the best way to go? Like an sqlite enabled systemd or something? Do you know whether such an initiative already exists?
- cat199 6y ago> Because, you know, hundreds of user-maintained shitty shell scripts for init.d are the opposite of what you're aiming to achieve, too. false choice - witness rc.d-style init & having a sane shell library / helper programs to handle common start/stop idioms, as is also apparently provided here.