site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com On Oct 12, 2009, at 2:20 AM, Jean-Daniel Dupas wrote: Le 12 oct. 2009 à 01:01, Stacey Son a écrit : On Oct 11, 2009, at 3:01 PM, Dave Keck wrote: FWIW: I never saw a version of OS X that support it. This explains why these flags were deprecated. :) Best Regards, -stacey. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... As far as getting the the new child's PID, I don't think it's possible using the kevent APIs from userland. (sys/event.h mentions "lower bits contain the PID of the child", but I think this is kernel-only.) This depends on which version of Mac OS you are using... Before 10.5 I believe you could use NOTE_TRACK and NOTE_CHILD to get the PID of the child. The PID of the child would be stored in the ident field and the PID of the parent (aka. PPID) would be stored in the data field. I guess this is no longer the case. See sys/ event.h: /* * DEPRECATED!!!!!!!!! * NOTE_TRACK, NOTE_TRACKERR, and NOTE_CHILD are no longer supported as of 10.5 */ Best Regards, The last time I tried to used them is a simple application, it was triggering a Kernel Panic, until Apple fix that by returning ENOTSUP when trying to register an event with theses flags. Another way to monitor and get the PID of new processes is to use auditing. See the FreeBSD documentation for the details: http://www.freebsd.org/doc/en/books/handbook/audit.html In short, you could audit the fork() and posix_spawn() system call events. The child PIDs are given as arguments to these events. To do this you will need to add the "process" audit class ("pc") to the "flags" and "naflags" fields of /etc/security/audit_control (or better yet, create your own audit class with just these events*) and restart auditing by doing "sudo audit -s" (or rebooting). You can then read the events from either the audit trail files in /var/audit or by reading /dev/auditpipe (see "man auditpipe"). This assumes you are running 10.6. Of course, auditing system call events can add some overhead. To reduce this overhead as much as possible you may want to create a new audit class with just the system events you would like to audit. This is done by edit the /etc/security/audit_class and /etc/security/ audit_event files (see 'man audit_class' and 'man audit_event'). This email sent to site_archiver@lists.apple.com