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

Re: RFC: fix for daemon start on package install/upgrade out-of-runlevel

On Sat, 09 Sep 2000, Robert D. Hilliard wrote:
> > > daemon is running, and only restart it if it found it was running?
> > 
> > Because if the user removes but not purges a package, all the configuration
> > data related to initscripts is kept. The daemon is not running, but the
> > runlevel restrictions must still be upheld (and stop-start-daemon cannot and
> > should not have to know about this). I hope you agree that such a partial
> > fix is undesirable when a complete one is available.
>      There would only be a problem in the rare case in which the
> sysadm had set up a daemon to run only in some run levels, then
> removed the package containing the daemon, then reinstalled it and
> expected it to resume its former behavior.  I think it is unreasonable

Yes. My point exactly: It doesn't work for all cases, and it's no simpler
than the complete fix. You have to take into account that you cannot stop
daemons in your preinst anymore for the restart trick to work, and now you
need to always differentiate upgrades from installs in your postinst. It
requires far more extensive changes to the packages than adding the call to
a initscriptquery script.

More trouble for less results IMHO.

> to make the packaging system system jump through hoops to save the
> sysadm from fixing it manually in this rare case.

The packaging system doesn't go through any more hoops than what's expected
of it: to obey the runlevels (if you tell me it is not expected to obey the
runlevels, I'll ask you why and where is it documented, and where's the
polite warning it should issue. I clearly told the system not to start that
daemon in that runlevel).  The added complexity on the average packager is
to copy-and-paste a small, easily understood, easy to debug script.

Someone went to a lot of trouble to set up the update-rc.d system. Thanks to
that, Debian's init script system is quite enjoyable to set up, and keep
control of. It doesn't try to do things behind your back. It doesn't change
your settings without warning.  IMHO we should finish the job update-rc.d
started, and close -completely- the last hole in the whole scheme. There is
no *need* to let the packaging system start daemons behind your back.

Also, although I didn't want even to broach the subject yet, a
initscriptquery-type solution allows for easy deployment of a _completely
optional_ (as in install an optional package implementing the stuff if you
want it) local policy to control the starting of daemons. I know some people
want this, I've read at least one request for it. And it would be completely
transparent to the packaging system (it's a small change done to the
initscriptquery script) and to the packages themselves.

> > I fear that detecting when a daemon is running in a generic way is not
> > always easy (I'll only know when I try to do it). Creating a generic
> > check-daemon-state script so as to make it easier for our initscripts to
> > conform to the LSB requirements of a "status" command is still in my todo
> > list, but at a rather low priority.
>      ps ax|grep <daemon-name>|grep -v grep works for me.

It won't work for all cases. Actually, it's extremely easy to break. I know
someone will post a far better regexpr sooner or later on this thread,

  "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: pgpSk0zHrYMAY.pgp
Description: PGP signature

Reply to: