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