Re: StartupItems
Re: StartupItems
- Subject: Re: StartupItems
- From: email@hidden (Peter Seebach)
- Date: Mon, 22 May 2006 15:25:42 -0500
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.
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. :)
>Actually you should have always tested for this in your code.
Should I?
Since when? Since 1980? Since 1990?
>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.
-s
_______________________________________________
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