RE: Seamless restarts

["Howard Chu" <hyc@highlandsun.com>]

> -----Original Message-----
> From: Hallvard B Furuseth [mailto:h.b.furuseth@usit.uio.no]

> Howard Chu writes:
> > Yes, I have a couple specific points:
> >    we talked about passing descriptors to the new slapd so
> that it can take
> > over client connections. I think this idea should be abandoned.
>
> Yes, I wasn't thinking of passing the clients, just to always have
> a slapd listener.  The clients would lose their connections, or they
> could get to use the old server for a while if it used the 'gentlehup'
> config option.

Right.
>
> > Some platforms don't support descriptor passing, and it's
> not possible
> > (AFAIK) to pass SASL or SSL context, so support would be
> incomplete at
> > best.
>
> Descriptors wouldn't have to be passed, since fork() and exec() do not
> close them.  I don't know anything about SASL/SSL context, though.

Maybe I was getting confused with the surrogate parent stuff. Right,
descriptor passing isn't an issue here, but regardless, it can be very
complicated to correctly hand off a client connection to a new slapd. Simpler
not to do it.
>
> >    there should be a way to change the commandline args of
> the new instance.
> > I propose that the slapd.args file be reread by the old
> slapd and used for
> > the args of the new slapd. A sysadmin can manually edit
> this file if new
> > options need to be specified for the new instance.
>
> Sounds OK.  The argsfile would have to be changed so we can tell
> a space between arguments from a space inside an argument, though.
> Maybe we should put one argument on each line.
> Also, some options would have to be ignored: '-u', '-g', '-r'.

Right.

> Why rename slapd.args, though?  The sysadmin could edit it in place.

Rename? I don't think I mentioned any rename. Definitely, edit it in place.
>
> We'd also need a 'slapdpath' config option or a slapd.path file
> with the pathname of the slapd daemon, since '-r' won't find slapd
> in the same place as the original filename.  I guess a config option
> is enough:  The admin can make the named path a symlink if he wants
> to change the path.  Or a shell script which starts slapd, if he
> does not have symlinks.

Symlinks are still parsed relative to the current filesystem root, so they
cannot be used. You must use hard links if you're going to use links at all,
which means that all the linked files must live in a single filesystem.
Generally this isn't the case, so that means you're stuck creating duplicate
copies of all your needed files.
>
> >    and of course, a few of the existing commandline args (like -h)
> > need to be implemented as config file options.
>
> Sounds hairy, since options are processed before '-r' and the config
> file after.  I don't think it's necessary if the options are
> read early
> enough from slapd.args.  The old server could give an '-a argsfile'
> option to tell the new slapd where to find it.

Yah, it may be simpler not to mess with this. This is an area that always
annoys me; I'd rather have the -h arguments in a config file, overridable
from the command line. Of course, it's a trivial inconvenience, nothing more.
And for the purposes of server restart, the slapd.args mechanism will do
fine.

The other issue in propagating the listener descriptors is telling the new
slapd instance which URI is associated with which descriptor(s) so that the
new slapd can initialize its own data structures correctly. Maybe a new
syntax like
	-h "(3,4,5)ldap://myserve.domain.com (6,7)ldap://localhost
(8)ldaps://foo.bar.com"
The new slapd will still have to use getsockname() or some other mechanism to
fill in some of the details (protocol family, address.)

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support