On Thu, Apr 10, 2014 at 08:20:59PM +0000, Harlan Stenn wrote: > Rob writes: > > Furthermore, the "simple solution" of having SIGHUP perform an exec > > of the same binary, thus in fact restarting the entire process and > > losing all state information, is not the only possible solution. > > If the current process has chroot()ed, how do you re-exec? How do you > handle the things that are done before the chroot()? Again, I haven't > looked at the code to be sure, but I believe there are some things that > will behave differently if they are attempted from the chroot() target. > > Sure, one could have a top-level master process that simply waits for > the chroot()ed subprocess to die and then restarts it, but we're > starting to get in to a lot of wheel-reinventing here, and would this > really be worth the overhead on a program that is already larger and > more complicated than many folks want?
That sounds like a horrible hack. Even without chroot it will be difficult. If the ntpd process dropped root privileges after start, it won't be able to re-exec and it may not have permissions to open newly added refclocks or reread the keys, for instance. -- Miroslav Lichvar _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
