Hey Thomas,
----- Original Message -----
> Hi.
>
> Who should be able to send the SIGHUP? If it is only root, then you
> can
> use the solution with dropping privileges like you did during normal
> system boot.
I guess you mean if we used seteuid originally (and not setuid) to set
the user away from root? Such that pmcd can then switch back to root,
temporarily, when SIGHUP arrives and it can (re)start child processes?
> Does restart mean "exit and exec"
Yeah, we can't do that - that'd terminate client connections (more
detail on the issues that causes below).
> or just resetting the configuration of the running processes?
Yes, but thats not a "just", it involves starting child processes which
may need to run as e.g. user "postgres". When pmcd runs as root this
is not a problem, but as an unprivileged user it presents challenges of
course.
> > And without disruption to any of pmcd's existing
> > client connections. Perhaps a setuid helper could do this bit
> > somehow
> > but this is the bit that's not really clear in my head at this
> > stage.
>
> Hm, so if you want to not interrupt the client connections you don't
> want to exit the process I assume, or are you using UDP?
Correct, and it is TCP-based. In particular, for the PMDAs exporting
event data, which involves per-client state, restarting pmcd (and all
existing PMDAs) is particularly disruptive & so not really an option.
Even for the "regular" PMDAs exporting sampled metrics, having to end
all their connections means they will miss their next value while they
reconnect and re-establish their state (rate converting counters means
client side state held from previous sample, which gets messed up on a
reconnect). Definitely we want to avoid client reconnects which means
SIGHUP handling has to be smarter than just restarting pmnd.
> What about two completely separate processes? The unprivileged one
> which
> handles the client connections could buffer client requests during
> the restart (exit/exec) of the privileged process.
Yeah, possibly, either way the solution is starting to get complex ...
I guess we've circled back to my original point anyway, that its a bit
of a non-trivial problem. :)
cheers.
--
Nathan
|