Re: About to commit removal of global_backendsync code and have onemore enhancement

[Randy Kunkee <randy@randallkunkee.com>]

Mark Adamson wrote:

> On Thu, 28 Jun 2001, Randy Kunkee wrote:
>
> > I have one more enhancement I'd like to offer.  This is a simple change
> > to allow a signal to the slapd process to restart the server using the
> > same arguments it was called with in the first place.  I use this to
> > restart the version 1.2.x slapd process in order to get a fresh slapd
> > running nightly.
>
> Are you talking about a signal handler than runs exec()?  Or how are you
> planning to implement this?  I'm wondering what the advantage is over
> having a "restart" option in an rc script that sends SIGINT to the running
> server and then starts a new one.
>

Yes, execv to be precise, but you have the idea.  The advantage is absolute
minimum down time in this circumstance.  If a script does it, it has to look
to see if the process is still running by sending kill -0 to the pid.  It
might be more proper to not run slapd in daemon mode so that one could just
wait on the child process, but I'm not willing to give up daemon mode, and
yet high availability is of the essence.

>
> > By the way, the signal I have been using is "SIGQUIT" which was not my
> > first choice, but SIGUSR1, SIGUSR2, SIGHUP, SIGINT, SIGTERM are all
> > taken.  So it will be SIGQUIT, unless somebody has a better suggestion.
>
> If you're willing to wander off from the tourist trap signals, there is
> SIGPWR on Solaris, Linux, et al.  I just glanced through the signal.h
> files and that seemed to fit what you're doing -- "power cycling" the
> slapd process. Hardcore compliance people will no doubt blanche at the
> notion...
>

SIGPWR could be alright.  Right now, most of the above signals all do the
same thing -- shut down slapd.  I don't think there's any reason not to
assign SIGUSR1 or SIGUSR2 for this purpose.

>
> -Mark Adamson
>  Carnegie Mellon

Randy