[Pkg-openldap-devel] Bug#254999: slapd: postinst conflicts with daemontools (should also conflict with runit)
Russ Allbery
rra at debian.org
Fri Jun 1 23:45:32 UTC 2007
retitle 254999 slapd: provide a way to tell slapd not to start
thanks
Hello,
Some years ago (about three years now), you reported the following bug
against the slapd Debian package:
> I've encountered a problem with slapd under daemontools which should
> also affect slapd if running under runit. In postinst, there is an
> attempt to start slapd unconditionally using the /etc/init.d/slapd
> script which fails if slapd is already running (very likely, slapd is
> also not stopped during the upgrade, either). The result is that an
> upgrade of slapd fails. If I manually stop slapd, then complete the
> upgrade, then restart, everything is fine.
>
> It would be nice if the maintenance scripts could handle such a case,
> maybe using a variable like START_SLAPD in /etc/default/slapd, to
> minimize downtime.
So that you know, the supported way of disabling an init script in Debian
is to rename all of the S* links to K* links in /etc/rc?.d. If you do
this, all Debian packages will honor it and will not automatically try to
start slapd on package installation.
However, it is convenient for various reasons to provide a quicker way
(particularly to undo) to tell slapd not to start. For that, having to
modify the default file isn't very good either, since it's annoying to do
that automatically through a configuration management system.
Stanford has for some years used an init script that declines to start
slapd if a file exists on the local system (we use /etc/noldap and
/etc/noservices for various reasons). My inclination with this bug is to
add another option to /etc/default/slapd that specifies a sentinel file,
something like:
# If this variable is set and the file it points to exists, the init
# script will not start slapd. Useful for temporarily disabling services
# for whatever reason.
#SLAPD_SENTINEL_FILE=/etc/noldap
(Debian really needs a more automated way of doing things like this, but
that's a larger discussion that won't resolve soon.)
If the other OpenLDAP package maintainers agree, I'll implement this.
--
Russ Allbery (rra at debian.org) <http://www.eyrie.org/~eagle/>
More information about the Pkg-openldap-devel
mailing list