Re: Root launched daemons and distributed objects clash?
Re: Root launched daemons and distributed objects clash?
- Subject: Re: Root launched daemons and distributed objects clash?
- From: James Bucanek <email@hidden>
- Date: Sat, 22 Jul 2006 07:27:11 -0700
Colin Cornaby wrote on Friday, July 21, 2006:
>I have a deamon being launched at startup by launchd, meaning the
>daemon is owned by the root user. My user side client attempts to
>connect to a distributed object being hosted by the server, which
>completes successfully. The client then queries the daemon for it's
>status (via the DO) and registers to receive notifications of changes
>of the status (again via the DO). The initial status request works
>great. The daemon's DO returns the daemon's current status. Things
>stop working when the damon attempts to send a message back to the
>client that the daemon's status has changed. The message just simply
>never goes through. When I run the daemon as the same user as the
>client, everything works just fine. Running the daemon as root
>prevents the daemon from sending any message back to the client to
>tell the client that the daemon's state has changed.
I wrestled with a similar problem just last month. The problem is Mach "sessions." Each user login creates their own session, and the system has its session. launchd, and anything launchd starts, runs in the system session (except for user agents), and any process you start as a user will run in your user's session. Child (user) sessions can see Mach ports created by its parent (system) session, but not the other way. Similarly, a user can't see Mach ports in another user sessions either.
What I don't understand is how you are getting the messages from the server to the client. DO connections, once established, are bidirectional and I've never had any problems sending messages both ways. So when you say "The client ... registers to receive notifications of changes of the status (again via the DO)." how are you "registering" and how are you "notifying?"
- If you are trying to create a new DO connection from the server to the client, that won't work (because of the session scope issue I mentioned).
- If you are sending a notification using NSDistributedNotificationCenter, you have a similar problem but you can get around it by including the NSNotificationPostToAllSessions option to send the notification to all other sessions. <file:///Developer/ADC Reference Library/documentation/Cocoa/Reference/Foundation/Classes/NSDistributedNotificationCenter_Class/Reference/Reference.html#//apple_ref/occ/instm/NSDistributedNotificationCenter/postNotificationName:object:userInfo:options:>
If you do this, be aware that you are now sending your notification to all processes and you should be prepared for the case where your application is running in multiple user sessions simultaneously. I solved this problem by including an "uid" property the in the notification's userInfo so I know which user the notification belongs to.
- If you are passing a delegate object from your client to your server, then having the server send messages to that (distant) object, that should work just fine. (As an aside, this is exactly how NSDistributedNotificationCenter works and how it is able to get around the "session barrier" issue.)
--
James Bucanek
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden