Slashdot/IBM: How To Speed Up Linux Booting
erich.schubert at gmail.com
Wed Apr 11 12:12:14 UTC 2007
> Writing new init scripts once is easy, maintaining them forever is the
> key issue here.
Which is why it makes sense to generate them from a common core,
instead of writing separate scripts for each init, doesn't it?
> > You want to be able to switch init systems on a running system; diversions
> > take immediate effect, not on the next reboot. Diverting invoke-rc.d might
> Do you? This does not look like an important requrement to me.
> It's probably not possibile anyway with complex ("interesting"... there
> is no big need for half a dozen sysvinit clones) init systems like
I was not referring to switching init systems *live*, but on *reboot*.
But you might be aware that init is also involved in shutdown.
Diverting invoke-rc.d can
also make subsequent package installations fail in a not really predictable way.
For example, the mysql-server script probably tries to stop the mysql
server, then fix some tables, then start it again.
Now assuming we have an init which respawns services, but invoke-rc.d
was just diverted.
So the mysql-server upgrade script stops mysql, the service monitor
restarts it, and the upgrade script modifies a live table. boom.
Anything bad can happen.
If invoke-rc.d isn't diverted, but detects which init is running, it
will tell the service monitor to stop mysql, and it won't be restartet
A similar thing can, btw., easily occur with monitors such as monit.
thats why we definitely could use some integration for them, too.
(P.S. and an appropriate way of detecting which init is running is
probably comparing the inode from /proc/1/stat with /sbin/init*, and
falling back to /proc/1/exe)
erich@(mucl.de|debian.org) -- GPG Key ID: 4B3A135C (o_
To understand recursion you first need to understand recursion. //\
Wo befreundete Wege zusammenlaufen, da sieht die ganze Welt für V_/_
eine Stunde wie eine Heimat aus. --- Herrmann Hesse
More information about the initscripts-ng-devel