On Nov 21, 2007, at 6:26 AM, Elango C wrote:
My objective is to identify the USB device and need to launch the USB authentication application which will open the USB drive/partition. So I am registering the USB arrival and removal in the init() See below functions.
I am the wrong person to help with such issues. I'll only note that this code is
not complete, so it does not allow me (at least) to answer the question I asked,
whether the process is forking.
[...]
The above code works fine in the Mac Tiger and it gives the problem in Mac Leopard. Please advise me to solve this issue.
Are you invoking fork at any point during the execution of your process,
and invoking CF functionality in the fork child ?
If you don't know whether your code is invoking fork, directly or indirectly, this dtrace
invocation could help resolve this question:
sudo dtrace -n 'syscall::fork:entry { printf("Executable '%s' with pid %d is forking", execname, pid); }'
Run this in one terminal window, wait for dtrace to report it matched 1 probe, then get
your code to run. The script should print lines like the following:
...
1 17594 fork:entry Executable login with pid 255 is forking
1 17594 fork:entry Executable zsh with pid 256 is forking
1 17594 fork:entry Executable sh with pid 259 is forking
...
If you see your executable in there, that's your problem. If not, I'm unlikely to help any further.
If you see your executable, printing the backtrace from dtrace should show you where
the fork() occurs.
sudo dtrace -n 'syscall::fork:entry / execname == "myexec" { ustack(); }'
Eric
Regards,
Elango C
Are you fork()'ing that process and attempting to use CF-level
functionality
in the fork child ? This is not supported, and in 10.5 some checks
have been added
to error out if CF is used in a fork child.
For daemons/agents started via launchd, forking (or using daemon())
should be unnecessary.
If there is a good reason for creating a new process, you'll have to
exec or posix_spawn()
the executable.
Eric