[Xymon] Xymon client doesn't clean up all of its children

[J.C. Cleaver]

On Thu, February 26, 2015 10:44 am, Novosielski, Ryan wrote:
> However, the result is that you can't do a restart on Solaris 10 with SMF
> if you are using vmstat. I have patched my scripts on Solaris to kill the
> child processes.
>

>
> On Feb 26, 2015, at 13:17, John Thurston
> <john.thurston at alaska.gov<mailto:john.thurston at alaska.gov>> wrote:
>
> On 2/26/2015 9:14 AM, Mark Felder wrote:
> ~~ I can't verify on other OSes right now, so I'm hoping someone can
> chime in ~~
>
> On FreeBSD when I stop the Xymon client process it doesn't clean up all
> of its children. Primarily you'll find that the vmstat command is not
> sent a signal and continues to run ... indefinitely?
>
> I have observed this behavior on Solaris, but the vmstat does eventually
> disappear. It does not run forever.
>


That's... interesting. vmstat (and anything of a similar nature) is indeed
being forked via nohup on a 5m timer. If it lasts more than 5m after the
last run of xymonclient.sh, there's definitely something wrong somewhere.
I wasn't aware that backgrounded processes like that could cause a problem
for Solaris under SMF though.

It does raise the question a little of three changes I'd considered
committing, but wanted to get differing perspectives on (especially from
non-Linux OS's):


1) Pipe the vmstat command to a nohup'd shell instead of executing it
directly. I'm curious if it might help SMF cope a little better, but must
confess that the primary reason was simply to have a 'ps' output that
doesn't look quite as scary:

 5599 ?        S      0:00 /bin/sh
 5602 ?        S      0:00  \_ vmstat 300 2


2) Kill backgrounded vmstat (or any other processes) owned by the
configured user when given a 'stop' SysV script command, but *not* when
given a 'restart'.


3) Generally speaking, patch the startup scripts and default configuration
to simply run 'xymoncmd /path/to/xymonlaunch --log=/path/to/log/file'.
This was the path I took for putting in systemd compatibility, and it's
possible it might provide something simpler for OSs' service monitors to
track too.


Long time users of the Terabithia RPMs might notice that these three have
been in for a while, but going beyond RH-derived Linux distros is a bigger
step.



What would you folks think?

-jc