4 ms·

systemd 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

by bkor 13y ago

systemd 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 ago
initscripts 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 ago
  Initscripts 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 ago
    Many 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 ago
Oooh, 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 ago
  That's part of what the systemd journal provides, yes.

by bkor 13y ago

thwarted 13y ago

initscripts 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 ago
Initscripts 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 ago
  Many 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 ago

Oooh, 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 ago
That's part of what the systemd journal provides, yes.