Re: StartupItems
Re: StartupItems
- Subject: Re: StartupItems
- From: Kevin Van Vechten <email@hidden>
- Date: Mon, 22 May 2006 13:09:56 -0700
On May 22, 2006, at 11:19 AM, Peter Seebach wrote:
What's the launchd way for my existing program which runs on 30
other UNIX
platforms to request that it be launched only when a configuration
file it
needs is accessible? On other systems, I'd put it in startup after
all the
disk-mounting. What do I do in the launchd model? My program
doesn't have
any hooks for querying disk availability, *BECAUSE THAT IS THE JOB
OF THE
STARTUP SYSTEM*. Or at least, always has been.
Historically it might have been safe to assume disk availability
after "startup," but the whole point is that such assumptions are
fragile at best, and therefore shouldn't be made. Disks (especially
FireWire and USB) can come and go long after "startup," so it really
isn't "the job of the startup system" to ensure that they're there.
It's the job of the process.
The complications of dependency checking have not been removed;
they've been
moved from specifications in the plist file (or rc file, or
whatever) into
extra code in my application.
Correct. The StartupItem dependencies were not a panacea. In fact,
a lot of third party applications had trouble with the dependency
model as technologies moved from one startup item to the next (even
before the shift to launchd). Maintaining dependency information in
an abstract parallel universe is always prone to mistakes. The
advantage of processes implicitly declaring dependencies (via
blocking IPC etc.) or explicitly declaring them (via callbacks for
system state changes) is inherently more robust.
What's the launchd way for my existing program, which scans for
running
network interfaces and binds to them, to ensure that it's run only
after the
network is up? I don't care about laptop issues, I'm writing a
server app.
I don't want to have to add special code to my app to scan
repeatedly because
ONE SYSTEM won't let me just schedule my item "after the network is
up".
Actually you should have always tested for this in your code.
configd is responsible for bringing up the network interfaces.
Originally launched by a startup item, it was subsequently moved to a
mach_init plist in Jaguar. The point is that there was never an
explicit dependency here. If you want to replicate the historic
behavior, then put a sleep(60) in your main() function and hope for
the best, because this is essentially all that was ever happening
anyway.
Interfaces can come and go dynamically even on Mac OS X Server, so I
don't really buy the argument that detecting this fact isn't
necessary on server systems.
Launchd has a lot to offer, especially for server processes, like
process keep-alive.
And the "new requirements" that lauchd "imposes" on your processes
generally have been there all along, and it's just been a matter of
luck that things worked without taking the time to address these issues.
- Kevin
_______________________________________________
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