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

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.

>Also, make sure you always compare pre-bound vs.
>pre-bound. Often, it's just the difference between pre-bound and not
>that can trigger these fork() issues (init routines are all called up
>front in pre-bound applications and on first use of a framework
>otherwise).
I'm not familiar with any of these issues, but I can look into it.
>
>I believe you can always just exec() the executable inside the bundle
>(if it's Mach-O) instead of using open() on the bundle itself.
Ok. I tried this out, and it works -- in general. But it still fails
after a login from a daemon that has been launched in a login context.

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>")
_______________________________________________
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>)



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.