• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: DO and StartupItems
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DO and StartupItems


  • Subject: Re: DO and StartupItems
  • From: Ryan McGann <email@hidden>
  • Date: Tue, 24 Sep 2002 00:48:58 -0700

On Tuesday, September 24, 2002, at 12:20 AM, Terence Goggin wrote:

Hi Ryan,

Now, I know that makes little sense because when I run them as sudo from the terminal, they work just fine and there really should be no major differences between that and the startup items loading. (Even stranger when you consider that the daemons are able to find each other just fine.)
This sounds like the bootstrap namespace issue that plagues many developers. Some background:

All interprocess communication uses Mach ports under the hood, including Distributed Objects. The bootstrap server is where the kernel (and the mach_init daemon) find which ports belong to which application.

The Mach bootstrap server in Darwin creates two namespaces. The first namespace is created during system startup. This is the "root" namespace session.
Processes that are created when there's a console user (somebody's logged in) register their Mach ports with a bootstrap server that's in an outer wrapper around that root session. Lookups in the login session can see both login session services and the root services, but lookups in the root session can see only other root session services.

This was done as a security risk management. The loginwindow denies Mach port connections to the window server so that you can't create a login window that looks like Apple's but instead steals people's passwords. Similarly, when you log out, the per-login namespace is torn down since it contains port registrations that you don't want to be searchable from a different user.

But it makes it harder for two processes launched in different namespaces to communicate with each other. This plagues all IPC...Apple Events, Mach ports, shared NSPasteboard's...But anyway, this is why it works from the command line. Your daemon is already inside the "per-use" namespace, which means your application can "see" the ports created by your daemon. When the daemon is started up as a startup item, its ports are registered in the root namespace, and the root namespace can't see the ports used by your application.

So... yeah, if you have some sample code, I'd love to see it.

On my iDisk's public folder (http://idisk.mac.com/rmcgann220/Public) there's a DistributedObjectsTest. Install the startup item (it may need to be chmod/chown'd under Jaguar) and reboot. You should have a new daemon process running, DOStartupItem. Then open the project in ProjectBuilder, debug the application. On my computer, it successfully calls the DOStartupItem.
This project basically has a process instead of a startup script. Th process calls daemon() and fork().

Is there anything I should be doing in the installer or the startup script that could influence this?

Call daemon() and fork() as I outlined.

Ryan

-----------------------------------
Ryan McGann
Software Engineer
Internet Security Division
Symantec Corporation
email@hidden
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: DO and StartupItems
      • From: Stéphane Sudre <email@hidden>
  • Prev by Date: Re: cocoa-dev digest, Vol 2 #1291 - 12 msgs
  • Next by Date: Re: needed Time for a method
  • Previous by thread: Re: DO and StartupItems
  • Next by thread: Re: DO and StartupItems
  • Index(es):
    • Date
    • Thread