Re: A thought about killing two bird with one stone
Hello! On Thu 27 Oct 2005 00:57 +0200, Brian May wrote: (I have seen a system that appears to run ntpdate on startup before the network is configured - but it hasn't bothered me enough to investigate why yet.) If you're using ifplugd, this is a known (and wontfix) issue: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=204499 Thx, bye, Gismo / Luca pgp88ij34RKOx.pgp Description: PGP signature
Re: A thought about killing two bird with one stone
On Wednesday 26 October 2005 23:32, Henrique de Moraes Holschuh wrote: On Wed, 26 Oct 2005, David Goodenough wrote: Does this make sense? Yes, it does. Such functionality is part of a proper dependency-based initscript system, actually. Which doesn't actually have much to do with parallel execution (hint: you can do parallel execution with just the regular ordering we already have, in fact sysv-rc in unstable can do it right now). The parallel execution was really not what I was interested in, it was the side effect if knowing what other things needed to be restarted by apt-get. David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A thought about killing two bird with one stone
* Brian May ([EMAIL PROTECTED]) wrote: Stephen == Stephen Frost [EMAIL PROTECTED] writes: Stephen Not to mention that quite a few things do things like DNS Stephen lookups which could take quite a while for an unconnected Stephen system (perhaps because something broke, or who knows Stephen what else, I've had it happen, waiting for sendmail to Stephen time out sucks). Or perhaps because the step that configures the network to support DNS requests hasn't been executed yet... Indeed, that can certainly be annoying. (I have seen a system that appears to run ntpdate on startup before the network is configured - but it hasn't bothered me enough to investigate why yet.) Yeah, I recall seeing that happen too, though havn't hunted it down yet. This situation might actually be fixed by the proposal which would implement dependencies such that ntpdate would depend on a working network... Thanks, Stephen signature.asc Description: Digital signature
Re: A thought about killing two bird with one stone
On Thu, 27 Oct 2005 08:57:48 +1000 Brian May [EMAIL PROTECTED] wrote: (I have seen a system that appears to run ntpdate on startup before the network is configured - but it hasn't bothered me enough to investigate why yet.) I had one which needed working pcmcia for the network. Pcmcia is initialized after ntpdate, which gave me the same delays. grts Tim pgpBOnlfVd3sN.pgp Description: PGP signature
Re: A thought about killing two bird with one stone
On Wed, Oct 26, 2005 at 12:39:45PM -0700, Thomas Bushnell BSG wrote: How does this help boot faster? Doesn't it just increase disk contention? In theory, parallel I/O requests give a chance to the kernel's I/O scheduler to optimize them (by serving them in the order they are laid out on disk instead the order they have arrived, for example). I'm lazy to look up if this effect was already measured by someone. Gabor -- - MTA SZTAKI Computer and Automation Research Institute Hungarian Academy of Sciences - -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
A thought about killing two bird with one stone
In various discussions recently it has been suggested that it would be a good idea (TM) to make the init.d scripts run in parallel. This involves using some tags from the new LSB and generally making explicit some run-time dependencies that have had to be hacked to assumed in the past. It occurs to me that the solution to this also would allow the solution of another problem. Namely that if say Postgresql is upgraded by apt-get, all the applications (say Tomcat apps) that are running probably need to be restarted as well (well not the apps, just Tomcat which will by implication restart the apps). Currently one of two things (like libc6) seem to have this notion of consequences built into their upgrade scripts, and as libc6 does not get started by init.d this discussion would not help, but it does strike me that automating this process might be quite useful. Thus on one of my systems (and I know that not all of these are official Debian packages) when Postgresql is upgraded, OpenNMS needs to be restarted, which in turn requires Tomcat to be restarted. Just as Tomcat needs OpenNMS to have started which in turn needs Postgresql to have started. Does this make sense? David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A thought about killing two bird with one stone
David Goodenough [EMAIL PROTECTED] writes: In various discussions recently it has been suggested that it would be a good idea (TM) to make the init.d scripts run in parallel. This involves using some tags from the new LSB and generally making explicit some run-time dependencies that have had to be hacked to assumed in the past. How does this help boot faster? Doesn't it just increase disk contention? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A thought about killing two bird with one stone
ke, 2005-10-26 kello 12:39 -0700, Thomas Bushnell BSG kirjoitti: David Goodenough [EMAIL PROTECTED] writes: In various discussions recently it has been suggested that it would be a good idea (TM) to make the init.d scripts run in parallel. This involves using some tags from the new LSB and generally making explicit some run-time dependencies that have had to be hacked to assumed in the past. How does this help boot faster? Doesn't it just increase disk contention? Lots of things sleep a bit (or a long while in case the DHCP server is slow) and meanwhile other things could easily be started, if they don't depend on the sleeping thing. -- Love is a four letter word. So is hate. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A thought about killing two bird with one stone
* Lars Wirzenius ([EMAIL PROTECTED]) wrote: ke, 2005-10-26 kello 12:39 -0700, Thomas Bushnell BSG kirjoitti: David Goodenough [EMAIL PROTECTED] writes: In various discussions recently it has been suggested that it would be a good idea (TM) to make the init.d scripts run in parallel. This involves using some tags from the new LSB and generally making explicit some run-time dependencies that have had to be hacked to assumed in the past. How does this help boot faster? Doesn't it just increase disk contention? Lots of things sleep a bit (or a long while in case the DHCP server is slow) and meanwhile other things could easily be started, if they don't depend on the sleeping thing. Not to mention that quite a few things do things like DNS lookups which could take quite a while for an unconnected system (perhaps because something broke, or who knows what else, I've had it happen, waiting for sendmail to time out sucks). Stephen signature.asc Description: Digital signature
Re: A thought about killing two bird with one stone
Scripsit Thomas Bushnell BSG [EMAIL PROTECTED] David Goodenough [EMAIL PROTECTED] writes: In various discussions recently it has been suggested that it would be a good idea (TM) to make the init.d scripts run in parallel. This involves using some tags from the new LSB and generally making explicit some run-time dependencies that have had to be hacked to assumed in the past. How does this help boot faster? For example, in some situations, a normal boot will spend seconds waiting for network peers to answer or time out. (Say, some DHCP servers' ideas of prompt service leave something to be desired). It would be a plus if something useful could run while the networking script is waiting for replies. -- Henning Makholm Al lykken er i ét ord: Overvægtig!
Re: A thought about killing two bird with one stone
On Wed, 26 Oct 2005, David Goodenough wrote: Does this make sense? Yes, it does. Such functionality is part of a proper dependency-based initscript system, actually. Which doesn't actually have much to do with parallel execution (hint: you can do parallel execution with just the regular ordering we already have, in fact sysv-rc in unstable can do it right now). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: A thought about killing two bird with one stone
Stephen == Stephen Frost [EMAIL PROTECTED] writes: Stephen Not to mention that quite a few things do things like DNS Stephen lookups which could take quite a while for an unconnected Stephen system (perhaps because something broke, or who knows Stephen what else, I've had it happen, waiting for sendmail to Stephen time out sucks). Or perhaps because the step that configures the network to support DNS requests hasn't been executed yet... (I have seen a system that appears to run ntpdate on startup before the network is configured - but it hasn't bothered me enough to investigate why yet.) -- Brian May [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
