Attempting to develop a launch plist for sysmon
A few years ago I wrote a Mac OS X StartupItem for sysmon <http://www.sysmon.org/> and I've been attempting to write a launchd plist for it now that I've migrated my monitoring server to Leopard Server (currently 10.5.3). Here's my /Library/LaunchDaemons/com.makkintosshu.sysmon.plist (owned by root:wheel with permissions of 750): <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>com.makkintosshu.sysmon</string> <key>ProgramArguments</key> <array> <string>/usr/local/bin/sysmond</string> <string>-d</string> </array> <key>OnDemand</key> <false/> <key>KeepAlive</key> <true/> <key>RunAtLoad</key> <true/> </dict> </plist> I use both the OnDemand and KeepAlive keys in the hopes of supporting both Tiger & Leopard with this file. Will I run into any issues there (I've currently only tested with Leopard Server)? Also, it seems to work correctly (sysmond loads, loads it's config file, and binds to its TCP port fine; plus if you kill the process launchd starts it up again) if I run `sudo launchctl load -w /Library/LaunchDaemons/com.makkintosshu.sysmon.plist` after boot, but if I leave it loaded (or, at least, if I don't disable it using `sudo launchctl unload -w /Library/LaunchDaemons/com.makkintosshu.sysmon.plist`) at boot, sysmond acts as if it didn't have any config files to load and it usually takes an unload & load of the launchd plist to get it to function normally. Any ideas as to what might cause this? Will I have to start investigating sysmond's source to see if it's a dependency checking issue? Shouldn't the file system be available upon loading the job and only network services might be unavailable? Thanks in advance, Morgan Aldridge --- morgant@makkintosshu.com http://www.makkintosshu.com/
I also have a question about this. I have been looking at the man page for launchd.plist on 10.4, and it does not list a KeepAlive key. Does that mean that it won't work? It doesn't seem to be working. Is there another way to keep a daemon running another way? Thanks Nathan -----Original Message----- From: launchd-dev-bounces@lists.macosforge.org [mailto:launchd-dev-bounces@lists.macosforge.org] On Behalf Of Morgan Aldridge Sent: Friday, August 01, 2008 3:09 PM To: launchd-dev@lists.macosforge.org Subject: [launchd-dev] Attempting to develop a launch plist for sysmon A few years ago I wrote a Mac OS X StartupItem for sysmon <http://www.sysmon.org/> and I've been attempting to write a launchd plist for it now that I've migrated my monitoring server to Leopard Server (currently 10.5.3). Here's my /Library/LaunchDaemons/com.makkintosshu.sysmon.plist (owned by root:wheel with permissions of 750): <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>com.makkintosshu.sysmon</string> <key>ProgramArguments</key> <array> <string>/usr/local/bin/sysmond</string> <string>-d</string> </array> <key>OnDemand</key> <false/> <key>KeepAlive</key> <true/> <key>RunAtLoad</key> <true/> </dict> </plist> I use both the OnDemand and KeepAlive keys in the hopes of supporting both Tiger & Leopard with this file. Will I run into any issues there (I've currently only tested with Leopard Server)? Also, it seems to work correctly (sysmond loads, loads it's config file, and binds to its TCP port fine; plus if you kill the process launchd starts it up again) if I run `sudo launchctl load -w /Library/LaunchDaemons/com.makkintosshu.sysmon.plist` after boot, but if I leave it loaded (or, at least, if I don't disable it using `sudo launchctl unload -w /Library/LaunchDaemons/com.makkintosshu.sysmon.plist`) at boot, sysmond acts as if it didn't have any config files to load and it usually takes an unload & load of the launchd plist to get it to function normally. Any ideas as to what might cause this? Will I have to start investigating sysmond's source to see if it's a dependency checking issue? Shouldn't the file system be available upon loading the job and only network services might be unavailable? Thanks in advance, Morgan Aldridge --- morgant@makkintosshu.com http://www.makkintosshu.com/ _______________________________________________ launchd-dev mailing list launchd-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/launchd-dev
At 18:09 -0400 1/8/08, Morgan Aldridge wrote:
I use both the OnDemand and KeepAlive keys in the hopes of supporting both Tiger & Leopard with this file. Will I run into any issues there (I've currently only tested with Leopard Server)?
As long as you still need to support 10.4.x you'd be better off just using "OnDemand". It's supported, albeit deprecated, on 10.5. At 12:51 -0700 4/8/08, Nathan Wan wrote:
I also have a question about this. I have been looking at the man page for launchd.plist on 10.4, and it does not list a KeepAlive key. Does that mean that it won't work? It doesn't seem to be working. Is there another way to keep a daemon running another way?
"KeepAlive" will not work on 10.4.x. "OnDemand" is your only choice. It's not as flexible, but it will do the job. At 18:09 -0400 1/8/08, Morgan Aldridge wrote:
Any ideas as to what might cause this? Will I have to start investigating sysmond's source to see if it's a dependency checking issue? Shouldn't the file system be available upon loading the job and only network services might be unavailable?
My guess is that this is related to networking. Startup items, since 10.4, have automatically been given a dependency on networking for compatibility reasons. If you convert to launchd, you lose that dependency and it's likely you come up /way/ before the networking stack. Lots of traditional UNIX code doesn't handle that well. Just for the sake of debugging this, have you tried adding "NetworkState" to your property list (in the "KeepAlive" dictionary, as documented by <x-man-page://5/launchd.plist>). This will prevent you from coming up until the network is up. It's not the long-term solution to this problem, but it would allow you determine whether the problem is networking or something else. S+E -- Quinn "The Eskimo!" <http://www.apple.com/developer/> Apple Developer Relations, Developer Technical Support, Core OS/Hardware
participants (3)
-
Morgan Aldridge
-
Nathan Wan
-
Quinn