Slashdot Mirror
Does launchd Beat cron?
Blamemyparents writes "For those who aren't Appleheads, you may not have heard that with Tiger, Apple swapped out old Unix standby cron for their own creation, launchd (Apple mentions it on their OS X page and has the man page for it up as well). Seems like it's a bit nerdy, but this changes a LOT about how *nix systems have done things for many years. Launchd is Apple's replacement for quite a few utilities, including launching and quitting quite a few different things, and getting info from the system and other running processes. This page from Ars Technica talks a bit more in depth about it. Apple has open sourced the thing, and is apparently hoping all the unix kids will take a look."
yea, it really seems to clean up a lot of things. Like being able to tell that the service or process shutdown, instead of just sending bigger and badder kill messages.
Looks like a nice clean API that has some nice message passing structure in it. I also kind of like the magic dealing with auto-resolving dependencies and starting programs in parallel if possible.
From the sound of it, it just seems cleaner in the back-end. Much less knowing specific Unix tricks or gotchas, and more of it just working and giving you the proper interfaces.
Isn't half the attraction to OS X for geeks how its not that much different from Linux or BSD from the console? And that many/most Linux/BSD scripts and apps would work with just a few, if any changes? I don't see how making it more different really helps it. Not trying to be a troll, but I got to assume if all or most the other Unixes work with what launchd replaced just fine, that OS X could as well.
Every time you post an article on Slashdot, I kill a server. Think of the servers!
- really wasteful
- it takes a long time to parse
- inconsistent (like, the sometimes-freeform-sometimes-not issue)
- quite human-unreadable
Sure, it's better thanThe creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Nice to see Apple take a page out of Sun's book...
And that is exactly what Apple was missing in OS X. Old versions of Mac OS always booted pretty quickly, and their customers are used to that. I once had that discussion with a Windows user who complained Linux took so long to boot; the average user does not like to leave their computer on, for whatever reason.
Besides, what I'd be interested in is how this compares to Sun's SMF (System Managament Facility), which is also supposed to be a replacement for the SysV init system.
/usr/share/morlock
Then why not YAML? YAML is as flexible as XML and has the benefit of not being a hugely wasteful format, spacewise. YAML is sort of a text representation of the [String, Hash, Array] layout that Perl and Ruby use. It would work very, very well for a config file.
I don't know this, but launchd (hopefully) does proper dependency-based concurrency, something that rc.d has lacked for a while. rc.d launches everything in order. What you really need is a dependency graph and then to traverse down it. Init will start first, then anything that directly depends on init. Once a process' dependencies are met, it starts. This is not a hard calculation (though I forget exactly which graph algorithm you use) and could vastly improve startup time. If they're experiencing vastly improved startup times, perhaps this is why?
Why the hell is the user forced to wait through the RAM test? All that has to be tested is the portion needed for booting, and the rest can proceed in the background, with RAM becoming incrementally available to the system as it finishes testing.
This takes a significant portion of the boot time, and is nothing but piss-poor lazy design. If you add all the minutes wasted over all the people who use the OS over its life, that's a hell of a lot of man-hours.
XML is total crap for config files. At least its complexity is somewhat warranted when dealing with document-type data (like HTML or DocBook).
The problem is that XML's data model is fundamentally broken. Most programming language data structures use records, variants, and lists to organize data and this has worked well for years. XML gives you attributes (which cannot contain nested elements), and sub-elements that are matched accoriding to a regular expression. Stupid, stupid, stupid.
Upgrading to Tiger moved my cron jobs over to launchd. No problem, but now the scheduled jobs seems to run an hour later than they should. Something scheduled for 3:15 runs at 4:15, for example. Not a huge issue, but my Mac is set to wake up at night to run these jobs - doesn't work so well if they don't fire at the right time.
Has anyone else seen this? Any ideas?
I can think of many a time I was doing a little system administration while purring "Come on, baby. Give me a cron job. You know you want to..."
Regardless WHAT it's called, I can't imagine anytime you would use the term in that context. Who would try to coerce their computer into performing a preset timed event? I don't think that's really necessary, it's not going to skip it if it feels sick or anything.
Hmm. So you think that this XML-based solution is bad because XML makes everything slooow. Interesting. Especially considering the fact that launchd reduces boot time from a minute to under 15 seconds. While XML itself might make some things slower, in this case it allows for processes to be launched concurrently on startup, rather than one at a time. The overhead of parsing an XML file is minimal compared to the speed gains launchd allows.
Pack up your anti-XML trolling and bring it elsewhere. It has some good uses. I very much doubt that you'd be happier with it if they used some proprietary, non-readable format instead of XML since it would save them all of 0.025 more seconds on boot.
Lack of eloquence does not denote lack of intelligence, though they often coincide.
The main problem with that is it presumes that you have a human doing all the messing with that one file.
The SysV approach is much more friendly to programs, such as installers and uninstallers, and configuration managers, that wish to make changes, or that wish to start and stop individual daemons other than at startup or shutdown.
Basically, cron needs higher resolution, that's my only beef with it. It also seems like to do anything facny with cron you end up writing a program to do it and it's not that uncommon to do that.
The startup scripts need an all together different kind of overhaul. I've been working on Linux appliances for over 6 years now, without exception, it seems like someone ends up writing some kind of "health script" that is kicked off by cron every minute or a few or is a daemon in it's own right that watches for things to crash or not be running and then it restarts them. I've seen it in a production set-top box based on Linux where we essentially wrote our own init and had it treat some processes special and 5 different software appliances. Fact of life is software crashes from time to time. These scripts then do something else, like ping the gateway or something stupid to check if the network went down before they do what it is that they do. To make matters worse, they are always written in Perl by some guy who doesn't know Bourne shell to write a good startup script in the first place; that's the part that chaps me. Rather than contaminate the system with all this extra shit we should just have an easily extensible and configurable system process starter and monitor and it shouldn't require scripting to do anything advanced.
There are probably some things I forgot, it's really not that much, I could see bangin' this out in Python or java in not that much code. My thinking is that instead of checking for a PID file or grepping through ps outout to provide "status" you query a running process and it tells you your proc is up and running. Yeah yeah, I know, shit shouldn't crash and whatever. I've just seen such a shitty job of this stuff being done over and over and even on fairly stock installs of major linux distributions I've seen service
Apple has open sourced the thing, and is apparently hoping all the unix kids will take a look.
I've been poking around at Apple's Open Source page and fail to see launchd, SystemStartup, or anything else thereabouts. Does anybody have a URL for this, or know of the specifics of getting the source? It looks like promising technology, and I'd love to get my hands on a copy to play with. I would also hate to think that we're being strung along with promises of an Open system that turns out to be only partially open (like the recent KHTML/Safari issue).
It's pretty apparent that the guy is a fucking troll, but all of the Apple fanbois who want to believe in this bilge-spewing liar will mod you into oblivion for suggesting such a thing.
Mods: How the hell is pointing out the obvious -Flamebait?
The "get toasted" expression wasn't my choice of words. I was quoting. I would have said, instead, "what happens if, say, you fat-finger inittab while editing it."
The problem with traditional Unix configuration files is that they're not self-validating. A single typographical error can very easily result in an unbootable system. XML-based property lists reduce that possibility. They don't eliminate it entirely, of course; nothing could. But they reduce it.
They also open up the door for us to make the launch system self-repairing. Check out the changes to NSUserDefaults in Tiger to see what I mean there.
Just to blow my own horn here, SYSVINIT for VM/ESA and z/VM--which is an Open Source product--does in fact do the parallel start and real dependency tracking part of this.
We created it as--as the name should tell you--something like System V Init for z/VM. The traditional method of starting service machines under VM is to put a bunch of AUTOLOG statements in the PROFILE EXEC of the AUTOLOG1 user. This is, yes, even cruder than System V.
The motivation was basically to give a more flexible and familiar startup system to people running multiple Linux images under z/VM, who understand Linux but don't want to deal with CMS and would rather just approach z/VM purely as a hypervisor.
SYSVINIT uses runlevels, which are like System V runlevels except arbitrarily named, and which define a list of services that should start in each runlevel. Each service can in turn list other services that must be running before it can start, and other services that should have been shut down before it can exit.
The system builds a dependency graph from this information, and starts whatever it can in parallel. Basically, I grew annoyed at the inability of System V Init to do real contingent startup processing, and so I fixed that part of it.
It also provides well-defined APIs so that the services you write can respond appropriately and do graceful shutdowns or configuration reloads. Failing that, it is able to do the moral equivalent of TERM; wait some (user configurable) number of seconds; KILL.
I like to think it's pretty slick, but then I wrote it. The underlying operating system is most definitely non-free, but this tool is free (speech and beer; it's released under the Artistic License).
Go to http://sinenomine.net/vm/s5i and get it if you're interested. You have to register with the site to get to the download section, but registration's free.
A future development--not there yet--is the ability to submit commands from an external (non-VM) machine. This is going to involve NJE-over-TCP, and should let you control your VM services from any old TCP-networked workstation, assuming you're running RSCS on the VM box and have defined a link to the workstation. This ought to make life *really* easy for people wanting to control Virtual Penguin Farms from their desktops, without requiring them to be good at VM system administration.
No, it's not as slick as launchd, but it does at least provide real dependency tracking and contingent service startup.
Adam
The reason systems DON'T boot when /etc/intttab get's toasted is they SHOULDN'T boot with out the service it kicks off running.
;-)
That's a pretty radical retrograde interpretation of the facts. The reason system don't boot when inittab has an error in it is because init lacks any mechanism for recovering from config-file errors. We fixed that.
When inittab is toasted on one of my AIX servers, I simply boot off of the install CD or a backup tape(yes I can do that). I mount rootvg in maintenance mode, FIX inittab and then reboot. That simple.
So what you're saying here is that you don't like Apple because we're making your job obsolete?
In all fairness, it sounds like you're the one who's ignoring the elephant in the room. If it's taking five minutes for your laptop to pass POST, you need to take it in for repair. It's obviously got a hardware problem.
The self validation looks ok for a side effect of XML, nothing more.
:)
Boot time would be a big plus, but my TiBook G4 1Ghz/1GB still takes about 25 sec out of my life between gray screen and login prompt
The Property List Editor - you guys should be ashamed of this product, according to About window it wasn't touched since 2002, it's primitive, inconvenient and doesn't really help at all.
On other side - I love the idea to replace whole bunch of daemons, scripts and configs with one process and single format. Even though XML is rather misanthropic format, if it's system wide this is still very big advantage. If you would just make some nice and human friendly XML editor with integrated support for all Apple's plist types, help, search and so on - this would be nice.
launchd is also capable of automatically checking for dependencies and scheduling services to startup in the correct order. It can even start services in parallel which speeds up the boot process.
Apple's plist stuff is an abuse of XML. All those keys should have been XML elements so that I can actually validate the configuration using a DTD or a schema, not just the key/value structure.
It's also maddening to use XPath on a plist. I once needed to use Apple's iTunes export format to programmatically recover from a disk failure. The plist format made it difficult to get at the information associated with each file that I was missing.
At first i thought, "cool, they replaced init and rc.d with something cleaner, yay, finally", but then i read this thread.
Those small programs are NOT doing the same thing, there is at least 3 categories and i don't like lumping them together:
I would welcome launchd as a replacement for the first, but replacing all those things, all three categories is not only has no advantages (i think only init needs fixing, cron and xinetd is good as it is) , but potentially bloats the whole thing. Let's see, if we combine the three categories, we deal with a lot of things at once: scheduling, networking, system runlevels, dependencies.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
"For example, while I'm waiting for my clock to sync with ntp (ubuntu does it on every boot) I could also be starting the webserver."
You can alter this behaviour by editing the startup scripts appropriately. Please read the manual on how to do this.
Alternatively, buy a Macintosh where your limited experience in the real world of Linux will make you some sort of God. You never know, your ego may increase to be only slightly smaller than mine.
> The only thing that is different between these systems is that each specializes in certain event types...which is thin justification for a bajillion different configuration formats, if you ask me.
For coders and system admins the issue is obviously not at what conceptual level these functions can be abstracted as similar, but their functional overlap. Offhand I see very little functional overlap between three types of programs (init, cron and inetd) beyond "they all start and stop programs." It's entirely possible that combining superficially similar functions only results is greater complexity in their implementation.
Also I think you are conflating two issues when you toss in the consolidation of program configuration. It's not obvious to me that such consolidating overlaps well with starting and stopping programs.
Maybe a better one would be, say, something corrupting the line that says some program shouldn't run as root (if such a property exists -- if not, use your imagination).
You mean the UserName key? Sure, I suppose it's possible that some mechanical process could alter the bits on the disk so that the value for the UserName key becomes "root" instead of "littlebilly." But it's not very likely, is it?
Basically the gist is, if there's an error isn't it more secure to abort entirely rather than possibly run something the wrong way?
There's a difference between refusing to fire off a given task defined by a (truncated, whatever) config file and leaving the computer in an unbootable state. If inittab were to be truncated, your computer would fail to book. With launchd, you never have to worry about that.
Okay, touché. If you use the word "daemon" to refer to any non-interactive program, the sure, init and everything else that isn't an application or a tool is a daemon.
I'm more accustomed to the definition that a daemon is a server, like ftpd or named. It's just the terminology that I learned years ago, and it's stuck with me ever since.
But if you want to throw that out, I'm cool. Yes, launchd is a daemon, in that it's not a user-interactive program.
There are much better formats then XML. For starters there is the old style plist files from next/apple. They are just as easy to parse by a machine and very easy to maintain by humans.
The fact is that for any non trivial application configuration will become so complex as to resemble a language (see exim for example). In my opinion those config files should simply be python or ruby or something.
evil is as evil does
I know the guy who does the Darwin releases.
You're not him.
I know the guy who has been working on launchd for over two years now.
You're not him.
I know the guys who work on the BSD Technology Team.
You're not any of them.
So what I want to know is, where do you get off using "we" every time you open your mouth about Apple? You didn't write it. You didn't think of it. I doubt you could do either. The credit isn't yours, and I have a feeling that Corporate Security is bearing down upon your desk in the QA department right about now.
If I were you I'd shut my trap and cover my ass.
-- AC
I will admit that I wasn't the clearest. However, if you use XML as you suggested. Then for each version of your program which adds preferences you need a new DTD in order for you to fully validate. Since a program should be able to handle all versions of its preferences. You now need to check against multiple DTDs.
If I turn off the validator... well that seems to go counter to your desire to validate against the DTD.
The application in question is lame. There is no separation of preferences storage and application specific details so it is completely aware of the program domain. Need to add a new preference? You have to add it to the raw code that reads/writes preferences (2 places in that program).
I highly suspect the program doesn't handle new versions of the program reading older preferences or the like.
I admit that if the storage was at least an isolated component, it could spit out arbitrary XML. But it would be a lot harder to find the right DTD.
Side question: Hmm, does an XML DTD itself even state what a value of a field should be, or is it always tags about strings? The property list DTD at least has a description for each value of whether it's a string, array, int, hash (dictionary), or boolean.
I decided to go with an Apple Property List in a cross-platform program, without using Apple's Preferences API, because I wanted better preferences than a memory dump. (what my program had been doing.) Because I wanted them human readable. And because I wanted room for growth without having to flex the DTD for every internal and external release of the program.
Basically, I saw what the other program was doing and desperately wanted to avoid what it had done and I was willing to make an isolated storage layer. Property lists fit what I needed out of my storage layer (application shouldn't care about how preferences are stored, preferences shouldn't care what is stored.) And as an added bonus, because of the ubiquity of property lists on MacOS X, there are already tools to work not just with XML, but explicitly with Property Lists.
I'm no XML God, but just a young programmer. And what Apple was doing with the property lists made a heck of a lot more sense than anything else I had seen. And most likely much more sense than anything I could design as well.