On 06/09/2016 10:10 PM, Andrew McGlashan wrote: > What I have now is that with some extra "smarts" that stops the original > concept from working as intended. The smarts is meant to allow for > faster startup and to tie in dependancies; to me, it is trying to be too > smart and that is where the problem lies. Faster startup was never the initial goal of dependency-based boot, that came afterwards. The main goal was always to describe startup properly, because you want ordering to reflect what services actually mean relative to another. And just pulling some arbitrary numbers out of thin air was NEVER a good idea in my eyes. > I see within the /etc/init.d/ scripts that there is all this extra junk > at the top and there are .depend.* files in that directory too. The .depend.* is for Makefile-based boot (startpar uses that internally). You can still disable that and go back to a fully serialized version with sysvinit. > I am thinking that these extras are the reason why it isn't running the > script at startup as expected. No, the reason is that you appear to have pulled the number 02 out of thin air and expect it to work, without giving a thought about what you want to actually order it against. (See my other email.) > Those extras weren't not part of the > more original sysv init setup; and, it may be why lots of Debian and > other people decided that the sysvinit was broken (due to the extras)... No, in the contrary. When I first saw Gentoo's system in the mid 2000s, which was based exclusively on dependencies (but still used scripts on top of sysvinit), I thought: wow, this is SO much better than all the other distros at that time. To me, anything that doesn't allow me to have dependencies is not worth my consideration. I've often had to write own services that hook into the system startup at certain points. And being able to specify dependencies is something absolutely essential here. Because then I actually semantically describe why I want a service in a given position in the boot sequence. Doing it in any other way is madness to me. There's a reason why _every_ modern init system supports dependencies (systemd, Solaris's SMF, nosh, OpenRC, ...), because in the modern world, where so many things need to be taken care of at boot, it's absolutely essential to be able to express the relations betwen all the services that need to be started explicitly in form of dependencies, otherwise you'd never be able to really tackle the complexity. > and hence why we ended up with systemd. You're right and you're wrong here. You're right in that the way dependency-based boot is handled in sysvinit+initscripts-based systems is not really nice, because dependencies are actually kind of implemented on top of an older model, instead of being treated as a first-class citizen. (And it's not complete, because the dependencies are only considered when booting, not when manually starting/stopping services. [1]) You're wrong in the sense that nobody on the systemd side of the argument wants to go back to non-dependency-based boot. So if you think that had dependency-based boot never been added to the init script logic, systemd wouldn't have been born or at least not have gained any traction - it would be the complete opposite, some people would have wanted something like systemd even moreso. Regards, Christian [1] Gentoo's set of scripts actually already did that 10 years ago, with the caveat that it didn't have proper state tracking, only an emulation of that, which is why the 'zap' action existed (exists?) there.
Attachment:
signature.asc
Description: OpenPGP digital signature