11:10 a.m.
I am hearing much good from the gentoo camp about paralell startup, and
how it brings down boot times to about 30 secounds. Is this possible to
do with fedora as well?
Kyrre
2:26 p.m.
Hi,
> I am hearing much good from the gentoo camp about paralell
startup, and
> how it brings down boot times to about 30 secounds. Is this possible to
> do with fedora as well?
No.
If you disable the prelinker, you *should* be able to do it. Unless
there is something with selinux which prevents it of course.
TTFN
Paul
--
"Trust me, I know what I'm doing" - Det. Sledgehammer
3:20 p.m.
Why does the prelinker make the machine boot 200% slower?
tir, 19.10.2004 kl. 21.26 skrev Paul:
Hi,
> > I am hearing much good from the gentoo camp about paralell startup, and
> > how it brings down boot times to about 30 secounds. Is this possible to
> > do with fedora as well?
>
> No.
If you disable the prelinker, you *should* be able to do it. Unless
there is something with selinux which prevents it of course.
TTFN
Paul
11:56 a.m.
On Tue, 19 Oct 2004 18:10:28 +0200, Kyrre Ness Sjobak
<kyrre(a)solution-forge.net> wrote:
I am hearing much good from the gentoo camp about paralell startup,
and
how it brings down boot times to about 30 secounds. Is this possible to
do with fedora as well?
Hmm that almost wants to knee jerk against it. I think || startup is
being looked at by some people, but it isnt currently possible in
fedora.
--
Stephen J Smoogen.
CSIRT/Linux System Administrator
12:43 p.m.
Well as far as i can see and hear, enabling it in gentoo is as simple as
setting RC_PARALLEL_STARTUP="YES" instead of NO in /etc/conf.d/rc. Not
that i have ever used gentoo, but FC4 :D
That could acctually make us take back any andvantage in boot time
windows may have
tir, 19.10.2004 kl. 18.56 skrev Stephen J. Smoogen:
On Tue, 19 Oct 2004 18:10:28 +0200, Kyrre Ness Sjobak
<kyrre(a)solution-forge.net> wrote:
> I am hearing much good from the gentoo camp about paralell startup, and
> how it brings down boot times to about 30 secounds. Is this possible to
> do with fedora as well?
>
Hmm that almost wants to knee jerk against it. I think || startup is
being looked at by some people, but it isnt currently possible in
fedora.
--
Stephen J Smoogen.
CSIRT/Linux System Administrator
12:04 p.m.
On Tue, 2004-10-19 at 18:10 +0200, Kyrre Ness Sjobak wrote:
I am hearing much good from the gentoo camp about paralell startup,
and
how it brings down boot times to about 30 secounds. Is this possible to
do with fedora as well?
Yes, and we should do it. However, it requires lots of changes to the
initscripts :)
There are a number of projects that have done parallel startup on *NIX
machines. I believe one or two of the BSD variants use parallel startup
and dependencies in their scripts. Seth Nickell has some writeups on a
new startup script architecture as well.
Nobody is making the noise necessary to do anything about anything
though. Somebody needs the time and energy to champion this cause. The
current Fedora initscripts packages are also very, very nasty and not
well split out by function. You'll encounter resistance too from people
who don't care about Desktop OS stuff under Linux and who think that
longer boot times don't matter because they only boot their servers once
a year.
Dan
12:07 p.m.
On Tue, Oct 19, 2004 at 01:04:02PM -0400, Dan Williams wrote:
well split out by function. You'll encounter resistance too from
people
who don't care about Desktop OS stuff under Linux and who think that
longer boot times don't matter because they only boot their servers once
a year.
Eventually, they won't matter on desktops either, because we'll have
hibernation working perfectly.
--
Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
12:45 p.m.
tir, 19.10.2004 kl. 19.07 skrev Matthew Miller:
On Tue, Oct 19, 2004 at 01:04:02PM -0400, Dan Williams wrote:
> well split out by function. You'll encounter resistance too from people
> who don't care about Desktop OS stuff under Linux and who think that
> longer boot times don't matter because they only boot their servers once
> a year.
Eventually, they won't matter on desktops either, because we'll have
hibernation working perfectly.
Yes, when RH starts building the HW themselves.
Or maybe in 2010 todays computers are satisfactory supported. But then
there are UACPI or some other wicked thing MS has comed up with.
12:17 p.m.
On Tue, 19 Oct 2004, Dan Williams wrote:
On Tue, 2004-10-19 at 18:10 +0200, Kyrre Ness Sjobak wrote:
> I am hearing much good from the gentoo camp about paralell startup, and
> how it brings down boot times to about 30 secounds. Is this possible to
> do with fedora as well?
Yes, and we should do it. However, it requires lots of changes to the
initscripts :)
There are a number of projects that have done parallel startup on *NIX
machines. I believe one or two of the BSD variants use parallel startup
and dependencies in their scripts. Seth Nickell has some writeups on a
new startup script architecture as well.
OSX does it. Nice fast boot, but painful at times when you can't figure
out why X won't work until you watch the bootup carefully to see ABC
haven't fully started yet and X depends on A.
Not that I'm against it, it's just a bit of a radical shift, esp
considering the very large amount of non-parallel initscripts that are out
there that might need changing.
Is this covered in/by the LSB in any way? That seems like the place to
really have this particular fight.
-n
--
-------------------------------------------
nathan hruby <nhruby(a)uga.edu>
uga enterprise information technology services
production systems support
metaphysically wrinkle-free
-------------------------------------------
12:50 p.m.
longer boot times don't matter because they only boot their
servers once
a year.
..... Or wont use Fedora in favor of RHEL.
--- Dan Williams <dcbw(a)redhat.com> wrote:
> On Tue, 2004-10-19 at 18:10 +0200, Kyrre Ness Sjobak wrote:
> > I am hearing much good from the gentoo camp about paralell startup, and
> > how it brings down boot times to about 30 secounds. Is this possible to
> > do with fedora as well?
>
> Yes, and we should do it. However, it requires lots of changes to the
> initscripts :)
>
> There are a number of projects that have done parallel startup on *NIX
> machines. I believe one or two of the BSD variants use parallel startup
> and dependencies in their scripts. Seth Nickell has some writeups on a
> new startup script architecture as well.
>
> Nobody is making the noise necessary to do anything about anything
> though. Somebody needs the time and energy to champion this cause. The
> current Fedora initscripts packages are also very, very nasty and not
> well split out by function. You'll encounter resistance too from people
> who don't care about Desktop OS stuff under Linux and who think that
longer boot times don't matter because they only boot their
servers once
a year.
>
> Dan
>
> --
> fedora-devel-list mailing list
> fedora-devel-list(a)redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
>
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
1:20 p.m.
Le mardi 19 octobre 2004 à 13:04 -0400, Dan Williams a écrit :
You'll encounter resistance too from people
who don't care about Desktop OS stuff under Linux and who think that
longer boot times don't matter because they only boot their servers once
a year.
The best improvement in boot time you can have is by disabling rhgb.
Is rhgb design for server or for desktop ?
8:38 p.m.
Dan Williams (dcbw(a)redhat.com) said:
Yes, and we should do it. However, it requires lots of changes to
the
initscripts :)
Hah. It mainly requires changing /etc/rc, and adding dependencies
to the scripts.
Nobody is making the noise necessary to do anything about anything
though. Somebody needs the time and energy to champion this cause.
Or, you know... write the code and test it. :P
Seriously... it was done once, it didn't help appreciably. Doing it
again would be a good project.
The current Fedora initscripts packages are also very, very nasty and
not
well split out by function.
One script per daemon! Oh my god, it's HORRIBLE.
Bill
10:46 p.m.
--On Tuesday, October 19, 2004 9:38 PM -0400 Bill Nottingham
<notting(a)redhat.com> wrote:
Hah. It mainly requires changing /etc/rc, and adding dependencies
to the scripts.
Migration path: How do you handle the scripts that haven't been updated?
(Ie. those in 3rd party packages that won't get updated until the machinery
is in place.) Lump them all at the end in traditional serial order?
10:52 p.m.
Kenneth Porter (shiva(a)sewingwitch.com) said:
>Hah. It mainly requires changing /etc/rc, and adding
dependencies
>to the scripts.
Migration path: How do you handle the scripts that haven't been updated?
(Ie. those in 3rd party packages that won't get updated until the machinery
is in place.) Lump them all at the end in traditional serial order?
Yup.
Bill
11:14 p.m.
On Tue, 2004-10-19 at 20:46 -0700, Kenneth Porter wrote:
--On Tuesday, October 19, 2004 9:38 PM -0400 Bill Nottingham
<notting(a)redhat.com> wrote:
> Hah. It mainly requires changing /etc/rc, and adding dependencies
> to the scripts.
Migration path: How do you handle the scripts that haven't been updated?
(Ie. those in 3rd party packages that won't get updated until the machinery
is in place.) Lump them all at the end in traditional serial order?
Well, since parallel startup support will probably be an option and will
requires the initscripts (the one shipped with fedora in the
hypothetical case) to be modified so they will worked correctly in
serial an parallel mode, why not assume the dependencies for third-party
scripts based on the order in which they would have executed serially?
Maybe when "chkconfig --add" is invoked for a script that doesn't
contain dependencies information, chkconfig could determine (assume) the
"equivalent dependencies" based on all the scripts that should had been
executed before the newly added script.
Am I making any sense?
Regards,
--
Ricardo Veguilla <veguilla(a)hpcf.upr.edu>
1:51 a.m.
Ricardo Veguilla wrote:
Maybe when "chkconfig --add" is invoked for a script that
doesn't
contain dependencies information, chkconfig could determine (assume) the
"equivalent dependencies" based on all the scripts that should had been
executed before the newly added script.
Am I making any sense?
yes, makes a lot of sense :)
I would like to see a kind of "Makefile", cause "make" has all the
things you want. If "make" is too slow, it can be replaced later.
1:55 a.m.
On Wed, 2004-10-20 at 08:51 +0200, Harald Hoyer wrote:
Ricardo Veguilla wrote:
> Maybe when "chkconfig --add" is invoked for a script that doesn't
> contain dependencies information, chkconfig could determine (assume) the
> "equivalent dependencies" based on all the scripts that should had been
> executed before the newly added script.
>
> Am I making any sense?
yes, makes a lot of sense :)
I would like to see a kind of "Makefile", cause "make" has all the
things you want. If "make" is too slow, it can be replaced later.
http://www-106.ibm.com/developerworks/linux/library/l-boot.html
This article includes a "sample implementation" with a corresponding
Makefile.
--
Mircea MITU
BitDefender Linux Business-Line Manager
SOFTWIN - Data Security Division
http://linux.bitdefender.com
--
This message was scanned for spam and viruses by BitDefender
For more information please visit http://linux.bitdefender.com/
7:09 p.m.
Migration path: How do you handle the scripts that haven't been
updated?
The old init scripts would have the old chkconfig line in them.
Currently, with ordered startup and shutdown, initscripts have something
similar to the following embedded within them:
# chkconfig: - 60 20
And the initscript's runlevel symlinks are along the lines of:
/etc/rc.d/rc3.d/S60nfs (for startup)
/etc/rc.d/rc3.d/K20nfs (for shutdown)
If a dependency handling framework were added to Fedora's rc scripts, I
imagine that would require a new sort of 'chkconfig' line for the newer
initscripts. That newer embedded hint would contain the dependency
information for system tools (like chkconfig) and for the boot scripts
to build the order at runtime.
I also suppose runlevel symlinks for the newer initscripts could be
along the lines of:
/etc/rc.d/rc3.d/Snfs
/etc/rc.d/rc3.d/Knfs
Lump them all at the end in traditional serial order?
Yeah... /etc/rc.d/rc could go through S[[:alpha:]]*, parse out each
file's new chkconfig hints, build the order, and run the parallel
startup. When that's done, if there are any S[[:digit:]]*, execute
those as according to trandition. Same goes for shutdown (although I
suppose ordered services should be shutdown first, then paralleled
services shutdown after).
Sounds simple enough really.
Peace out,
Derek
7:46 p.m.
On Thu, 2004-10-21 at 19:09 -0500, Derek P. Moore wrote:
> Migration path: How do you handle the scripts that haven't
been updated?
The old init scripts would have the old chkconfig line in them.
Currently, with ordered startup and shutdown, initscripts have something
similar to the following embedded within them:
# chkconfig: - 60 20
And the initscript's runlevel symlinks are along the lines of:
/etc/rc.d/rc3.d/S60nfs (for startup)
/etc/rc.d/rc3.d/K20nfs (for shutdown)
If a dependency handling framework were added to Fedora's rc scripts, I
imagine that would require a new sort of 'chkconfig' line for the newer
initscripts. That newer embedded hint would contain the dependency
information for system tools (like chkconfig) and for the boot scripts
to build the order at runtime.
I also suppose runlevel symlinks for the newer initscripts could be
along the lines of:
/etc/rc.d/rc3.d/Snfs
/etc/rc.d/rc3.d/Knfs
> Lump them all at the end in traditional serial order?
Yeah... /etc/rc.d/rc could go through S[[:alpha:]]*, parse out each
file's new chkconfig hints, build the order, and run the parallel
startup. When that's done, if there are any S[[:digit:]]*, execute
those as according to trandition. Same goes for shutdown (although I
suppose ordered services should be shutdown first, then paralleled
services shutdown after).
Like I said previously, you don't need to run a traditional (serial)
startup process after the parallel startup to catch third party scripts
lacking the dependencies info, you only need to generate the new
dependencies info from current "chkconfig" info for each third-party
script.
For example:
# /etc/init.d/somescript
# chkconfig: - 60 20
the dependencies for "somescript" are all the scripts that would
preceded "somescript" in the traditional serial startup.
Sounds simple enough really.
Peace out,
Derek
Regards,
--
Ricardo Veguilla <veguilla(a)hpcf.upr.edu>
1 a.m.
On 13:04 19 Oct 2004, Dan Williams <dcbw(a)redhat.com> wrote:
| On Tue, 2004-10-19 at 18:10 +0200, Kyrre Ness Sjobak wrote:
| > I am hearing much good from the gentoo camp about paralell startup, and
| > how it brings down boot times to about 30 secounds. Is this possible to
| > do with fedora as well?
|
| Yes, and we should do it. However, it requires lots of changes to the
| initscripts :)
Not really.
| There are a number of projects that have done parallel startup on *NIX
| machines. I believe one or two of the BSD variants use parallel startup
| and dependencies in their scripts. Seth Nickell has some writeups on a
| new startup script architecture as well.
I do parallel startup on my FC2 boxes. Some info here:
Home page:
http://www.cskk.ezoshosting.com/cs/css/rc.mobile.html
Manual:
http://www.cskk.ezoshosting.com/cs/css/manuals/rc.mobile.1.html
Shrug. Works quite well, greatly reduces boot time.
Doesn't need any hacking of the initscripts except to use chkconfig to
turn everything off, because they're specified in the config file.
It only parallelises the init.d scripts; the preamble is all serial
still. There's some stuff in there I can probably turn off but obviously
not for the general (unknown box) case. But just parallelising the init.d
scripts is a significant win.
Cheers,
--
Cameron Simpson <cs(a)zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/
The nether wind, it blows again
of many things she speaks:
"The time has come to abstain from
all cabbages and leeks."
- Jonathan E. Quist, DoD #094, <jeq(a)lachman.com>
3:51 p.m.
Replying to Kyrre Ness Sjobak:
I am hearing much good from the gentoo camp about paralell startup,
and
how it brings down boot times to about 30 secounds. Is this possible to
do with fedora as well?
Gentoo, instead of numeric order of service startup which we have in
fedora, implements service dependencies. With dependencies it is pure
implementation detail to have system startup in parallel.
I doubt if anyone with @redhat.com suffix will consider reworking
initscripts to mind service dependencies ...
--
Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key
This message represents the official view of the voices in my head
7:55 a.m.
> I am hearing much good from the gentoo camp about paralell
startup, and
> how it brings down boot times to about 30 secounds. Is this possible to
> do with fedora as well?
Gentoo, instead of numeric order of service startup which we have in
fedora, implements service dependencies. With dependencies it is pure
implementation detail to have system startup in parallel.
I doubt if anyone with @redhat.com suffix will consider reworking
initscripts to mind service dependencies ...
sure sounds like a job for makefile. even with numbered tasks it should
be possible to construct a makefile that would handle it. indeed, i
believe pmake will handle the parallelization issues.
Tim Daly
9:21 a.m.
Le mercredi 20 octobre 2004 à 08:55 -0400, Tim Daly a écrit :
sure sounds like a job for makefile. even with numbered tasks it
should
be possible to construct a makefile that would handle it.
telinit 5 => make runlevel5
reboot => make runlevel6
indeed, i
believe pmake will handle the parallelization issues.
make -j ?
9:34 a.m.
Could some of the ordering be determined by the dependancies that are
already present in the rpm database?
Going further we really need services to start/stop/restart based on
Dbus messages. I want autofs to be notifed and reload its maps when
the network comes up.
On Wed, 20 Oct 2004 08:55:38 -0400, Tim Daly <daly(a)rio.sci.ccny.cuny.edu> wrote:
>> I am hearing much good from the gentoo camp about paralell
startup, and
>> how it brings down boot times to about 30 secounds. Is this possible to
>> do with fedora as well?
>
>Gentoo, instead of numeric order of service startup which we have in
>fedora, implements service dependencies. With dependencies it is pure
>implementation detail to have system startup in parallel.
>
>I doubt if anyone with @redhat.com suffix will consider reworking
>initscripts to mind service dependencies ...
sure sounds like a job for makefile. even with numbered tasks it should
be possible to construct a makefile that would handle it. indeed, i
believe pmake will handle the parallelization issues.
Tim Daly
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list
9:56 a.m.
On Wed, 20 Oct 2004 10:34:27 -0400, bill peck <bill.peck(a)gmail.com> wrote:
Could some of the ordering be determined by the dependancies that
are
already present in the rpm database?
I really don't think you want to rely on rpm's concept of a
'dependancy'. startup script logic can have not completely trivial
conditional logic. And rpm's dependancy definition is very very not
suited for conditional situations. rpm natively understand hard
dependancies and thats about it. This is even a problem for post/pre
scripts in rpm packages to deal with. I don't think its a good idea to
rely on rpmdb for "some" of the information at this point. I'd much
rather require manual dependancy creation when writing the startup
scripts instead of relying on an automation step that will still
require human review after the fact because it can't be trusted to get
conditional dependancies correct. I'd much rather have development
manhours focused on building simple tools to help verify hand created
dependancy information so its easier to review changes to the parallel
flow, than see time spent on tools that automate dependancy creation.
Your going to burn a lot of time just trying to come up with a tool
that can parse shell script conditionals looking for things like
executables or files present on the system. And personally i think the
effort to do this sort of thing in an generally useful and
encompassing way is FAR more effort than it would take to just hand
edit each and every initscript to add dependancy information.
-jef"Invokes the "need a more structured initscript file like xml"
argument just to move this discussion along towards its ultimate
climatic battle"spaleta
10:18 a.m.
On Wed, 2004-10-20 at 08:55, Tim Daly wrote:
sure sounds like a job for makefile. even with numbered tasks it should
be possible to construct a makefile that would handle it. indeed, i
believe pmake will handle the parallelization issues.
Tim Daly
Similar to this:
http://linuxdevices.com/articles/AT7172642614.html
Bob...
3:55 p.m.
On Wed, 2004-10-20 at 08:55 -0400, Tim Daly wrote:
>> I am hearing much good from the gentoo camp about paralell
startup, and
>> how it brings down boot times to about 30 secounds. Is this possible to
>> do with fedora as well?
>
>Gentoo, instead of numeric order of service startup which we have in
>fedora, implements service dependencies. With dependencies it is pure
>implementation detail to have system startup in parallel.
>
>I doubt if anyone with @redhat.com suffix will consider reworking
>initscripts to mind service dependencies ...
sure sounds like a job for makefile. even with numbered tasks it should
be possible to construct a makefile that would handle it. indeed, i
believe pmake will handle the parallelization issues.
Makefile isn't the way to go, it has the same problem as shell scripts:
error reporting and fine-grained control isn't very easy.
With something like D-BUS involved it's far easier to e.g. have GUI for
progress meters, starting/stopping services, display meaningful error
messages, and so forth. You also avoid some of the yucky issues such as
stuck PID files. Basically it's a lot more deterministic and extensible.
Havoc
3:58 p.m.
On Thu, 2004-10-21 at 16:55 -0400, Havoc Pennington wrote:
With something like D-BUS involved it's far easier to e.g. have
GUI for
progress meters, starting/stopping services, display meaningful error
messages, and so forth. You also avoid some of the yucky issues such as
stuck PID files. Basically it's a lot more deterministic and extensible.
Wasn't Seth (Nickell?) working on a Python/D-BUS init system prototype a
while back? What happened to that?
Havoc
--
Sean Middleditch <elanthis(a)awesomeplay.com>
AwesomePlay Productions, Inc.
4:14 p.m.
On Thu, 2004-10-21 at 16:58 -0400, Sean Middleditch wrote:
On Thu, 2004-10-21 at 16:55 -0400, Havoc Pennington wrote:
> With something like D-BUS involved it's far easier to e.g. have GUI for
> progress meters, starting/stopping services, display meaningful error
> messages, and so forth. You also avoid some of the yucky issues such as
> stuck PID files. Basically it's a lot more deterministic and extensible.
Wasn't Seth (Nickell?) working on a Python/D-BUS init system prototype a
while back? What happened to that?
It was just a prototype, I guess not finished. The hard part after all
is switching over the system and fixing all the bugs.
Havoc
4:50 p.m.
Havoc Pennington (hp(a)redhat.com) said:
> Wasn't Seth (Nickell?) working on a Python/D-BUS init system
prototype a
> while back? What happened to that?
It was just a prototype, I guess not finished. The hard part after all
is switching over the system and fixing all the bugs.
... and finding out that it makes it all slower. :)
Bill
7:10 p.m.
On Thu, 2004-10-21 at 17:50 -0400, Bill Nottingham wrote:
Havoc Pennington (hp(a)redhat.com) said:
> > Wasn't Seth (Nickell?) working on a Python/D-BUS init system prototype a
> > while back? What happened to that?
>
> It was just a prototype, I guess not finished. The hard part after all
> is switching over the system and fixing all the bugs.
... and finding out that it makes it all slower. :)
Heh, right ;-)
Though, one of the reasons to go with something more program/API-like
rather than makefile/shell is that it has conceivable advantages other
than speed.
You could imagine for example that rhgb is only a "view" that doesn't
have any interaction with or entanglement with the actual boot process,
it just watches events about boot progress and displays them. I don't
know how close that is to true already, but it might be a nice
situation. For that matter, maybe rhgb could just become part of gdm, if
we can get gdm launched early enough instead of at the end. Just
speculating.
Havoc
8:34 p.m.
Havoc Pennington (hp(a)redhat.com) said:
You could imagine for example that rhgb is only a "view"
that doesn't
have any interaction with or entanglement with the actual boot process,
it just watches events about boot progress and displays them. I don't
know how close that is to true already,
Hahaha, that is so not true now.
situation. For that matter, maybe rhgb could just become part of gdm,
if
we can get gdm launched early enough instead of at the end. Just
speculating.
Ideally, what happens is:
- you get *full* X up as early as possible (as opposed to the limited
X rhgb runs on now)
- you start gdm
- as a 'PreLoginAvailable' thing in gdm, you run rhgb, which just
collects script events (via dbus, presumably) and puts up information
Main technical barriers:
- getting enough of an env for full X to run early
- get filesystems mounted read-write quickly
- make X deal gracefully with the lack of xfs at startup
(or just shoot xfs :) )
- finding a good way for a gdm managed X to make its screen
available for rhgb, firstboot, and other 'custom' pre-session
widgetry
Bill
7:42 a.m.
On Thu, Oct 21, 2004 at 08:10:15PM -0400, Havoc Pennington wrote:
You could imagine for example that rhgb is only a "view"
that doesn't
have any interaction with or entanglement with the actual boot process,
it just watches events about boot progress and displays them. I don't
know how close that is to true already, but it might be a nice
Well communication goes both ways for example to be able to get user
input in kudzu.
situation. For that matter, maybe rhgb could just become part of gdm,
if
we can get gdm launched early enough instead of at the end. Just
speculating.
I don't think we can completely merge both but, integrating part of gdm
functionalities within rhgb, for example to allow login before the boot
finishes is one of the future improvement.
I plan to write down within a couple of weeks how I would like rhgb to
improve and evolve. Parallel startup is only one of the aspects of getting
a shorter and smoother "time to session from boot" which is IMHO the real
design goal.
Daniel
--
Daniel Veillard | Red Hat Desktop team http://redhat.com/
veillard(a)redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
9:17 a.m.
On Friday 22 October 2004 20:42, Daniel Veillard wrote:
Well communication goes both ways for example to be able to get
user input in kudzu.
I think if we're talking about getting into X ASAP, then I think the
whole kudzu thing needs to be rehashed. Maybe only check for graphics
card changes prior to bringing up X and then having a GUI after X is up
for all other devices.
take care,
--
-jeff
2:59 p.m.
On Fri, 2004-10-22 at 08:42 -0400, Daniel Veillard wrote:
On Thu, Oct 21, 2004 at 08:10:15PM -0400, Havoc Pennington wrote:
> You could imagine for example that rhgb is only a "view" that doesn't
> have any interaction with or entanglement with the actual boot process,
> it just watches events about boot progress and displays them. I don't
> know how close that is to true already, but it might be a nice
Well communication goes both ways for example to be able to get user
input in kudzu.
Right, but you could frame the communication as some kind of interface,
instead of just connecting kudzu to a tty. Then have real GUI.
> situation. For that matter, maybe rhgb could just become part of
gdm, if
> we can get gdm launched early enough instead of at the end. Just
> speculating.
I don't think we can completely merge both but, integrating part of gdm
functionalities within rhgb, for example to allow login before the boot
finishes is one of the future improvement.
I plan to write down within a couple of weeks how I would like rhgb to
improve and evolve. Parallel startup is only one of the aspects of getting
a shorter and smoother "time to session from boot" which is IMHO the real
design goal.
One of the goals. Reliability, good error messages, ability to have GUI
controls/questions early on are also worth thinking about perhaps.
Havoc
1:56 a.m.
Another improvement would be maybe s.th. like the C-header files have...
[ -z "$_INIT_D_FUNCTIONS" ] && . /etc/rc.d/init.d/functions
9:53 a.m.
On Tue, 2004-10-19 at 12:10, Kyrre Ness Sjobak wrote:
I am hearing much good from the gentoo camp about paralell startup,
and
how it brings down boot times to about 30 secounds. Is this possible to
do with fedora as well?
problem with parallel startup is that it *ALSO* increases how much the
disk has to seek, which slows things down. For me it's not clear if it's
actually a real gain or just a placebo one.
10:31 a.m.
Le mercredi 20 octobre 2004 à 10:53 -0400, Arjan van de Ven a écrit :
On Tue, 2004-10-19 at 12:10, Kyrre Ness Sjobak wrote:
> I am hearing much good from the gentoo camp about paralell startup, and
> how it brings down boot times to about 30 secounds. Is this possible to
> do with fedora as well?
problem with parallel startup is that it *ALSO* increases how much the
disk has to seek, which slows things down. For me it's not clear if it's
actually a real gain or just a placebo one.
Placebo, perhaps. I appreciate the speed up of readahead.
I boot in 35 seconds (gdm login) ! Just disable rhgb and suppress
unneeded (for me) services. I also add other services (apache,
postgresql, named, squid).
Athon xp 1600. IDE drive.
noon
On Wednesday 20 October 2004 22:53, Arjan van de Ven wrote:
problem with parallel startup is that it *ALSO* increases how much
the disk has to seek, which slows things down. For me it's not clear
if it's actually a real gain or just a placebo one.
It's a gain for those really long startup daemons. Maybe xfs has to
recache its fonts, or maybe ntpdate is syncing with the time server.
Then again, if Apache were written in a Bash script with all of its
functions in separate script files and configuration spread out in
different files and sourced in, parallelism would be an issue wouldn't
it?
I actually retooled this: http://www.fefe.de/minit/ for Redhat once and
the results were just night and day. Of course, I didn't run kudzu or
anything complicated like that. Just brought up the stuff I needed.
You practically don't even need hibernate or sleep when you get it this
good. (Doesn't help with X/GNOME/KDE startup, though) ;-)
have fun,
--
-jeff
12:07 p.m.
ons, 20.10.2004 kl. 19.00 skrev Jeff Pitman:
On Wednesday 20 October 2004 22:53, Arjan van de Ven wrote:
> problem with parallel startup is that it *ALSO* increases how much
> the disk has to seek, which slows things down. For me it's not clear
> if it's actually a real gain or just a placebo one.
It's a gain for those really long startup daemons. Maybe xfs has to
recache its fonts, or maybe ntpdate is syncing with the time server.
Then again, if Apache were written in a Bash script with all of its
functions in separate script files and configuration spread out in
different files and sourced in, parallelism would be an issue wouldn't
it?
I actually retooled this: http://www.fefe.de/minit/ for Redhat once and
the results were just night and day. Of course, I didn't run kudzu or
anything complicated like that. Just brought up the stuff I needed.
You practically don't even need hibernate or sleep when you get it this
good. (Doesn't help with X/GNOME/KDE startup, though) ;-)
No problem - i can wait 30 secounds, but 1.5 minutes is sometimes a bit
long.
Same basically goes to shutdown + i would guess somebody will think a
grapical shutdown (similar to rhgb) would be a good thing...
12:40 p.m.
On Thursday 21 October 2004 01:07, Kyrre Ness Sjobak wrote:
i would guess somebody will think a
grapical shutdown (similar to rhgb) would be a good thing...
Sure, a pure black screen with the words "Shutting Down..." written in
green right in the middle using ncurses would work for me.
--
-jeff
12:45 p.m.
ons, 20.10.2004 kl. 19.40 skrev Jeff Pitman:
On Thursday 21 October 2004 01:07, Kyrre Ness Sjobak wrote:
> i would guess somebody will think a
> grapical shutdown (similar to rhgb) would be a good thing...
Sure, a pure black screen with the words "Shutting Down..." written in
green right in the middle using ncurses would work for me.
:P
Really - it shouldn't be that hard to implement. We already have an
x-server running in the cases we want it, rigth?
But really not hi-pri either...
11:59 p.m.
New subject: Parallel Shutdown (was Re: Paralell startup)
On Thursday 21 October 2004 01:45, Kyrre Ness Sjobak wrote:
But really not hi-pri either...
No.
Shutdown can be made much faster then it is right now. Most processes
take a normal SIGINT (killall, pkill) and it will clean up. But,
currently, we reload all the scripts, all the configuration, delete pid
files, etc. and wait for each and every daemon to say OK before we go
to the next. And, the funny thing is we just SIGINT and SIGKILL at the
end: rc0.d/S00killall, rc6.d/S00killall.
--
-jeff
11:18 a.m.
New subject: Parallel Shutdown (was Re: Paralell startup)
Jeff Pitman (symbiont(a)berlios.de) said:
Shutdown can be made much faster then it is right now. Most
processes
take a normal SIGINT (killall, pkill) and it will clean up.
Exactly... what's needed is a simple list of what services are known
to shutdown cleanly if they're just whacked by init/killall (as opposed
to something like a database, or some other app that needs to save state.)
Then, we don't even need to run the shutdown scripts for those apps.
(Obviously, this is a whitelist scenario; any service that doesn't
claim this property needs to be shut down in the 'normal' way.)
Bill
11:46 a.m.
New subject: Parallel Shutdown (was Re: Paralell startup)
On Friday 22 October 2004 00:18, Bill Nottingham wrote:
as opposed
to something like a database, or some other app that needs to save
state.
I think we'd surprised about the robustness of SIGINT.
MySQL:
/bin/kill `cat /var/run/mysqld/mysqld.pid 2> /dev/null ` > /dev/null
2>&1
PostGRE:
su -l postgres -s /bin/sh -c "/usr/bin/pg_ctl stop -D $PGDATA -s -m
fast" > /dev/null 2>&1
Probably for transaction rollback and client disconnect, I dunno, I'm
not a DB yoda. But, then again you'd hope things have acquiesced on
the server and you've notified your users such that just nuking it's
not an issue...
I think most state saving is mainly a distro-centric thing: pid files,
lock files in /var/run. And little hidden files pooped onto or wiped
from the filesystem on the way out: /.autofsck, etc.
--
-jeff
1:19 p.m.
New subject: Parallel Shutdown (was Re: Paralell startup)
Jeff Pitman (symbiont(a)berlios.de) said:
I think we'd surprised about the robustness of SIGINT.
MySQL:
/bin/kill `cat /var/run/mysqld/mysqld.pid 2> /dev/null ` > /dev/null
2>&1
That could be easily done in this case by killall/init...
PostGRE:
su -l postgres -s /bin/sh -c "/usr/bin/pg_ctl stop -D $PGDATA -s -m
fast" > /dev/null 2>&1
That, not so much.
Bill
12:13 p.m.
recache its fonts, or maybe ntpdate is syncing with the time server.
Sometimes daemons fail, so there has to be a mechanism to show a failure.
What happens if the daemon/service fails that other daemons depend on? Does
the machine fail to boot properly or does it fail back to a serial boot?
--- Jeff Pitman <symbiont(a)berlios.de> wrote:
> On Wednesday 20 October 2004 22:53, Arjan van de Ven wrote:
> > problem with parallel startup is that it *ALSO* increases how much
> > the disk has to seek, which slows things down. For me it's not clear
> > if it's actually a real gain or just a placebo one.
>
> It's a gain for those really long startup daemons. Maybe xfs has to
recache its fonts, or maybe ntpdate is syncing with the time server.
>
> Then again, if Apache were written in a Bash script with all of its
> functions in separate script files and configuration spread out in
> different files and sourced in, parallelism would be an issue wouldn't
> it?
>
> I actually retooled this: http://www.fefe.de/minit/ for Redhat once and
> the results were just night and day. Of course, I didn't run kudzu or
> anything complicated like that. Just brought up the stuff I needed.
> You practically don't even need hibernate or sleep when you get it this
> good. (Doesn't help with X/GNOME/KDE startup, though) ;-)
>
> have fun,
> --
> -jeff
>
> --
> fedora-devel-list mailing list
> fedora-devel-list(a)redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
12:13 p.m.
ons, 20.10.2004 kl. 19.13 skrev James Harrison:
> recache its fonts, or maybe ntpdate is syncing with the time
server.
Sometimes daemons fail, so there has to be a mechanism to show a failure.
What happens if the daemon/service fails that other daemons depend on? Does
the machine fail to boot properly or does it fail back to a serial boot?
What happens today if a daemon fails, that other daemons depend on?
--- Jeff Pitman <symbiont(a)berlios.de> wrote:
> On Wednesday 20 October 2004 22:53, Arjan van de Ven wrote:
> > problem with parallel startup is that it *ALSO* increases how much
> > the disk has to seek, which slows things down. For me it's not clear
> > if it's actually a real gain or just a placebo one.
>
> It's a gain for those really long startup daemons. Maybe xfs has to
> recache its fonts, or maybe ntpdate is syncing with the time server.
>
> Then again, if Apache were written in a Bash script with all of its
> functions in separate script files and configuration spread out in
> different files and sourced in, parallelism would be an issue wouldn't
> it?
>
> I actually retooled this: http://www.fefe.de/minit/ for Redhat once and
> the results were just night and day. Of course, I didn't run kudzu or
> anything complicated like that. Just brought up the stuff I needed.
> You practically don't even need hibernate or sleep when you get it this
> good. (Doesn't help with X/GNOME/KDE startup, though) ;-)
>
> have fun,
> --
> -jeff
>
> --
> fedora-devel-list mailing list
> fedora-devel-list(a)redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
12:49 p.m.
On Thursday 21 October 2004 01:13, James Harrison wrote:
> recache its fonts, or maybe ntpdate is syncing with the time
> server.
Sometimes daemons fail, so there has to be a mechanism to show a
failure.
vi /var/log/messages
dmesg | less
What happens if the daemon/service fails that other daemons depend
on? Does the machine fail to boot properly or does it fail back to a
serial boot?
Why would it fail back to serial? It's already too late. For example,
if networking "fails", a lot things that depend on it will actually
still run (well, if you've got localhost working and stuff.)
You create dependencies like "yeah, this one needs network" and stuff
like that, and it will boot in order from there.
You ever play with Lattice Graphs in school? Lines can be traced to be
run in parallel, and others will run serial. Shoot, we could call all
these daemons "packages" and run it through RPM's topological sort! :)
take care,
--
-jeff
3:39 p.m.
On Wednesday 20 October 2004 01:13 pm, James Harrison wrote:
> recache its fonts, or maybe ntpdate is syncing with the time
server.
Sometimes daemons fail, so there has to be a mechanism to show a failure.
How would falling back to serial boot help?
Not launching the services whose dependancies are not satisfied seems like a
good idea to me. It is better than the current, try it anyway, and see it
fail (sometimes spectacularly).
Your definition of 'boot properly' needs explanation. What does it mean to
'boot properly'?
My personal opinion is that you get any system that runs well enough that you
can get in and fix the problem (hopefully, as quickly as possible...) has
booted successfully, if not satisfactorily.
-Roberto JP
What happens if the daemon/service fails that other daemons depend
on? Does
the machine fail to boot properly or does it fail back to a serial boot?
--- Jeff Pitman <symbiont(a)berlios.de> wrote:
> On Wednesday 20 October 2004 22:53, Arjan van de Ven wrote:
> > problem with parallel startup is that it *ALSO* increases how much
> > the disk has to seek, which slows things down. For me it's not clear
> > if it's actually a real gain or just a placebo one.
>
> It's a gain for those really long startup daemons. Maybe xfs has to
> recache its fonts, or maybe ntpdate is syncing with the time server.
>
> Then again, if Apache were written in a Bash script with all of its
> functions in separate script files and configuration spread out in
> different files and sourced in, parallelism would be an issue wouldn't
> it?
>
> I actually retooled this: http://www.fefe.de/minit/ for Redhat once and
> the results were just night and day. Of course, I didn't run kudzu or
> anything complicated like that. Just brought up the stuff I needed.
> You practically don't even need hibernate or sleep when you get it this
> good. (Doesn't help with X/GNOME/KDE startup, though) ;-)
>
> have fun,
> --
> -jeff
>
> --
> fedora-devel-list mailing list
> fedora-devel-list(a)redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
4:09 p.m.
On Wed, 20 Oct 2004 16:39:07 -0400, Roberto Peon <grmoc(a)yahoo.com> wrote:
How would falling back to serial boot help?
Not launching the services whose dependancies are not satisfied seems like a
good idea to me. It is better than the current, try it anyway, and see it
fail (sometimes spectacularly).
Uhm... i think you are mixing several different technical problems together.
Parallel booting addresses the specifc problem of how to order
'attempted' start up
of service scripts. There is no reason to say that a later script
must not be 'attempted' if an eariler script in the ordering has a
problem.
You are using I think 'dependancy' in an all encomposing way to
include hard dependancies as well as conditional dependancies. Just
because a 'dependancy' fails to start doesn't mean a later service
doesn't launch. Services scripts can have conditional logic...
foo initscript
if network is running do this
if network is not running do that
bar initscript
if sshd is running do this
if sshd is not running do that
Are completely valid conditional checks that later scripts can use to
taste the state of the system and decide how to proceed. In these
cases network and sshd are still dependancies in the sense that they
need to be 'attempted' to be run for the conditional logic to have any
validity. The startup scripts for these services still need to be
'attempted' before my foo are bar services, but whether or not network
is running or sshd is running is not a failure state that causes foo
or bar to not be launced.
Service scripts that depend on something else running should be robust
enough to have conditional logic and do their own internal checking
for system state before attempting to doing something spectacularly
stupid. Lets not drag failure status into the debate about ordering.
Each initscript should internalize its own checks and do its own
conditional logic to check for system state. What parallel bootup
should be addressing is SOLELY how to order script start up. It should
not refuse to attempt to start up a script. If a script has been
requested to be on at boot...it should be run at some point in the
ordering...and its internal checks should be used to catch system
state problems.
-jef
-jef
4:49 p.m.
On Wednesday 20 October 2004 05:09 pm, Jeff Spaleta wrote:
On Wed, 20 Oct 2004 16:39:07 -0400, Roberto Peon
<grmoc(a)yahoo.com> wrote:
> How would falling back to serial boot help?
>
> Not launching the services whose dependancies are not satisfied seems
> like a good idea to me. It is better than the current, try it anyway, and
> see it fail (sometimes spectacularly).
Uhm... i think you are mixing several different technical problems
together. Parallel booting addresses the specifc problem of how to order
'attempted' start up
of service scripts. There is no reason to say that a later script
must not be 'attempted' if an eariler script in the ordering has a
problem.
Sure there is- It is (at the least) inefficient, and often error-prone.
You are using I think 'dependancy' in an all encomposing way
to
include hard dependancies as well as conditional dependancies. Just
because a 'dependancy' fails to start doesn't mean a later service
doesn't launch. Services scripts can have conditional logic...
foo initscript
if network is running do this
if network is not running do that
bar initscript
if sshd is running do this
if sshd is not running do that
Are completely valid conditional checks that later scripts can use to
taste the state of the system and decide how to proceed. In these
cases network and sshd are still dependancies in the sense that they
need to be 'attempted' to be run for the conditional logic to have any
validity. The startup scripts for these services still need to be
'attempted' before my foo are bar services, but whether or not network
is running or sshd is running is not a failure state that causes foo
or bar to not be launced.
Agreed, and in the current initscripts world, this is an absolute necessity,
however, with adequately specified dependancies such checks per service are
redundant and inefficient.
I believe that stopping at the head of a dependancy chain (as opposed to
-forcing- each script to error-check on its own, which is where you're
implying we should leave it) is better for the following reasons:
1) Writing state-checking code is typically error-prone and tedius.
2) Reporting that a link in the dependancy chain failed, and so Foo,
Bar, and Baz will not be run is much cleaner than scanning the
syslog for failure statments from each of Foo, Bar, and Baz. This
means that it is easier to fix, i.e. more maintainable.
3) Most of the 'parallel' init schemes that I've seen already use a tool
which does dependancy checking... i.e. the tools are robust and
useful in dependancy checking/failure situations.
Service scripts that depend on something else running should be
robust
enough to have conditional logic and do their own internal checking
for system state before attempting to doing something spectacularly
stupid.
If you rephrased that as: Service scripts should fail gracefully, then I'd
wholeheartedly agree. I don't view requiring additional overhead as good.
A requirement in a dependancy graph might even be virtual, i.e. depend on
a system logger daemon be running. This seems like a nice way to deal with
things, instead of requiring the script to check for each version of a daemon
that it knows about.
Lets not drag failure status into the debate about ordering.
Each initscript should internalize its own checks and do its own
conditional logic to check for system state. What parallel bootup
should be addressing is SOLELY how to order script start up. It should
not refuse to attempt to start up a script. If a script has been
requested to be on at boot...it should be run at some point in the
ordering...and its internal checks should be used to catch system
state problems.
-jef
:/
I feel that using the information provided by dependancies can result in a
cleaner, easier to fix error condition.. I'm not sure if I know how to
reconcile the two viewpoints... Perhaps the only way is to just try it :/
-Roberto JP
9:50 p.m.
--On Wednesday, October 20, 2004 5:09 PM -0400 Jeff Spaleta
<jspaleta(a)gmail.com> wrote:
Services scripts can have conditional logic...
foo initscript
if network is running do this
if network is not running do that
bar initscript
if sshd is running do this
if sshd is not running do that
This is a boot-centric way of looking at the problem. Instead, think
hot-plug. foo has two scripts, one that runs right away without a
dependency, and the other runs when the network hot-plugs into existence,
after the first script signals that it's done. Everything can be
event-driven.
I followed Jeff Pitman's link and his page has a link to Richard Gooch's
interesting "need" scheme:
<http://www.atnf.csiro.au/people/rgooch/linux/boot-scripts/>
It looks like this scheme stores the dependency graph in init's memory, so
shutting down a service should also shut down its dependencies first. (When
considering a boot scheme, you also need to consider its effect on shutdown
and runlevel-change processing.)
12:39 a.m.
My quick 2 cents:
The goal of a parallel startup is to plunge the user into the graphical
login as quickly as possible while the remaining daemons continue
starting in the background. This gives the feel of a faster startup and
in reality does just that with limited functionality as remaining
services come to life.
To this end i would create a tree style dependency graph (gantt like) of
services as they are installed on the system. Services can specify that
they "require" a particular service to be started or simply "request"
that a previous daemon be started before it is started (in the first
case the current service wouldnt be executed if the dependent failed in
the second it would with supposed partial functionality). Every daemon
on the tree should be started eventually but particular ones could be
fast forwarded by adding them to a specialized queue. The queue is
sorted FIFO style and its dependents are added to an independent FILO
stack that starts only those services required to get you to the point
at which the queued service can run (utilizing parallel startups where
possible of course).
In the event a service fails the user should be notified and any service
that "requires" it shouldnt be started but any service that "requests"
it should be with partial functionality. Am i making any sense to other
people or am i way off base? This allows you to get into a "working"
environment as quickly as possible while also starting the remaining
services as efficiently as possible. Feedback always welcome.
--mf
4:20 a.m.
Michael Favia wrote:
My quick 2 cents:
The goal of a parallel startup is to plunge the user into the graphical
login as quickly as possible while the remaining daemons continue
starting in the background. This gives the feel of a faster startup and
in reality does just that with limited functionality as remaining
services come to life.
Keep in mind, that for a login, you need network services in some environments (NIS,
kerberos, ...)
So the dependencies have to check for these needs also.
11:22 a.m.
Harald Hoyer wrote:
Keep in mind, that for a login, you need network services in some
environments (NIS, kerberos, ...)
So the dependencies have to check for these needs also.
And should register as such. I dont know if this is required on install
or if this can be modified when kerberos/NIS is enabled somehow (to save
the greatest number of people the greatest amount of time).regardless
you need network to verify proper login not to display a login screen.
Many times it takes people seconds if not minutes to login. My
suggestion is give them the ability to enter their information and hold
off checking it after they submit it till the required network
infrastructure exists.
-mf
2:20 p.m.
tor, 21.10.2004 kl. 18.22 skrev Michael Favia:
Harald Hoyer wrote:
>
> Keep in mind, that for a login, you need network services in some
> environments (NIS, kerberos, ...)
> So the dependencies have to check for these needs also.
>
And should register as such. I dont know if this is required on install
or if this can be modified when kerberos/NIS is enabled somehow (to save
the greatest number of people the greatest amount of time).regardless
you need network to verify proper login not to display a login screen.
Many times it takes people seconds if not minutes to login. My
suggestion is give them the ability to enter their information and hold
off checking it after they submit it till the required network
infrastructure exists.
-mf
...or simply "gray out" (ie not activate) the GDM login prompt before
network etc is up...
11:36 p.m.
Kyrre Ness Sjobak wrote:
tor, 21.10.2004 kl. 18.22 skrev Michael Favia:
...or simply "gray out" (ie not activate) the GDM login prompt before
network etc is up...
I disagree here you want to enable interaction as quickly as possible to
impart the idea of being started up. Instead delay verification of
credentials.
-mf
6:33 p.m.
The origional point I tried to make was that if you dont give some indication
that something failed to start on boot then unless you start diging around in
system files you wont know something failed.
How would falling back to serial boot help?
Jumping back into
serial boot could be an indication that the boot process is
not running correctly and that the operator should do some invesitgation to
fix the problem. Perhaps where serial boot starts could be the indication to
the problem.
Your definition of 'boot properly' needs explanation. What
does it mean to
'boot properly'?
The machine boots into multiuser mode without any errors
in the startup
process. Sorry if this wasnt clear.
Its pointless having a very fast booting system if the time you saved is spent
finding out why the machine didnt "boot properly".
Error checking and user notification is important.
We already have rhgb as a tool for this....
James
--- Roberto Peon <grmoc(a)yahoo.com> wrote:
>
>
>
> On Wednesday 20 October 2004 01:13 pm, James Harrison wrote:
> > > recache its fonts, or maybe ntpdate is syncing with the time server.
> >
> > Sometimes daemons fail, so there has to be a mechanism to show a failure.
>
How would falling back to serial boot help?
>
> Not launching the services whose dependancies are not satisfied seems like a
>
> good idea to me. It is better than the current, try it anyway, and see it
> fail (sometimes spectacularly).
>
Your definition of 'boot properly' needs explanation. What
does it mean to
'boot properly'?
>
> My personal opinion is that you get any system that runs well enough that
> you
> can get in and fix the problem (hopefully, as quickly as possible...) has
> booted successfully, if not satisfactorily.
>
>
> -Roberto JP
>
> > What happens if the daemon/service fails that other daemons depend on?
> Does
> > the machine fail to boot properly or does it fail back to a serial boot?
> >
> > --- Jeff Pitman <symbiont(a)berlios.de> wrote:
> > > On Wednesday 20 October 2004 22:53, Arjan van de Ven wrote:
> > > > problem with parallel startup is that it *ALSO* increases how much
> > > > the disk has to seek, which slows things down. For me it's not
clear
> > > > if it's actually a real gain or just a placebo one.
> > >
> > > It's a gain for those really long startup daemons. Maybe xfs has to
> > > recache its fonts, or maybe ntpdate is syncing with the time server.
> > >
> > > Then again, if Apache were written in a Bash script with all of its
> > > functions in separate script files and configuration spread out in
> > > different files and sourced in, parallelism would be an issue wouldn't
> > > it?
> > >
> > > I actually retooled this: http://www.fefe.de/minit/ for Redhat once and
> > > the results were just night and day. Of course, I didn't run kudzu or
> > > anything complicated like that. Just brought up the stuff I needed.
> > > You practically don't even need hibernate or sleep when you get it
this
> > > good. (Doesn't help with X/GNOME/KDE startup, though) ;-)
> > >
> > > have fun,
> > > --
> > > -jeff
> > >
> > > --
> > > fedora-devel-list mailing list
> > > fedora-devel-list(a)redhat.com
> > > http://www.redhat.com/mailman/listinfo/fedora-devel-list
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
>
> --
> fedora-devel-list mailing list
> fedora-devel-list(a)redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-devel-list
>
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com
3:36 a.m.
On Wed, 2004-10-20 at 10:13 -0700, James Harrison wrote:
> recache its fonts, or maybe ntpdate is syncing with the time
server.
Sometimes daemons fail, so there has to be a mechanism to show a failure.
What happens if the daemon/service fails that other daemons depend on? Does
the machine fail to boot properly or does it fail back to a serial boot?
I'd rather prefer to not launch any other daemons is one fails. Imagine
that iptables fails to start for some reason and networking and network
related daemons do start up properly, leaving the system open to "bad
guys".
--
Mircea MITU
BitDefender Linux Business-Line Manager
SOFTWIN - Data Security Division
http://linux.bitdefender.com
--
This message was scanned for spam and viruses by BitDefender
For more information please visit http://linux.bitdefender.com/
3:35 p.m.
It is a real gain. Many services sit there and wait for a network timeout, or
other high-latency, low-disk activity.
Annoying. Load the other, non-dependant services in the meanwhile.
Head 'thrashing' due to multiple application access may cause some overall
ineffiency, but it really depends on the ratio of disk activity to
application latency.
-Roberto JP
On Wednesday 20 October 2004 10:53 am, Arjan van de Ven wrote:
On Tue, 2004-10-19 at 12:10, Kyrre Ness Sjobak wrote:
> I am hearing much good from the gentoo camp about paralell startup, and
> how it brings down boot times to about 30 secounds. Is this possible to
> do with fedora as well?
problem with parallel startup is that it *ALSO* increases how much the
disk has to seek, which slows things down. For me it's not clear if it's
actually a real gain or just a placebo one.
7187
days inactive
7190
days old
63 comments
27 participants
participants (27)
-
Arjan van de Ven -
Bill Nottingham -
bill peck -
Bob Chiodini -
Cameron Simpson -
Dan Williams -
Daniel Veillard -
Derek P. Moore -
Féliciano Matias -
Harald Hoyer -
Havoc Pennington -
James Harrison -
Jef Spaleta -
Jeff Pitman -
Kenneth Porter -
Kyrre Ness Sjobak -
Matthew Miller -
Michael Favia -
Mircea MITU -
nathan r. hruby -
Paul F. Johnson -
Paul P Komkoff Jr -
Ricardo Veguilla -
Roberto Peon -
Sean Middleditch -
Stephen John Smoogen -
Tim Daly