Re: StartupItems
Re: StartupItems
- Subject: Re: StartupItems
- From: email@hidden (Peter Seebach)
- Date: Mon, 22 May 2006 15:52:24 -0500
In message <email@hidden>, Kevin Van Vec
hten writes:
>I'm not advocating polling models, there are callback models that
>suffice.
Fair enough, but even MORE system-specific.
>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.
It may or may not. I just don't find myself convinced that every daemon
in the world should acquire all this extra sanity-checking. I like to
isolate repetitive tasks; I would rather see ONE program to dependency
checking than DOZENS.
>> Since when? Since 1980? Since 1990?
>Since Mac OS X 10.0. I can't/won't speak for earlier systems.
Imagine that I'm a UNIX guy with a half-dozen machines already running.
Why should I care about OS X? It's imposing a totally new model on my code
that contradicts how my code has worked fine on every other system for twenty
years.
>I'd be surprised if there is not a platform specific line of code in
>your program.
There may be some, but there's damn little. I write portable, standard, code.
>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.
Hmm.
Tell you what: When there's a published standard that is not Apple-specific,
and a second independent implementation I can compare with, I'll think about
it.
Right now, I have Apple totally overhauling the way daemons are started.
I have no reason to believe that this one will survive.
>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 it has some potential.
But ultimately, the more I think about it, the more I think it's just plain
wrong. Dependency checking is not something that should be duplicated in
every program.
>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.
Yes.
Well, as a recent example, I have an existing fire-and-forget program. I
don't want to modify it. How should I do a launchd.plist file to start it?
The obvious idea is to use RunAtLoad.
If you do this, launchd hangs forever. Why? Because despite every last
piece of documentation saying that you must NEVER fork and detach, and you
MUST NOT close file descriptors, if you don't fork-and-detach and close
file descriptors in a RunAtLoad process, launchd waits for it to terminate
before doing anything else.
I could, I suppose, rewrite my program to add launchd checking and so on
to what is essentially a ten line shell script with a while loop. I'm not
sure how I'd go about doing this, because my kornshell documentation makes
no mention of a fully functional IPC system.
My objection here is not to the basic idea of the launchd model for many
things; I think it is hands down the best way I've seen to handle inetd/cron
jobs or their equivalents. I just think it's doing an awful job of replacing
rc.d/startupitems. It's good for on-demand launches; it's not doing nearly
as good a job of startup.
Philosophically, it's right about inetd/cron. It eliminates the need for
daemons to do their own setup work and have everyone duplicate the various
attempts to drop privileges as soon as possible but not to soon, and so on.
It REDUCES code duplication.
Philosophically, it's wrong about startup. It CREATES the need for daemons
to do their own dependency checking, and requires everyone to duplicate
all the code to handle this, add new mechanisms, and so on. It INCREASES
code duplication.
-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