[Date Prev][Date Next]
RE: Seamless restarts
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'
> 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
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.
> 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'.
Why rename slapd.args, though? The sysadmin could 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.
> 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.