|
Home > Archive > Debian Developers > October 2005 > A thought about killing two bird with one stone
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
A thought about killing two bird with one stone
|
|
| David Goodenough 2005-10-26, 6:03 pm |
| 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Thomas Bushnell BSG 2005-10-26, 6:03 pm |
| David Goodenough <david.goodenough@btconnect.com> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Stephen Frost 2005-10-26, 6:03 pm |
| * Lars Wirzenius (liw@liw.iki.fi) wrote:
> ke, 2005-10-26 kello 12:39 -0700, Thomas Bushnell BSG kirjoitti:
>
> 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
| |
| Lars Wirzenius 2005-10-26, 6:03 pm |
| ke, 2005-10-26 kello 12:39 -0700, Thomas Bushnell BSG kirjoitti:
> David Goodenough <david.goodenough@btconnect.com> writes:
>
>
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Henning Makholm 2005-10-26, 6:03 pm |
| Scripsit Thomas Bushnell BSG <tb@becket.net>
> David Goodenough <david.goodenough@btconnect.com> writes:
ves[vbcol=seagreen]
[vbcol=seagreen]
> 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.
--=20
Henning Makholm "Al lykken er i =E9t ord: Overv=E6g=
tig!"
| |
| Henrique de Moraes Holschuh 2005-10-26, 6:03 pm |
| 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Brian May 2005-10-26, 8:51 pm |
| >>>>> "Stephen" == Stephen Frost <sfrost@snowman.net> 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 <bam@debian.org>
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| David Goodenough 2005-10-28, 4:51 pm |
| On Wednesday 26 October 2005 23:32, Henrique de Moraes Holschuh wrote:
> On Wed, 26 Oct 2005, David Goodenough wrote:
>
> 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Stephen Frost 2005-10-28, 4:51 pm |
| * Brian May (bam@debian.org) wrote:
>
> 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
| |
| Tim Dijkstra 2005-10-28, 4:51 pm |
| | |
| Gabor Gombas 2005-10-28, 4:51 pm |
| 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 debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Luca Capello 2005-10-30, 7:48 am |
| |
|
|
|
|