On Mon, Jul 09, 2001 at 05:16:14PM -0000, pop corn wrote:
> I already did a "man svc". Here are two quotes:
> From the OpenLDAP 2.0 Administrator's Guide at:
> http://www.openldap.org/doc/admin/runningslapd.html#Stopping slapd
> 6.3. Stopping slapd
> To kill off slapd safely, you should give a command like this
> kill -INT `cat /usr/local/var/slapd.pid`
> where /usr/local/var is determined by configure.
> Killing slapd by a more drastic method may cause information loss or
> database corruption.
This is a dramatic design failure in OpenLDAP. What happens on system
shutdown? Right, all processes get a TERM signal.
I haven't read these statements until today, but it explains OpenLDAPs poor
behaviour (meaning database not beeing writeable any longer) twice a year or
so. Who files a bug report?
Oh, I hear you saying: just use kill -INT blabla in your
/etc/rc.d/rc.2/slapd or whatever it is. But Note that this is SysV specific,
and there are non-SysV unices around (all BSDs for example), and this is a
Good Thing (tm). I really don't like this SysV init style, but I'll stop my
rant now.
Nontheless, instead of working around this OpenLDAP bug in daemontools fix
OpenLDAP.
> better to stop slapd than svc -d. However, even if I use svc -i to stop
> slapd, will svc -i necessarily know to send the INT signal to the process id
> specified in the file slapd.pid as recommended in the OpenLDAP
> Administrator's Guide?
Of course. supervise (for slapd) is a child of svscan (so svscan knows it's
PID) and slapd is a child of supervise so supervise knows slapd's PID.
These PID files are a design failure. Think of starting slapd with PID 2163.
For one reason or the other slapd is terminated without removing the PID
file. Later another process, let's say qmail-send, is started and gets PID
2163. You didn't notice that slapd was terminated and issue a "kill `cat
/var/run/slapd.pid`". Congratulations, you killed qmail-send but wanted
slapd. Surprise surprise. With daemontools all daemons are child processes
of their supervise instance and such a mess simply cannot happen.
> I am not trying to argue with you, I am only trying to understand exactly
> how to stop slapd because of the warning from the OpenLDAP Administrator's
> Guide above: "Killing slapd by a more drastic method may cause information
> loss or database corruption.".
There is one problem I see about twice a year, OpenLDAP can no longer make
updates. erasing a reinitializing the database fixes this. (btw, OpenLDAP
1.2.11). BUT this is in no way related to killing the process. In production
usage there is no reason to stop and restart slapd or to stop it at all. So
it only gets killed on reboots, and OpenBSD machines don't boot that often
usually ;-))
This behaviour is an OpenLDAP bug. I'd file a bug report. Maybe I'll do that
later today, but I'm really busy at the moment and if someone else could do
do it it'd be nice.
--
* Henning Brauer, [EMAIL PROTECTED], http://www.bsws.de *
* Roedingsmarkt 14, 20459 Hamburg, Germany *
Unix is very simple, but it takes a genius to understand the simplicity.
(Dennis Ritchie)
