Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: open fails in daemon

On Tuesday, July 22, 2003, at 1:58 PM, Steve Cox wrote:
email@hidden writes:
Well, daemon() does a fork() for you. So, it still could be a
fork()-related issue. Does your code not call daemon() when launched
as a startupitem?
Yes, it does. But from what you've said, at that point, it's called
within the startup context.

But the bad effects of daemon() exist regardless of which context you are in. Since there are less services for your frameworks to "initialize connections to" during their init routines in the startup item context, the potential [bad] effects can be somewhat reduced. But they are still there. You may think you are getting away with it, but it will eventually bite you in the end (probably not until your app is installed on some machine and they update their pre-binding and change the order of some initialization or something - but it will get you).

The rule Chris and I both cited still stands. If using frameworks above basic BSD frameworks, you cannot safely proceed after a fork() without an exec().

Just in case you can see anything obvious, my daemon looks like this:
Mach-O 'tool' created in Project Builder
linked to CoreFoundation and SystemConfiguration frameworks
calls daemon(0,0) on startup
creates a CFRunLoopSource and registers for console user notifications
via the SCDynamicStore
on login (console user change), attempts to run a Mach-O binary. I've
tried the following, all fail equally well :-)
- Launch Services (LPOpenFSRef)
- LaunchApplication
- system("open <path>")
- execl("<path>")

Have you tried the combination of "re-exec() one's self immediately after daemon()" and sticking to "execlp("<path>")? Those are your best bets.

I don't think there is anything about requesting a SCDynamicStore notification that goes invalid after logout of the session under which the daemon was started - but there might be. Lots of higher-level things go invalid at that point (although SCDynamicStore is fairly low level).

In particular, your daemon can't register any new Mach ports in the per-login-namespace once logout is initiated, because that particular node in the namespace is shut down for new registrations. In fact, everything you previously registered in the namespace is also tossed out of it at that point. That means no new CFMessagePort connections can be established to your daemon at that point (since those are to ports registered in the per-login bootstrap namespace) - and lots of other things like that. Connections already established to other startup items, etc... are fine. Looking up ports advertised by startup items are also fine at that point. You just can't register anything any more.

Interestingly, your daemon's connection to CoreProcessServices (CPS - the thing that backs "open") is explicitly broken when the next login occurs. That's why I suggested using execlp("<path>") instead.

--Jim
_______________________________________________
darwin-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/darwin-development
Do not post admin requests to the list. They will be ignored.
References: 
 >Re: open fails in daemon (From: Jim Magee <email@hidden>)
 >Re: open fails in daemon (From: "Steve Cox" <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.