[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Interesting article on boot ordering

hp redhat com (Havoc Pennington) writes:

> Some UI goals to keep in mind for reworking bootup include:

For me, UI goals are nearly uninteresting. Reliability and performance
are much more important:

* when processes like sshd or httpd are dying (e.g. logrotation,
  complications with nss_ldap), the best thing which will happen
  with LSB/SysV initscripts is that I see a warn-message on my
  pager and I have to drive 30km to restart the service manually.
  This is a design-issue; LSB/SysV initscripts do not support the
  respawning of services (except getty's in /etc/inittab which is
  really primitive).

  With alternative concepts (e.g. minit, djb's supervise, runit, ...),
  the died process would be restarted automatically.

* performance is unimportant at the first glance (usual linux servers will
  not be rebooted very often). But when having on a machine 50+ vservers
  which will be started sequentially, the bloat and implementation weaknesses
  (expensive bash-invocations, lots of interpreted sh-commands, UTF8 locales)
  of initscripts become very painful.

  With minit, the service-invocation happens in parallel and consists
  of 'malloc(...); read('params',...); execv(...);' basically. When
  using lightweight services (e.g. 'fgetty' instead of 'mingetty',
  'socklog'/'svlogd' instead of 'syslog'), this is really fast.

>  - making the boot fast

minit on my laptop needs 7 seconds from /sbin/minit startup till the
'login:' prompt. Shutdown happens in 5 seconds.

initscripts are taking 40+ seconds for startup and 45+ seconds for

minit-vservers are starting in 2 seconds and need 4 seconds for shutdown,
while initscript-vservers are taking 3-4 seconds + 14 seconds. There are
around 1-2 seconds overhead in the /usr/sbin/vserver script (e.g for
nss-lookups, lots of interpreted bash-scripts, a 'sleep 2' for 'start').

>  - almost as useful though, getting to a login prompt as soon as  
>      possible; so if we can continue some stuff in the background 
>      while the user logs in, that's almost the same as just getting
>      rid of it from a timing standpoint

Yes; this is parallelizing which is implemented in minit. You can
e.g. create a 'getty' service which has something like

| loadkeys
| kbdrate
| fgetty/1
| ...
| fgetty/6

in its 'depends' file. 'loadkeys' and 'kbdrate' are having a 'sync' flag
(I do not know if it makes much sense/if it is possible to execute them
in parallel), while 'fgetty/[1..6]' are just marked as 'respawn'. Then,
'minit' executes loadkeys-service and kbdrate-service sequentially, and
then the six fgetty-services in parallel.

Most services can be executed in parallel also, but some are requiring
e.g. 'named' which can be solved by making it a 'depends' of the

>  - graphical display showing progress (with optional way to get at 
>      the detailed technical messages, of course)

7 seconds boot-time (+5 seconds kernel-startup) do not require a
progress-meter... ;)


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]