On Thu, 8 May 2008, Martin Hicks wrote:
> On Fri, May 09, 2008 at 05:35:25AM +1000, Ken McDonell wrote:
> > And in fact pmie has accumulated so much state about metric meta data
> > and historical metric values, that any re-reading of the config file
> > would almost certainly mean forgetting all of that and starting again.
> > Functionally this would be like killing pmie and starting again ...
> > which is already supported .. 8^)>
> What I really need is a chroot-safe way to reload pmie.
> You can't do `/etc/init.d/pmie restart` because that would start pmie
> in the chroot.
> It seems that many initscripts support a "reload", which checks a PID
> file and sends a -HUP signal if they are (in this case) pmie processes.
> I need this because I have an RPM with its own pmie rules file. (The
> RPM adds a new process to the pmie control file). When this RPM is
> upgraded it needs to restart pmie in order to get these new rules
> loaded. The catch is that this RPM is frequently installed in a chroot.
i think we have some good news for once: pmie *already* creates
per-process files in $PCP_TMP_DIR/pmie/<pid> (thats /var/tmp/ on linux).
In fact i believe "/etc/init.d/pmie stop" will actually do the right thing
(ie not kill a "global" pmie when run in a chroot).
unfortunately "restart" (== "start") run in a chroot will attempt to start
pmie instances. Fortunately, i dont think anything thats been done to date
will have triggered this. (Installing the monitoring rpm chkconfig's pmie
on, but nothing should be started til the image is (re)booted). So the
presence of any /var/tmp/pmie/[0-9]* is enough to guarantee that we are
not in a chroot.
so a reload can simply be a restart conditional on the existence of such a
file. If i dont get that in quickly enough u can always check for such a
file in your spec $postun