- launchd-dev - lists.macosforge.org

Re: [launchd-dev] Recommended tool daemon/agent install folder ... Is this list still active?
by Karl Moskowski 17 Sep '09

17 Sep '09

On 2009-09-16, at 3:25 PM, Brent Gulanowski wrote: > Now I'm curious if anyone here remembers the standard path for tools > on Mac > OS X which are launched by launchd -- there's a folder in Library > which > isn't created by default but is considered proper, but I can't > recall nor > find any mention of it. Brent, Apple's BetterAuthorizationSample uses /Library/ PrivilegedHelperTools/, and that location seems to have become a de facto standard. <http://developer.apple.com/samplecode/BetterAuthorizationSample/> Caveats: - ensure any installers keep the correct permissions and ownership on that folder; - ensure your tool is uniquely named, probably using reverse DNS notation (e.g., com.mycompany.foobard). (There are probably more.) ---- Karl Moskowski <kolpanic(a)voodooergonomics.com> Voodoo Ergonomics Inc. <http://voodooergonomics.com/>

1 0

launchd daemon launch delayed when (Snow) Leopard Server Firewall is on (port is open)
by Brent Gulanowski 17 Sep '09

17 Sep '09

We've found a problem with Daylite Server that if we turn on the Leopard Server Firewall and open the Daylite Server ports for incoming connections, launchd doesn't seem to get notified, or at best there is a long delay, which exceeds our timeout. Longer than two minutes. I have confirmed that launchd does eventually wake up by connecting with telnet. Turning the firewall off results in normal behaviour. I'm not sure where to start to identify the source of the problem. I could not find any other reports of this exact behaviour. If anyone has any thoughts or can point me in the right direction, that would be appreciated. Here is the property list as it is found in /Library/LaunchDaemons: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>GroupName</key> <string>_dayliteserver</string> <key>Label</key> <string>com.marketcircle.daylite.dlserver</string> <key>ProgramArguments</key> <array> <string>/Library/Application Support/Daylite Server/Daylite Server.bundle/Contents/MacOS/DLServer</string> </array> <key>Sockets</key> <dict> <key>Listeners</key> <dict> <key>Bonjour</key> <string>dlserver</string> <key>SockServiceName</key> <string>6113</string> </dict> </dict> <key>StandardErrorPath</key> <string>/Library/Application Support/Daylite Server/Logs/Daylite Server.log</string> <key>UserName</key> <string>_dayliteserver</string> <key>inetdCompatibility</key> <dict> <key>Wait</key> <false/> </dict> </dict> </plist> -- Brent Gulanowski

3 2

Recommended tool daemon/agent install folder ... Is this list still active?
by Brent Gulanowski 17 Sep '09

17 Sep '09

I posted a question a week or so ago, but either I used the wrong address or no one noticed. Haven't seen any messages on this list since I subscribed. My last question was about a lauchd job not starting immediately when the firewall on OS X Server was on. Now I'm curious if anyone here remembers the standard path for tools on Mac OS X which are launched by launchd -- there's a folder in Library which isn't created by default but is considered proper, but I can't recall nor find any mention of it. Thanks, -- Brent Gulanowski

3 2

Possible to modify a job in-memory?
by Sidney San Martín 15 Sep '09

15 Sep '09

How can I modify properties of a job (StartInterval, in this case) without un/reloading it from launchd? Ideally, I want a daemon to be able to modify its own StartInterval while running, so that it applies the next time the daemon idles out, and without disrupting any of its launchd-provided sockets.

1 0

Working with overrides.plist
by Dean Shavit 03 Sep '09

03 Sep '09

Kudos to the launchd team for finding a way of allowing a sysadmin to disable / enable a launchagent in /Library and the new by-uidNumber settings for launchagents on a per user basis. That solves a few issues for me. However, other than having to programmatically manipulate the overrides.plist, is there a sanctioned command to do so? I've noted of course that launchctl -w doesn't do it (as the man page states).

3 8

launchd and syslog.conf
by Jonathan del Strother 02 Sep '09

02 Sep '09

