Older tricks for this included StartupItems, which apparently no longer work as of Yosemite, let alone El Capitan.
MacPorts has a really strange solution, but I'm not impressed at all with it.
I see that xymonlaunch has a --no-daemon option, which would allow the sort of behavior that launchd expects. An old post mentions an approach using that: http://lists.xymon.com/oldarchive/2009/05/msg00244.html
Seems to me that if runclient.sh handled an extra command line option to pass --no-daemon through to the xymonlaunch command line, it would simplify matters somewhat, not requiring people to check that their modified script was updated as needed; all that would be needed extra would be a com.xymon.client.plist file to put in /Library/LaunchDaemons; and that shouldn't vary from one update to the next.
What I'm suggesting should probably work at least as far back as Snow Leopard (OS X 10.6) if not further. I haven't tried it yet, but I'm on my way to doing so.
Ok, what I wanted to do seems to work fine. Attached are the modified runclient.sh and my launchd plist file. The latter would need the account name, group name, and pathnames modified as necessary (I installed in /Users/xymon/client, which may not be typical).
The modified runclient.sh will also exec xymonlaunch rather than run it and wait for it, if --no-daemon is passed; might as well save one shell process. :-) It also allows passing --debug and --verbose options through to xymonlaunch. None of which should affect its conventional use.
On Feb 9, 2016, at 09:35, Richard L. Hamilton <rlhamil2 at gmail.com> wrote:
Older tricks for this included StartupItems, which apparently no longer work as of Yosemite, let alone El Capitan.
MacPorts has a really strange solution, but I'm not impressed at all with it.
I see that xymonlaunch has a --no-daemon option, which would allow the sort of behavior that launchd expects. An old post mentions an approach using that: http://lists.xymon.com/oldarchive/2009/05/msg00244.html
Seems to me that if runclient.sh handled an extra command line option to pass --no-daemon through to the xymonlaunch command line, it would simplify matters somewhat, not requiring people to check that their modified script was updated as needed; all that would be needed extra would be a com.xymon.client.plist file to put in /Library/LaunchDaemons; and that shouldn't vary from one update to the next.
What I'm suggesting should probably work at least as far back as Snow Leopard (OS X 10.6) if not further. I haven't tried it yet, but I'm on my way to doing so.
On Tue, February 9, 2016 8:22 am, Richard L. Hamilton wrote:
Ok, what I wanted to do seems to work fine. Attached are the modified runclient.sh and my launchd plist file. The latter would need the account name, group name, and pathnames modified as necessary (I installed in /Users/xymon/client, which may not be typical).
The modified runclient.sh will also exec xymonlaunch rather than run it and wait for it, if --no-daemon is passed; might as well save one shell process. :-) It also allows passing --debug and --verbose options through to xymonlaunch. None of which should affect its conventional use.
On Feb 9, 2016, at 09:35, Richard L. Hamilton <rlhamil2 at gmail.com> wrote:
Older tricks for this included StartupItems, which apparently no longer work as of Yosemite, let alone El Capitan.
MacPorts has a really strange solution, but I'm not impressed at all with it.
I see that xymonlaunch has a --no-daemon option, which would allow the sort of behavior that launchd expects. An old post mentions an approach using that: http://lists.xymon.com/oldarchive/2009/05/msg00244.html
Seems to me that if runclient.sh handled an extra command line option to pass --no-daemon through to the xymonlaunch command line, it would simplify matters somewhat, not requiring people to check that their modified script was updated as needed; all that would be needed extra would be a com.xymon.client.plist file to put in /Library/LaunchDaemons; and that shouldn't vary from one update to the next.
What I'm suggesting should probably work at least as far back as Snow Leopard (OS X 10.6) if not further. I haven't tried it yet, but I'm on my way to doing so.
Thanks for the submits. The launch method used here is very similar to the that used on systemd systems, since they're both basically solving the same problem. This runclient support is coming in 4.4.
The plist seems like something generic enough to include in the tarball, I'd think The macports version itself seems somewhat out of date:
https://trac.macports.org/browser/trunk/dports/net/xymon-client/Portfile
Regards, -jc
Thanks for the submits. The launch method used here is very similar to the that used on systemd systems, since they're both basically solving the same problem. This runclient support is coming in 4.4.
The plist seems like something generic enough to include in the tarball, I'd think The macports version itself seems somewhat out of date:
https://trac.macports.org/browser/trunk/dports/net/xymon-client/Portfile
I nudged on their list to get an update, given that the latest fixes some significant security issues; we'll see what happens.
You might want to at least clean up the environment variables in the plist file. It may not be necessary to have them specified at all, but as a first attempt, I wanted something similar to starting it by hand. At the very least, the PATH should be reduced to system default, perhaps plus /sbin and /usr/sbin.
Mac account names can have aliases. Non-human accounts often have the underscore prefix with an alias without the underscore. I think with the underscore is how MacPorts installed it, although I added the alias because other systems don't tend to have account names beginning with an underscore, and it's one less thing for my fingers to remember. But it might look odd to some.
In the usual case, the umask (decimal equivalent of 022), and working directory, and capture of stdout/stderr might also be unnecessary. As I said, I overspecified everything just to be sure it would work, esp. with any of my own scripts that might expect the usual environment; but the plist file would be less bother if it were minimized. That would still leave pathnames, and account and group name, that could need changing depending on where and under what account/group someone installed Xymon.
Hi Richard
I nudged on their list to get an update, given that the latest fixes some significant security issues; we'll see what happens.
It happened ! I finally updated xymon client and server in macports ! ;-)
I took this opportunity to add "openmaintainer" to both ports. Feel free to participate in maintaining those ports and submit changes on the macports dev mailing-list:
https://guide.macports.org/#project.contributing
Cheers, Francois.
participants (3)
-
cleaver＠terabithia.org
-
fclaire＠free.fr
-
rlhamil2＠gmail.com