cyrus configuration reload without service interuption

Alain Spineux aspineux at gmail.com
Wed Jan 9 05:47:24 EST 2008


On Jan 9, 2008 1:38 AM, Ken Murchison <murch at andrew.cmu.edu> wrote:
> Alain Spineux wrote:
> > Hi
> >
> > When cyrmaster receive a SIGHUP, it reload its configuration file,
> > stop/start the the required services
> > and schedule new "EVENTS".
> > But running imapd, pop3d ... keep running until they "expire" (timout
> > waiting for a new connection, or reach
> > the maximum number of connection).
> >
> > For example, if you need to replace your certificate or added new
> > cyrus admins to imapd.conf , you need to make a restart,
> > (this mean a disconnection, of already connect users) if you want to
> > use the new stuff immediately.
> >
> > I would like to provide a patch to avoid this.
> >
> > Here is the idea:
> > When cyrmaster get a SIGHUP, It does as before, but send a SIGHUP to
> > all imapd, popd process too. The sig_handler
> > of these processes will  update their connection counter to a value
> > above the limit and then will no accept new connection and
> > then will shutdown!
>
> The services already check to see if their binaries have changed out
> from under them, and do as you explain above.  Simply touch'ing the
> binaries will have the same effect.

Yes this is exactly what I want !

>
> I supposed we could also have the services check for a new imapd.conf.

Touching the binary is not very friendly for distribution that keep
size, time, .... info about
all files in every packages, they will report them as changed!
Touching the configuration file is more recommended.

Anyway the existing system is not working as expected!
The check is done only after the end of a connection and
before if fall into an accept() ! If the changes appends when the
service is blocked in the accept,
the service handle one more connection before to detect the change!
This is true for signals too, because the handler use
action.sa_flags |= SA_RESTART; (at least in linux)
and then the "accept()" doesn't terminate. BUT then the service become sensible
to a second signal and will terminate (because of the use of
action.sa_flags |= SA_RESETHAND;)
, this is maybe a BUG, if this append in the middle of a connection ?

The SIGALRM doen't suffer this probleme because SA_RESTART is not set for it !
Maybe cyrus should avoid the use of SA_RESTART for HUP too





The solution is to send it a SIGHUP to force the accept to fail.
Anyway the SIGHUP is not working !

>
> --
> Kenneth Murchison
> Systems Programmer
> Project Cyrus Developer/Maintainer
> Carnegie Mellon University
>



-- 
Alain Spineux
aspineux gmail com
May the sources be with you


More information about the Cyrus-devel mailing list