On 19 Aug 2009, at 18:39, Kevin Van Vechten <kvv(a)apple.com> wrote: > There are two pieces to the puzzle. The first step, as you've already found, is to appropriately adjust the syslog filters Really? A launchd.* syslog filter works for you on Leopard? I'll have to try it on a different machine later, because it's doing nothing for me here. -Jonathan

4 4

Re: [launchd-dev] launch_msg(): Socket is not connected
by Grant Erickson 02 Sep '09

02 Sep '09

On Wed Jun 24 04:14:23 PDT 2009 Quinn <eskimo1(a)apple.com> wrote: > At 23:31 +0530 18/6/09, Arjun SM wrote: >> I will take your word for it . I was of the notion that i have to >> support multiple users for my application. > > Well, there's a difference between supporting multiple users and > supporting all of the edge cases brought about by multiple users. I > totally agree that you should support multiple GUI users in general. > However, that presents some unique install, upgrade and uninstall > problems, and I think it's better that you solve those problems in a > nice simple manner (forcing a restart in the multiple user case, for > example) than do some convoluted hack that will break in mysterious > ways in the future. > > But hey, Mac OS X is a very open platform so you get to choose how to > spend your development time. > > And yes, we do recognise that this is a nasty wrinkle in the whole > launchd story and we hope to fix this eventually. It would appear that I just ran into this same problem with my preflight and postflight scripts for my agent / preference pane package. I solved the installer-side issue of launchctl running with root/admin credentials as Arjun did by using sudo/su; however, from this thread, it sounds like the: launch_msg(): Socket is not connected is a fatal dead end for the {pre/post}flight approach. My scripts effectively amount to: preflight: if "${LaunchctlExecutable}" list | /usr/bin/grep "${LaunchctlLabelRegex}" 2>&1 > /dev/null; then sudo -u "${USER}" "${LaunchctlExecutable}" remove "${LaunchctlLabel}" fi postflight: if [ -r "${LaunchctlPath}" ]; then sudo -u "${USER}" "${LaunchctlExecutable}" load -S "${LaunchctlSession}" "${LaunchctlPath}" fi Has anyone had any luck setting KeepAlive to true in their job description and then using a kqueue in their agent to monitor either its Info.plist or the executable itself and then quit and let launchctl restart it when it detects a version change or unlink of said files? It seems like this would also address the multi-user case which, while rare, still needs to be solved and is NOT addressed with the {pre,post}flight approach. I realize, of course, that I can set the restart flag in the package; however, from a user experience perspective that's less than ideal and is not entirely compatible with Sparkle (as near as I can tell). Regards, Grant

1 0

Re: [launchd-dev] Release build (solved)
by Karl Moskowski 29 Aug '09

29 Aug '09

On 28-Aug-09, at 6:24 PM, Steve Gehrman wrote: > Looks like COPY_PHASE_STRIP was the problem. > > Is this flag needed? It's been in my config file for years. I had a similar problem a few months back, where codesign for an embedded tool didn't work in the Release config. I filed a Radar, and Apple engineering's reply was to change the following build settings in the Release config: - uncheck the "Strip Debug Symbols During Copy" for the Release configuration (to prevent changing the binary after it has been code signed); - make sure the "Strip Linked Product" and "Deployment Postprocessing" is checked for the Release configuration. ---- Karl Moskowski <kolpanic(a)voodooergonomics.com> Voodoo Ergonomics Inc. <http://voodooergonomics.com/>

1 0

Release build (solved)
by Steve Gehrman 28 Aug '09

28 Aug '09

Looks like COPY_PHASE_STRIP was the problem. Is this flag needed? It's been in my config file for years. -steve

1 0

Release vs. Debug builds and launchd codesigning
by Steve Gehrman 28 Aug '09

28 Aug '09

I'm using a simple self sign cert to sign my app. It works great when building for Debug. When I build for release I get this: error from SMJobBless: 8/27/09 Aug 27, 10:50:09 PM Path Finder[65031] Error! Error Domain=kSMErrorDomainFramework Code=3 UserInfo=0xeb5d80 "The operation couldn’t be completed. (kSMErrorDomainFramework error 3 - The client and tool did not match requirements.)" I've check my settings and I don't see anything different with Debug and Release, so I don't think it's that. Anyone seen this? -steve

2 2