Peter Hjalmarsson posted on Fri, 15 Apr 2011 16:04:09 +0200 as excerpted: > [parallel boot] feature is still not really perfect, at least not > perfect enought. Use squid on a system where it takes longer for its > daemon to exist (like my router, where the media is a intel SSD, > 4GB memory and a AMD Athlon 2x on the AM3 socket) and you will see > lots of outputs from openrc about all those scripts waiting for it > to end...
If you're talking about the 50...40... etc wait if something takes longer than 10 seconds (I get it here on startup with ntp-client), I'd argue that's demonstration of the feature's maturity. What can start/stop does. Other things wait, with a (configurable) timeout until their dependency comes up (or goes down, at shutdown). If the wait is more than 10 seconds, the system tells you what is going on. That's as designed and IMO a good thing. What's broken about it? > So maybe when that feature is ready to be enabled by default? I believe it's ready for everyone to give a try. If it doesn't work or they prefer the more ordered output of a serial boot, despite the longer wait time, fine, but it'll work for most, with possible tweaking of the the timeout, the services that don't timeout at all (fscks, by default), or fine dependency ordering, if necessary. To have the system take far longer to POST than from end of POST to waiting for me to login (despite the idle-wait for ntp-client), is very nice indeed. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
