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

Re: Debian, daemons and runlevels (was: Re: X and runlevels)

On Thu, 07 Sep 2000, Craig Sanders wrote:
> On Mon, Sep 04, 2000 at 10:28:20AM -0300, Henrique M Holschuh wrote:
> > I was going to tack this sooner or later (the "trust us, we KNOW you
> > want the daemons to start always" current state of almost all daemon
> > packages annoys me to no end, and from past flamewars I know I'm not
> > the only one), I think I even warned a few newbies in -user two days
> > ago about this :-)
> it is a reasonable assumption to make - if someone installs a package

Yes, it is. But it is just that: an assumption. That's all we can do right
now for package installs, and it CAN be argued that it's all we should ever
do in package installs.  My current issue is with package upgrades.

So, please, let's not even get into the 'start daemons at package install'
issue right now. Let me tack the upgrade problem first, and when that's done
and ready (please note I didn't say "accepted"), we can move to the install
problem and we can argue all you want about it.

Here is what I'm trying to fix: Upgrading a daemon while the system is in
runlevel 4 and the init script system is set up to stop that daemon in
runlevel 4 is a *bug*.

If you call the script which addresses the upgrade issue during installs as
well, it won't malfunction (this is a design requirement), and you can share
the same code for upgrades and installs. It *could* be used to avoid
starting a daemon during installs if extended to do so, but it doesn't
_have_ to.

> > The solution is to *force* all daemon packages to never start a daemon
> > out of its intended runlevel, be it during first install or upgrades
> > (I think this probably requires a policy change). I'd even say this
> > should be a goal for woody, unless we're going to try to get woody out
> > of the door very fast.
> this sounds bloody annoying.

If everyone had to write a lot of complicated code to get this to work, I'd
agree with you.  As it stands, I'm writing all the code needed for sysvinit,
and I could even try to do the same for file-rc after the sysvinit code is
ready, tested, published to -devel and ripped to shreds.

A *design* goal in this stuff is that: If you do nothing to the defaults,
the system will act just like it does today. In *all* cases, even the highly
unlikely ones such as no init system at all being installed.

You as a maintainer will have to add something that boils down to:


 update-rc.d foo bar foobar barfoo
+if canIstartTheDaemonPlease daemonname; then
+   /etc/init.d/daemoname start


After all error checking is stripped off.

> if you don't want a service to start, then don't install the package.
> simple, really.

As I said, let's leave that issue alone for now, please.

> no package manager can read your mind.   you're still going to have to do

It doesn't need to, I consider the start on upgrade as it stands a bug
because the system can detect what it should do, unless I am overlooking
something... which is why I'm trying to get the code done and working before
posting anything else to -devel.

  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Attachment: pgpUrj2q648Ti.pgp
Description: PGP signature

Reply to: