Re: StartupItems
Re: StartupItems
- Subject: Re: StartupItems
- From: email@hidden (Peter Seebach)
- Date: Tue, 23 May 2006 01:33:15 -0500
In message <email@hidden>, Michael Smith wr
ites:
>Wow. I can't actually say that I've seen such a collection of
>reactionary curmudgeonery in, well, a very long time.
Not a Usenet reader? :)
>Given that no other system you're going to touch with a ten-foot pole
>supports this in the first place, what do you expect? Freebies?
Well, ideally, any kind of bone at all tossed to the notion of minimally
intrusive designs; otherwise, one of the much vaunted advantages of launchd
("it's less work!!") goes away.
>As has been pointed out, on Mac OS and many other systems, disks come
>and go. If you are going to handle this at all, then you might as
>well accept that any volume other than the one you were loaded from
>may come and go at any time, in which case startup is just a special
>case.
>It's been a long time since the RA-81. You can actually pick a disk
>up and put it in your pocket, and this has changed the way people use
>them. You can't pretend that adding a new disk to the system must
>necessitate an electrician and a forklift anymore.
But I can observe that, in practice, servers don't change system-level volumes
that services depend on, unless they're doing real maintenance during which
the service *can't run anyway*.
>> 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.
>Like, say, launchd? I think you've swapped ends here...
Exactly.
**I WANT LAUNCHD TO DO THIS CHECKING, RATHER THAN EVERY SEPARATE PROGRAM**.
Right now, launchd *requires* that every program it's going to run do its
own dependency checking.
That's WORSE than what I had before.
>Mac OS X has the largest installed base of any Unix-like operating
>system. Period.
Yes. Almost none of which are servers.
>It's the only Unix-like operating system that takes the desktop
>environment seriously. Period.
Which doesn't have much effect on services.
>It's the only Unix-like operating system that is attempting to adapt
>the way that the system thinks about people, rather than the other
>way around. Period.
Er, no.
Launchd is, right or wrong, an absolutely crystal clear example of a system
declaring "no matter what is convenient for you, THIS IS WHAT YOU MUST DO."
You are not allowed to have the system do the dependency work for you.
>And thus you get portable, standard, lowest-common-denominator
>behaviour.
Yup. And since that happens to, today, be BETTER for starting many
services than what launchd offers, with LESS EFFORT, that seems like a likely
continued state.
Launchd, if it's going to see real success outside of the enforced conformance
of the Mac, is going to have to offer some kind of solution to the very real
problem of dependency management.
Having the solution be "every one of the hundreds if not thousands of jobs
and daemons that will ever be written must have entire modules to handle
dependency checking because we don't want to" is not a solution to the
problem; it's a bald assertion that there never was any problem.
>As has already been pointed out, if you want to act like a piece of
>code from the 1970s, that facility is available. There are good
>reasons not to, some of which are consequent on the points I just
>made above.
But that facility is going away.
>> wrong. Dependency checking is not something that should be
>> duplicated in every program.
>I don't see your point; this is exactly what Dave & co. are asserting
>with the launchd service dependency design.
Huh?
>As a service provider, you advertise your services passively.
>As a service consumer, you attempt to consume said services.
>The latter results in the invocation of the former.
>Where is there any sort of "dependency checking" in the consumer, or
>for that matter in the provider?
In the attempt to consume said services.
Once again, the two most common cases I can think of are sockets and
filesystem access. Neither offers a way to indicate "this service isn't
available now but will be soon, please try again in a bit".
>Launchd will happily spoof local sockets, so I don't see a
>counterexample there.
Okay. So, when I try to talk to my socket-based service, how do I know
whether it's permanently unavailable or just a bit slow?
>As previously noted, if by "file access" you mean "the presence of a
>magic file" then it's down to the vector that presents the file. If
>you're expecting it to arrive via filesystem mount, then
>DiskArbitration does everything you want and a great deal more.
Uhm.
So, instead of starting my program after filesystem mounts, I'm supposed to
write a chunk of brand new system-specific code that queries a brand new
service to see whether a disk is available?
I thought launchd was abstracting away service dependencies. This is a
dependency I apparently have to manually encode and check myself, now?
>If you are talking about a passive or implicit rendezvous (e.g.
>waiting for a PID file before attempting to contact a local service
>by some other means), then you are typically looking at an
>arrangement that tries to avoid a problem that the launchd model has
>made obsolete. You can remove code in this case... should make you
>happier again. 8)
Well, the obvious examples are things like configuration files.
>> Which are, by strange coincidence, 99% of UNIX services.
>But by no means 99% of the services available on a Mac OS X system.
True.
In part, because Mac OS X, even Server, really isn't going after the
traditional server market right now.
In part because, without dependancy checking, it's cheaper to buy a UNIX
box than to figure out how to get a service running under launchd.
>My opening point about reactionary behaviour and obstinacy bears some
>restatement. As Dave and Kevin and others have pointed out here, the
>launchd architecture is trying to solve some fundamental, undeniable
>problems with the way that services are invoked and managed.
Yes.
And I think the problem is that it's done an absolutely BRILLIANT job of
replacing cron and inetd.
I just don't think the system startup tasks are the same category of tasks.
Launchd's handling of on-demand service is absolutely delightful. I would
like to see launchd added to other systems to replace inetd (bleh), xinetd
(pfui!), cron (meh), and the dozens of system-specific one-off "relaunch
this when it fails" scripts that every large system develops.
But I don't think it can, or should, replace system startup. These are
fundamentally different types of tasks, and I think the attempt to coerce
that square peg into launchd's brilliantly perfectly round hole is not
working.
>Change is pain, and you really have just two choices; impede the
>process and contribute nothing, or align yourself with it and help
>these folks improve the world a little.
I've suggested the obvious improvement: Stop trying to crowbar system
startup into launchd. Use it for on-demand services and other things that
can be started "once the system is up". It is without doubt the best
implementation I've ever seen of either inetd or cron functionality, and I'd
happily take launchd over both of those any day of the week.
But no matter how absolutely beautiful this knife is, it's not a spoon.
-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