Forgot your password?
typodupeerror
Utilities (Apple) Businesses OS X Operating Systems Software Unix Apple

Does launchd Beat cron? 798

Posted by timothy
from the borrowable dept.
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."
This discussion has been archived. No new comments can be posted.

Does launchd Beat cron?

Comments Filter:
  • Re:my observation... (Score:5, Interesting)

    by kaiser423 (828989) on Sunday May 01, 2005 @03:30PM (#12399981)
    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.
  • Less Compatible? (Score:3, Interesting)

    by imemyself (757318) on Sunday May 01, 2005 @03:32PM (#12400009)
    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.
  • Re:Ahh yes. (Score:3, Interesting)

    by KiloByte (825081) on Sunday May 01, 2005 @03:36PM (#12400035)
    In my opinion, XML is:
    • really wasteful
    • it takes a long time to parse
    • inconsistent (like, the sometimes-freeform-sometimes-not issue)
    • quite human-unreadable
    Sure, it's better than .ini, but is it the best thing since sliced campers? No way.
  • Just like SMF (Score:2, Interesting)

    by timf (21111) on Sunday May 01, 2005 @03:43PM (#12400096) Homepage
    Nice to see Apple take a page out of Sun's book [sun.com]...
  • by sjlumme (719239) on Sunday May 01, 2005 @03:56PM (#12400205) Homepage
    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.
  • Re:Ahh yes. (Score:1, Interesting)

    by Anonymous Coward on Sunday May 01, 2005 @04:02PM (#12400243)
    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.
  • by zorander (85178) on Sunday May 01, 2005 @04:09PM (#12400287) Homepage Journal
    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?
  • by Anonymous Coward on Sunday May 01, 2005 @04:10PM (#12400310)
    It takes longer to test 8 GB of RAM than 512 MB of RAM.

    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.

  • by cakoose (460295) on Sunday May 01, 2005 @04:57PM (#12400716) Homepage

    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.

  • by wilkens (27751) on Sunday May 01, 2005 @05:02PM (#12400756)
    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?
  • by Aeiri (713218) on Sunday May 01, 2005 @05:12PM (#12400846)
    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.
  • Re:Re-post (Score:3, Interesting)

    by sean23007 (143364) on Sunday May 01, 2005 @05:15PM (#12400867) Homepage Journal
    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.
  • by harlows_monkeys (106428) on Sunday May 01, 2005 @05:16PM (#12400877) Homepage
    A few years later, in 1999 or so, I tried FreeBSD for the first time. (Here it comes, I'm gonna be modded troll for starting another BSD- vs. SYSV-style init script war...) There, the functionality is still implemented in scripts, but there was a much more sane system. There is one script that is the same across all FreeBSD installs of that version. Then, there's the script you get to customize if you want. There's one more file, and that's where you simply give yes or no answers, or provide other data, in the form of environment variables that influence the running of those two scripts. It's so simple, and works quite quickly. Also, since you really only mess with one file, and two if you modify the script, it's much easier to find where things are. It's more efficient, from many standpoints.

    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.

  • by Nelson (1275) on Sunday May 01, 2005 @05:18PM (#12400889)
    Cron and init and rc.X work fine, I'm not a hater. However I do think it's time to move forward. I like what Sun is doing with SMF and this is Apple's cut at it.

    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.

    • Use XML for configuration, it's easy to parse, it's here to stay and I think it's a little bit better than the columns of a crontab because it's more verbose.
    • Have variable restart behavior, restart, restart and restart dependancies, reboot, just let processes die, etc..
    • Have dependancies (start the database before the shit that inserts data in to it, even though it shouldn't matter, it does) and start them in the right order.
    • Kill dependencies when I kill a process
    • Smart killing, if something doesn't gracefully go down, 9 it down.
    • Have some kind of health monitoring call back, at a time I specify, execute a program that will check to see if a process is okay.
    • Once all this is done, maybe support something like soft cycling, kill everything down to single user mode and then bring it all back.
    • Variable dependency notification, if I restart my database allow me to do nothing to dependant processes, restart them, or HUP them, or something I define.
    • Full featured logging.
    • At some configurable interval, sniff out all of the XML configs in this "next gen startup proc" config directory, like every 5 minutes just check for changes and if needed, start something new up.
    • Allow for user to be specified in the config
    • Allow for end users to have thier own daemons defined by files in their home directories.
    • Then finally, allow for cron like behavior and run tranient tasks with all the flexibility of cron.
    • Proc specific ulimits would be nice also...
    • And some form of runlevel logic still.
    • And startup and kill in parallel if allowed by the depends...
    • And it should have a template for common daemon type things I should just provide a startup command, arguments, a user to run it as, and a run level.

    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

  • by shorti9 (307602) on Sunday May 01, 2005 @05:28PM (#12400983)
    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 [apple.com] 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).
  • by Anonymous Coward on Sunday May 01, 2005 @05:42PM (#12401113)
    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?
  • by As Seen On TV (857673) <asseen@gmail.com> on Sunday May 01, 2005 @05:49PM (#12401182)
    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.
  • Re:*sigh* (Score:2, Interesting)

    by adamthornton (101636) on Sunday May 01, 2005 @06:16PM (#12401464) Homepage
    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 [sinenomine.net] 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
  • by As Seen On TV (857673) <asseen@gmail.com> on Sunday May 01, 2005 @06:22PM (#12401525)
    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? ;-)
  • by As Seen On TV (857673) <asseen@gmail.com> on Sunday May 01, 2005 @06:28PM (#12401597)
    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.
  • by atverd (562994) * <atverd@gmail.com> on Sunday May 01, 2005 @06:45PM (#12401746)
    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.
  • by metoc (224422) on Sunday May 01, 2005 @06:47PM (#12401754)
    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.
  • by 6e7a (256012) <6e7an0n@g[ ]l.com ['mai' in gap]> on Sunday May 01, 2005 @07:11PM (#12401984) Journal

    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.

  • by A beautiful mind (821714) on Sunday May 01, 2005 @07:28PM (#12402167)
    And you know, this blew it.

    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:

    • init, rc.d: system startup, levels
    • inetd, xinetd: it(they) starts programs that provide Internet services, when a connection is initialized on a specific port over the network
    • atd,crond: They execute commands/scripts at a scheduled given, fixed time/interval

    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.
  • Re:No thanks. (Score:0, Interesting)

    by Anonymous Coward on Sunday May 01, 2005 @07:32PM (#12402200)
    "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.
  • by Anonymous Coward on Sunday May 01, 2005 @09:09PM (#12402933)
    > 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.
  • by As Seen On TV (857673) <asseen@gmail.com> on Sunday May 01, 2005 @10:57PM (#12403755)
    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.
  • by As Seen On TV (857673) <asseen@gmail.com> on Sunday May 01, 2005 @11:32PM (#12403956)
    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.
  • by killjoe (766577) on Monday May 02, 2005 @12:33AM (#12404276)
    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.
  • by Anonymous Coward on Monday May 02, 2005 @01:42AM (#12404576)
    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
  • by Anonymous Coward on Monday May 02, 2005 @10:42AM (#12407189)
    To me, your schema seems like an ideal location to enumerate and document your preferences. But let's say you don't give a crap about that; you want to add new preferences by updating the config-file-loading code, but the validator isn't letting your new tags through. Turn off the validator. You don't need it. Just let your config-file-loading code look directly at the XML and take the elements it wants.

    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.

    (BTW, what do you mean by "schema parsing"?)

    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.

    People (like you and the guys at Apple) are building generic layers on top of XML and building their domain-specific data types on top of that new layer. XML was supposed to be that generic layer, but you guys have implicitly decided that XML sucks too hard to serve that purpose. I totally agree.

    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.

Facts are stubborn, but statistics are more pliable.

Working...