• 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: StartupItems
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: StartupItems


  • Subject: Re: StartupItems
  • From: John Fieber <email@hidden>
  • Date: Sun, 4 Jun 2006 20:44:30 -0700

On Jun 4, 2006, at 12:22 PM, Peter Seebach wrote:

Jun 4 12:06:18 localhost launchd: localhost.script_name: getpwnam ("kodak") failed
Jun 4 12:06:18 localhost launchd: localhost.script_name: exited with exit code: 1
Jun 4 12:06:18 localhost launchd: localhost.script_name: 9 more failures without living at least 60 seconds will cause job removal


Does the user exist? Why, yes. This is not only a user on the system, but
the user that gets automatically logged in once the system is booted.


So what happens? Launchd tries to launch this before the netinfo stuff is all
up, and ends up yanking it from the job list, not because the script or daemon
is problematic... But because the UserName key isn't viable yet.

Dependencies on directory services are problematic for all the launching methods in OSX because directory services being launched and "available" does not mean the configured data sources are available. Launchd may be failing particularly badly here, but StartupItems can too.


This personally bit me with LDAP defined automounts. I eventually wrote a directory services blocker which would stall the automount daemon launch until all the sources defined in directory search were online. (Automount is *supposed* to notice when the network configuration changes, but that proved unreliable.)

But is blocking until all directory service search paths are available actually the correct thing to do? Hard to say. What if one of the paths is mirror of another and it being online is purely optional and possibly not even common? What if a dependent service needs information from one path, but doesn't care about another, should it be blocked until both are available? Should the dependent dig deeper into the directory service configuration to determine which search paths have the information needed mapped?

So whatever your startup method of choice is, directory services needs some finer resolution dependency targets to work well.

-john

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Re: Fwd: StartupItems (From: email@hidden (Peter Seebach))

  • Prev by Date: Re: StartupItems
  • Next by Date: Re: What exactly does DKIOCCDREAD return for kCDSectorAreaSubChannelQ?
  • Previous by thread: Re: Fwd: StartupItems
  • Next by thread: launchd's job jettison logic (Was: Re: StartupItems)
  • Index(es):
    • Date
    • Thread