December 2010 - launchd-dev - lists.macosforge.org

Re: [launchd-dev] launchd-dev Digest, Vol 42, Issue 4
by Nehemiah Dacres 28 Dec '10

28 Dec '10

I'm not sure about practice but I wouldn't put the daemon there, I would put it in one of the bin directories like /local/bin or something. Thats a fine place for a kernel extension (/Library/extension) thats where Virtual Box keeps them. I believe Launchd uses the StartInterval directive for this (search for StartInterval in the launchd.plist man page )

1 0

Periodic action performed by a daemon, Where to store daemon?
by eveningnick eveningnick 27 Dec '10

27 Dec '10

Hello I have written an NKE (Network filter kext). According to the ideas of OS X, if i want to have it started everytime the system starts, i need an autostarted daemon, which will load kext every systemboot. I am planning to let the user install (daemon and NKE) using supplied PKG, which provides uninstalling script as well. What is the best place to put the NKE and Daemon in? Is /Library/Extensions/ appropriate path for this? And i have an another question. If i want my daemon to talk to a kext every 10 seconds, what kind of timer and blocking primitives (like events in Windows) could i use? I was thinking that creating a process (which "talks" to kext milliseconds and the shuts down) every 10 seconds is not such a good idea. What is a good practice here? Thanks!

1 0

Problems with SMJobBless
by Per Ejeklint 07 Dec '10

07 Dec '10

I can't figure out what's going wrong. When I try to upgrade an installed tool SMJobBless fails at first run. System log says: Dec 6 18:17:37 iMac-Quattro /usr/libexec/launchdadd[2968]: FAILURE: Failed to check validity of client's code, error reported was The operation couldn’t be completed. (OSStatus error -67063.). And from SMJobBless() I get this message: kSMErrorDomainFramework error 4098 Then I just try once again and it works fine. The only difference being that the installed tool (a launch daemon) is not running at second attempt. During first attempt it is running but SMJobRemove successfully terminates it. Everything worked fine last week but not after migrating to a new machine. Any ideas? /Per

1 0

libdispatch threads, blocked SIGINT and child process
by Thomas Clement 03 Dec '10

03 Dec '10

Hello, I have encountered a strange behavior when using libdispatch (OS X 10.6.5). I'm not sure if there is a bug in libdispatch or else what the correct fix is for me. I found myself in the situation of doing a fork/exec/waitpid from a libdispatch thread, the child process waiting for user input, then doing ctrl-c in my Terminal window. I would expect the child process to also be terminated, however the child process is still running, consuming lots of cpu (and its ppid is now 1 which is weird). I have noticed that libdispatch calls pthread_sigmask() when creating new threads blocking many signals. I have found that calling pthread_sigmask() in my dispatch_asynced code to unblock the SIGINT signal fixes the issue (the child process is also terminated when doing a ctrl-c in my Terminal window). You can reproduce the issue using the attached sample code (which uses launchctl as the child process but it could be anything else). You can run the process from the Terminal window (./sigdispatch_br) then doing ctrl-c and watching the child process from a "top". So, what do you guys think? Thanks, Thomas

2 4