Bug 99540 - (startuptime) Things that might speed up startup
Things that might speed up startup
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: distribution (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
bzcl34nup
:
: 104968 124406 132480 (view as bug list)
Depends On: 131466
Blocks:
  Show dependency treegraph
 
Reported: 2003-07-21 15:33 EDT by Adrian Likins
Modified: 2014-03-16 22:37 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-06 19:56:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Adrian Likins 2003-07-21 15:33:26 EDT
This bug is intented to be a holding place for ideas on how to 
speed up startup.
Comment 1 Adrian Likins 2003-07-21 15:38:08 EDT
Some ideas already bounced around:

Parallell init scripts

      http://lists.debian.org/lsb-spec/2000/lsb-spec-200002/msg00015.html
      http://www.atnf.csiro.au/people/rgooch/linux/boot-scripts/


Lockfiles on a ramfs?
     blocke on #rhl-devel mentioned that gentoo does this. Speculation
that it might improve startup times. 
Comment 2 Adrian Likins 2003-07-21 16:15:44 EDT
Try to startup up X once instead of twice (rhgb, [gxk]dm)
Comment 3 Chris Ricker 2003-07-22 02:04:14 EDT
How about a simpler version of parallel init scripts: modify rc so that all
scripts with the same number get started || stopped in parallel in background?
It wouldn't gain as much speed as Ted / Richard's ideas, but it would be a lot
more compatible with standard SysV init behavior

If you don't care at all about compatibility, I've never seen a faster boot than
minit  http://www.fefe.de/minit/ or http://www.fbunet.de/minit.shtml . It's a
little too similar to djb's wackiness for my taste, but it is quite speedy

there's also runit 
http://smarden.org/runit/index.html which I've never tried, but looks similar to
minit
Comment 4 Bruce A. Locke 2003-07-22 06:22:31 EDT
It was also discussed on #rhl-devel that disk I/O and harddrive seek times was
what causes the apparent slowness in the bootup scripts.

I also brought up an extention of the "start X up only once idea" in that to
give the illusion of a faster boot system (for a better end user experience) the
following could be done:

For systems configured to use runlevel 5 as the default start X as soon as the /
partition and any other needed partitions (if /tmp is split out into its own,
etc) are mounted r/w.  Delay the start of the graphical boot until this point
and reuse this copy of X to start gdm after the boot "appears" complete
(modification to gdm most likely needed). 

While services such as portmap and xinetd (for fam), xfs, kudzu etc and such
should be up and running before gdm starts other services like sendmail, etc
could wait until after gdm is started on a desktop or workstation system.  Again
its all to give the illusion to the end user which is important on a desktop
system.  (Most likely this behaviour would be looked down upon for server
environments so a toggle in /etc/sysconfig would be desirable)

To avoid a race issue between X and the gettys a configurable hardcoded vt would
probably need to be assigned to X (as long as its configurable I personally
don't see the harm)

Comment 5 Chris Ricker 2003-07-24 07:27:10 EDT
Also see http://www.fastboot.org
Comment 6 Ben Russo 2003-09-04 22:31:47 EDT
How about you make a way for the machine to tell the difference between starting
up from a halt (or poweroff) and a simple reboot.  If it is just a reboot have
kudzu short circuit.  That would save a few seconds right there.  Just have to
document kudzu so that people know if they want it to scan they have to do a
init 0 and then restart, not an init 6.
Comment 7 Ben Russo 2003-09-04 22:36:51 EDT
Also, all network related services (that require network access to start) should
auto-detect an "up" interface, (no up interface, just fork a wait and retry
process into the background and exit the current process so the boot will continue).

Also Interfaces should have an option in the ifcfg-DEVX file for
"MII-TOOL-COMPATIBLE=[yes|NO]" or "ETH-TOOL-COMPATIBLE=[yes|NO]"
if one of these options is present, and the interface is active when the service
is starting, then the service startup script will check for the presence of
"LINK STATUS GOOD"  if there is no link status on any of the active interfaces,
then the startup script should fork a "wait and try again later" process into
the background, and then it should let the boot process move on.
Comment 8 Bill Nottingham 2003-09-04 22:40:12 EDT
We already check for link before bringing up any DHCP interface; moreover,
there's no reason to specify separate ethtool/miitool settings; everything in
the future should support ethtool.
Comment 9 Panu Matilainen 2003-09-05 02:07:33 EDT
I agree there's no need for separate mii-tool and ethtool settings but PLEASE do
add such an option - as long as there are drivers not compatible with neither...
It's nothing short of ugly to have to do chmod a-x /sbin/ethtool kind of stuff
to disable link-up detection for incompatible drivers.
Comment 10 Bill Nottingham 2003-09-05 11:00:58 EDT
Any such drivers should be reported as kernel bugs, seriously, as that means the
driver is returning *wrong* results. If the tools return 'not supported', we
assume the link is *up*.
Comment 11 Panu Matilainen 2003-09-05 12:36:42 EDT
Ok, will do so from now on. Last I checked pcnet32 driver could crash the whole 
box just by running mii-tool as a normal user but that was quite a while ago, 
need to recheck. 

However I still think having such an option would be good as there really isn't 
any guarantee AFAIK that new drivers will automatically support ethtool. And 
there are cases when you don't even *want* to check whether the link is up 
right now (collague of mine just stumbled upon this a couple of weeks ago) - 
don't remember off-hand whether the link-up check is done for interfaces with 
static IP's but IIRC it is.
Comment 12 Bill Nottingham 2003-09-05 12:46:17 EDT
Nope, link check is only done for dynamic IP.
Comment 13 Bill Nottingham 2003-09-23 21:43:35 EDT
*** Bug 104968 has been marked as a duplicate of this bug. ***
Comment 14 acount closed by user 2003-10-10 21:15:29 EDT
Chris Ricker wrote:
> If you don't care at all about compatibility, I've never seen a faster boot
than minit  http://www.fefe.de/minit/ or http://www.fbunet.de/minit.shtml . 

LiNUX init _must_ be LSB compatible:
LSB init script tests - http://www.physik.fu-berlin.de/~tburnus/lsb/
Linux Standard Base Specification, System Initialization -
http://www.linuxbase.org/spec/gLSB/gLSB/sysinit.html

There is a /. article about "Replacing the Aging Init Procedure on Linux" at:
http://developers.slashdot.org/article.pl?sid=03/10/02/1553253&mode=thread&tid=106&tid=185
Comment 15 Bill Nottingham 2003-10-13 15:30:57 EDT
Note that minit is not really faster in and of itself; it's only faster if you
restrict *what it runs* (minit running the same script as regular init is only
faster by a couple of percent)
Comment 16 Bill Nottingham 2004-05-26 15:33:35 EDT
*** Bug 124406 has been marked as a duplicate of this bug. ***
Comment 17 Bill Nottingham 2004-09-13 17:46:24 EDT
*** Bug 132480 has been marked as a duplicate of this bug. ***
Comment 18 Daniel Malmgren 2005-05-18 03:00:19 EDT
Has anyone at the Fedora team looked at initng? It's a quite new
project, but it's already stable enough for me to have it as default
in my Grub config. By switching from SysVinit to initng I shortened my
boot time by about 30 seconds.

Have a look at http://initng.thinktux.net/
Comment 19 Wade Mealing 2006-10-16 01:38:04 EDT
I'm sure this has been thought of, perhaps it is already done.

Allow the user to start typing in the username and password during RHGB.  I
spend 2-5 seconds at this screen depending on how co-ordinated I am at the time.
 This would reduce the time to "login" for desktop users.

Comment 20 Gregory D. Weber 2007-08-01 11:31:00 EDT
(In reply to comment #7)
> Also, all network related services (that require network access to start) should
> auto-detect an "up" interface, (no up interface, just fork a wait and retry
> process into the background and exit the current process so the boot will
continue).
> 

However, NFS is a network related service, and if the /home directory is mounted
via NFS, then you wouldn't want to give desktop users the illusion that they
could log in before /home is successfully mounted!
Comment 21 Bug Zapper 2008-04-03 11:29:13 EDT
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.

If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Comment 22 Bug Zapper 2008-05-06 19:56:45 EDT
This bug has been in NEEDINFO for more than 30 days since feedback was
first requested. As a result we are closing it.

If you can reproduce this bug in the future against a maintained Fedora
version please feel free to reopen it against that version.

The process we're following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

Note You need to log in before you can comment on or make changes to this bug.