Okay, one technical correction (on myself): > What are you talking about? > > root@t510:/home/jude# runlevel > N 2 > root@t510:/home/jude# fgrep -r "sleep" /etc/rc2.d /etc/rcS.d > root@t510:/home/jude# > > You do *not* need timeouts to boot the system sequentially.
I should have typed "fgrep -r "sleep" /etc/rc2.d/* /etc/rcS.d/*", since it slipped my mind that fgrep does not follow symlinks unless specified on the command-line. While this command yields many instances of "sleep", a cursory inspection of when they occur indicates that the init scripts almost always execute "sleep" as part a restart, reload, upgrade, or failsafe. They do not "sleep" on the start/stop critical paths. Thus, I stand by my earlier point that timeouts aren't an expected part of the boot process. -Jude On Mon, Mar 30, 2015 at 10:55 PM, Jude Nelson <[email protected]> wrote: > > If you need to generically support a wide range of setups and include > > the fun stuff listed above into the mix, then your init system will > > need to do a lot more than what is necessary to bring up one > > individual system. Debian did run all of the above during its boot > > sequence (if the package was installed), just in case somebody > > actually went ahead and used it. > > Except that it doesn't. Debian will only do the "extra fun stuff" if it's > installed and usable. Go read the init scripts in /etc/rcS.d if you don't > believe me. > > > Dependencies enable you to have a robust boot sequence even with > > hardware like this. > > No. No they do not. Let me say it again: if the device with your root > filesystem is unavailable, the boot process *will* wait for it to become > available. There is no alternative, besides panicking. There is no > parallelization before root gets mounted, because nothing else *can* start. > > > If you want to support a wide range of combinations of all the goodies > > Linux comes with, incl. software raid, logical volume management, disk > > encryption and any combination thereof, then you can not do so in a > > generic way using a strictly sequential init system. You can configure > > all of these for each individual system, but you can not have generic > > support for all of them in any valid combination in your distribution. > > First, the extra packages are not used unless you install them, and will > only get invoked if they are needed. Second, Debian has initialized them > all sequentially, in the right order, without fail for the better part of > its existence. In fact, if you go look at Debian bug tracker, the > introduction of init script parallelization strategies have lead to > hard-to-reproduce boot bugs due to race conditions. > > > You will also need to introduce timeouts (which are either too short > > or too long, depending on the system) into each and every step along > > the way. > > What are you talking about? > > root@t510:/home/jude# runlevel > N 2 > root@t510:/home/jude# fgrep -r "sleep" /etc/rc2.d /etc/rcS.d > root@t510:/home/jude# > > You do *not* need timeouts to boot the system sequentially. > > > My point is "A init system should be robust to work with any valid > > configuration I can put the system in" and I understand your reply to > > be "Complexity makes programs less robust". I agree with both > > statement and see no contradiction whatsoever. > > Um, no. That has *never*, *EVER* been the case. If you break something, > it stays broken until you fix it. The OS does exactly what you tell it > to do, as it should. It's not the OS's responsibility to clean up your > mistakes if you put it into a state where it can't boot. > > > A strictly sequential boot is not able to do that in a generic way. > > You can configure *your* system to do that by tweaking the sequence, > > but it is impossible for a distribution to ship a sequential init > > system that can robustly set up any filesystem that you can mount > > manually. > > Then how, pray tell, has Debian been able to boot sequentially all these > years, with all these features? > > Okay. I hate that it's come to this, but at this point in reading your > reply I can no longer tell whether or not you're a troll. You talk about > the low-level details of userspace like you think you understand it, but > it's pretty clear that you do not (or, you do a very bad job at > communicating it). Either way, this thread has gone wildly off-topic, so I > will no longer reply to it. > > -Jude > > On Mon, Mar 30, 2015 at 7:06 PM, <[email protected]> wrote: > >> Hi Jude, hello Isaac, >> >> I did express myself poorly when I spoke of hardware detection. You >> both are fully correct to call me out on that. Yes, hardware detection >> happens in the kernel, and indeed some of it is done in parallel >> there. >> >> I was thinking about all the user-space tools that scan drives and >> create new devices based on their findings when writing this mail. >> These little things like btrfs scan, lvm --forgot-the-parameter, >> cryptsetup open, and the others that allow you to do cool things with >> your filesystems. >> >> Sorry for the confusion this caused and my poor choice of words. >> >> On Tue, Mar 31, 2015 at 12:05 AM, Jude Nelson - [email protected] >> <devuan.kn.ae5676beef.judecn#[email protected]> wrote: >> <snip> >> >> > If your boot sequence is taking too long because it's loading >> unnecessary >> > drivers, then your boot sequence is misconfigured. >> >> If you need to generically support a wide range of setups and include >> the fun stuff listed above into the mix, then your init system will >> need to do a lot more than what is necessary to bring up one >> individual system. Debian did run all of the above during its boot >> sequence (if the package was installed), just in case somebody >> actually went ahead and used it. >> >> >> And some hardware can take a very >> >> long time to register, so you need to be generous with those >> >> time-outs. On the other hand anybody without the hardware will stuck >> >> for the entire timeout, so you need to keep them as short as possible. >> > >> > If your hardware is taking a long time to spin up, it's due to bug in >> either >> > the hardware or its driver, not the boot sequence. >> >> Dependencies enable you to have a robust boot sequence even with >> hardware like this. >> >> > Again, if you're talking about waiting for the device with your root >> > filesystem, the boot process is *supposed* to block until it's ready. >> Boot >> > cannot proceed until the root device is found and mounted; otherwise you >> > obviously cannot load programs. This process cannot be sped up through >> > parallelization (Amdahl's Law and all that). Same goes for programs >> that >> > cannot be started until /usr is mounted (if you have a separate /usr). >> >> I think I poorly worded my original mail. >> >> Please let me try again: >> >> If you want to support a wide range of combinations of all the goodies >> Linux comes with, incl. software raid, logical volume management, disk >> encryption and any combination thereof, then you can not do so in a >> generic way using a strictly sequential init system. You can configure >> all of these for each individual system, but you can not have generic >> support for all of them in any valid combination in your distribution. >> >> You will also need to introduce timeouts (which are either too short >> or too long, depending on the system) into each and every step along >> the way. >> >> This is all about file system detection. Once everything is mounted, >> it is still rather easy to run into trouble with services not being >> fully up even though their start script finished, network not being >> there yet and whatnot. But that is a entirely different issue. >> >> <snip> >> >> >> The killer argument for parallel startup with dependency handling is >> >> robustness, not speed. >> > >> > No, the opposite is true. Programs with multiple instances of execution >> > (processes, threads, coroutines) in practice tend to be much more >> > error-prone, because they are much harder to reason about. This is >> because >> > the number of states such a program can be in increases with the >> *factorial* >> > of the number of instances of execution it has. This is such a problem >> that >> > determinism is often a design requirement for mission-critical software >> > whose failure will result in huge costs and/or loss of life. >> >> I think I missed something here;-) >> >> My point is "A init system should be robust to work with any valid >> configuration I can put the system in" and I understand your reply to >> be "Complexity makes programs less robust". I agree with both >> statement and see no contradiction whatsoever. >> >> >> Maybe it is my tendency to mess around with cryptsetup and co. that >> >> gets me into trouble, but I did have unbootable systems with sysv-init >> >> due to "unexpected setup" problems. Nothing I could not fix, but still >> >> an annoyance that I would be happy to get rid of. >> > >> > Parallel boot won't fix misconfigurations you introduced by messing >> around >> > with it. >> >> If I can mount a filesystem manually, then it is not misconfigured. I >> do expect my init system to also be able to bring up that filesystem >> -- provided I hand it all the necessary data (keys, etc.) and that it >> can handle all the individual pieces of software that I used when >> setting up that filesystem. >> >> A strictly sequential boot is not able to do that in a generic way. >> You can configure *your* system to do that by tweaking the sequence, >> but it is impossible for a distribution to ship a sequential init >> system that can robustly set up any filesystem that you can mount >> manually. >> >> That is a severe limitation of sequential init system and one that a >> distribution needs to be aware of. >> >> >> The whole consecutive boot thing hinges on timeouts and that is >> >> neither generic nor robust. >> > >> > The boot sequence does *not* hinge on timeouts. If anything, timeouts >> are a >> > fallback mechanism for working around other programs not making forward >> > progress (i.e. due to bugs, a down network, or faulty hardware). If >> your >> > boot sequence is encountering timeouts, then something's wrong with your >> > boot sequence. >> >> A *generic* consecutive boot sequence does. You can tweak the setup >> for your system so that it does not (or it least does less), but you >> can not ship one system that supports all (or at least most) valid >> combinations of filesystem setups and does not heavily rely on >> timeouts. >> >> BR >> Karl >> >> _______________________________________________ >> Dng mailing list >> [email protected] >> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng >> > >
_______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
