Re: StartupItems
Re: StartupItems
- Subject: Re: StartupItems
- From: Kevin Van Vechten <email@hidden>
- Date: Mon, 22 May 2006 13:40:43 -0700
On May 22, 2006, at 1:25 PM, Peter Seebach wrote:
In message <email@hidden>,
Kevin Van Vec
hten writes:
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.
I think it's the job of the sysadmin. Having every process
constantly check
for disk availability doesn't help all that much; it's load-
creating, and it
doesn't solve the problem.
I'm not advocating polling models, there are callback models that
suffice.
There comes a time when the UNIX philosophy should win; 10% of the
coding
does 90% of the job. Dealing with disk changes is probably a human
task.
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.
It is, but inventing yet another new way of doing it doesn't help
me much. :)
In the short term I agree with you. You have some more work to do,
but in the long term, this approach is sustainable and hopefully will
not require further churn.
Actually you should have always tested for this in your code.
Should I?
Since when? Since 1980? Since 1990?
Since Mac OS X 10.0. I can't/won't speak for earlier systems.
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.
I'm not talking about "only on a Mac".
I'm talking general UNIX. I don't have any interest in crippling
my code
to a single platform.
The historical practice has been to figure out how your system
provides
ordering, and use that to launch code at the right time. On SysV, you
link your init script to SXXdaemon, where XX is larger than the
number for
the network init script. In NetBSD/FreeBSD, you put "REQUIRE:
network" in
your rc.d script.
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.
When I say "server systems", I don't mean "systems running OS X
server". I'm
talking about general practices for people running a server. I've
yet to see
a real webserver want to use a dynamically up/down interface.
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.
No. Outside of the Mac, everyone's provided a nice luck-free way
to ensure
that items get launched at the right time. It might be as dumb as
the very
old "put it in /etc/rc after the things it depends on", but the
ordering
control has always been there.
Launchd is expecting me to modify the code of my server application
to solve
an administrative task, and to do so in a completely Mac-specific
way. No
one else has done that. I can take a daemon written in 1990 and
run it
without modifying the code on any other system, by using their
script or
config file interface for specifying what its requirements are. On
the Mac,
I'm being told it's suddenly up to me to modify my application code.
I'm not sure this is wrong; I think UNIX could benefit a lot from
additional
dependency handling in applications. However, it's a major change in
philosophy, and the short-term effect is that, if I have to support
more than
one UNIX platform, the Mac is gonna be my absolute last choice,
because it's
the one that requires me to encode system-specific configuration
knowledge
into my code, rather than having that be in the part of the system
that
handles startup. I can no longer have a single unified source tree
if I want
to target the Mac.
I'd be surprised if there is not a platform specific line of code in
your program. You can wrap your launchd support in #ifdef
__LAUNCHD__ or something equivalent. It's overstating the problem to
say that you can't have a unified code base. Adding Launchd support
is a relatively small amount of code, I know from experience. I
think your sysadmins (customers) will ultimately be pleasantly
surprised by this investment. Your server can be automatically kept
alive. This and other servers can be uniformly launched, stopped,
and queried via launchctl or programmatically.
It's clear you're dissatisfied with having to change from what you're
used to, and I appreciate that. I don't think any further amount of
discussion is going to change that. However, I think you'd be
pleasantly surprised if you gave the launchd model a chance.
I think your concerns are completely legitimate, but we're faced with
a difference in opinion as to how they're most effectively addressed
(i.e. are they a startup problem or a process problem?) I suspect
the best solution is for more documentation and sample code to be
written about launchd, to illustrate how to achieve these goals
within your process.
- 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