Re: Future of update-rc.d in wheezy+1
On Sun, Jul 01, 2012 at 06:39:57PM +0200, Stephan Seitz wrote:
> On Thu, Jun 28, 2012 at 10:52:23AM +0100, Roger Leigh wrote:
> >On Thu, Jun 28, 2012 at 10:44:53AM +0200, Goswin von Brederlow wrote:
> >>The numbers specified for update-rc.d must be well ordered
> >>according to the dependencies specified in the LSB headers. That
> >>means that that
> >>update-rc.d could keep a record of the numbers specified and check that
> >>the numbers are valid even though sysv-rc/insserv then ignore them.
> >While we could expend the time and effort to do this, I do have to
> >question why. What would be the point of this? No one is using
> >those numbers, so why retain them? It seems, to me, to be an
> >entirely pointless waste of valuable developer time. And not just my
> >time, but for every developer who would need to continue to test and
> >validate the numbers for their scripts.
> >
> >We have dependencies for a reason, and the sequence numbers are now
> >nothing more than a historical artifact.
>
> Well, I’m using file-rc on all my systems for many years.
> - „vi /etc/runlevel.conf” is easier than working with strange symlinks;
> - if I don’t want a service to start, I can replace „2,3,4,5” with „-”;
> - third-party software without Debian package doesn’t use
> update-rc.d; getting it to start is easier if I only have to edit
> one file (runlevel.conf);
No one messes with symlinks. We have update-rc.d for that for both
sysv-rc and file-rc. For sysv-rc, insserv manages them for you,
and in theory we could even get rid of them entirely and have the
dependencies computed at runtime. We'd just need a mechanism for
recording which scripts were disabled.
When you edit runlevel.conf, you have to maintain the script ordering,
by hand, using the sequence number field. This is (or is becoming)
utterly broken, and is why we have dependency based booting nowadays.
The numbers are computed automatically by insserv; this is far less
error prone and much more flexible.
> I have never used dependency based booting.
> - old systems had to many old init scripts without LSB headers, so
> the upgrade failed;
> - some software needs a database, but the database server may not be
> the same server, so the software can’t have a dependency on the
> database server; so I have to overwrite the dependency
> configuration in some way;
> - third-party software doesn’t have any LSB headers;
> IIRC the upgrade to dependency based booting doesn’t fail anymore if
> you have initscripts without LSB headers (they are now running at
> the end of the boot process), but for now I still don’t see any
> reason to change.
Given that it's been the default for quite a few years now, you really
should try it. The sequence numbers are going away, so if there are
problems with it that you need fixing, then they need indentifying and
reporting. Editing the LSB headers in the scripts to do stuff like
not depend on a local server is not exactly rocket science. And we
have Should-Start rather than Required-Start for exactly this
situation--if you found a buggy LSB dependency, for goodness sake
report it and get it fixed, rather than perpetuating the awful
static sequence numbers. Dependency based boot works, and works well.
There is no reason to continue to use file-rc.
[I spent the weekend adding insserv support to file-rc. But the
consequence of computing the sequence numbers automatically is that
it no longer makes sense to edit runlevel.conf by hand--adding or
removing an init script could recompute the sequence numbers of
many scripts. runlevel.conf is essentially just marking scripts
as enabled if present, disabled if absent.]
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
Reply to: