Apple's OS X Launchd is being ported to FreeBSD

As Phoronix news says, Apple's launchd is being ported to FreeBSD.
The project's name is openlaunchd and its main goal is to provide better boot-up times and jobs management.
You can find openlaunchd project on Github and its homepage at FreeBSD wiki.

This sounds like systemd for the BSD world, but in this case, written by Apple.
 
I find this interesting. I wonder if anything else has been ported from Darwin to FreeBSD, or where to go to find the info.
 
freesbies said:
This sounds like systemd for the BSD world, but in this case, written by Apple.
This sounds interesting. And while I would expect systemd to create a huge pile of problems when it would be "ported" (a.k.a. shoehorned) into a different system, this would very likely be a good addition to FreeBSD.

One of the big benefits for the project is said to be less downtime. Here, I would like to point out that a working suspend-to-disk along a stash of identical replacement parts can provide a NIC change with no lost connections - as long as you can work fast enough to avoid the TCP timeout.
 
Well, on OS X launchd handles literally everything related to services including the system start up, all those are now handled by shell scripts in FreeBSD. Having something similar in FreeBSD would be quite awesome to be honest. The system that is now in use in FreeBSD is good but can not handle many error conditions gracefully because of the limitations of the chosen script interpreter, /bin/sh.
 
trh411 said:
Coming from Apple I expect it will only launch applications purchased from the App store. :beergrin

Nah, I suspect that, in the spirit of the systemtap vs dtrace discussions it will be a case of:

"Like systemd, but not crap."

Have launchd on my Macs, but have never really bothered looking at it. It just works (tm).
 
Greetings from linuxland! I have been quite interested in BSD for a few years, but I was a newbie back then, and couldn't figure out the finer points of how stuff works. I may be making the jump soon. As an current arch user, however, I can comment on systemd. You might have heard it's pretty awesome, and yeah, it pretty much is. In 20 minutes, I learned how to use the mini language its configs use, and it was pretty much smooth sailing from there. You may have also heard that systemd is terrible, and yeah, that's pretty much also true. You can find the debate all over the web, so I won't post it here. If we could hack most of the systemd API into a userspace library in BSD, we could probably port dependent linux apps over. I don't know how possible that is, as I haven't actually looked at it yet, but someone, possibly me, should look into it, if it hasn't been done already. Although there may not be much demand, as GNOME proper I believe has the deps, not gtk, and gnome proper is considered a horrible piece of trash with most people. I hope launchd works out well over here, if you really want it, and not the current BSD init.
 
So rather than just use XML, it has its own configuration language?

Yay.

edit:
I don't think you'll find much support for systemd here mate :)

launchd will be a bit of a stretch., and that's not GNU.
 
throAU said:
So rather than just use XML, it has its own configuration language?

Yay.

edit:
I don't think you'll find much support for systemd here mate :)

launchd will be a bit of a stretch., and that's not GNU.

So is this thing actually replacing rc.d or do the people porting it just think it will be, just because they did?
 
I don't know of any plans for it to replace anything. The code isn't ported yet.

IF it is ported and IF it works well, then MAYBE people might consider including it.

I wouldn't hold your breath, however I suspect that if launchd is ported, it probably will end up in PC-BSD (a FreeBSD variant).
 
throAU said:
I don't know of any plans for it to replace anything. The code isn't ported yet.

IF it is ported and IF it works well, then MAYBE people might consider including it.

I wouldn't hold your breath, however I suspect that if launchd is ported, it probably will end up in PC-BSD (a FreeBSD variant).

Don't get me wrong, I'm not an advocate of an rc.d replacement, I quite like FreeBSD the way it is now. But if it was to change, I would be seeking a suitable alternative.
 
throAU said:
So rather than just use XML, it has its own configuration language?

I don't understand why you'd ever want to use XML for a configuration file. It's difficult to edit, hard on the eyes and not particularly suited for a configuration file. XML works well as a markup language, but it's been shoe-horned into places it doesn't belong (like data exchange, configuration, simple databases, etc).

Here's an example systemd configuration file (Redis):

Code:
[Unit]
Description=Advanced key-value store
After=network.target

[Service]
Type=forking
User=redis
PIDFile=/run/redis/redis.pid
ExecStartPre=/bin/mkdir -p /var/lib/redis
ExecStart=/usr/bin/redis-server /etc/redis.conf
ExecStop=/usr/bin/redis-cli shutdown
Restart=always

[Install]
WantedBy=multi-user.target

It's a pretty standard if you ask me. I honestly really like systemd's design, I just wish it were BSD-licensed and portable so I could use it here.

Then again, I also really like FreeBSD's init. It's much simpler than Linux's sysv and reminds me a lot of Arch Linux's init before they switched to systemd.
 
XML is interesting, because it's neither human-readable nor machine-readable. I don't understand why one would *ever* want to use it. The masturbating monkeys people at W3C suffer from a seemingly incurable case of cognitive dissonance on the subject.

So, ehmm, back to the topic at hand.

Is there a specific problem with rc.d that needs to be solved?

Of late, there seems to be a `hey, let's just make something new' attitude in FreeBSD, replacing programs that worked quite well & had only minor problems that could just be fixed (instead of replacing the entire program). Notable examples are sysinstall and the new pkg tools.
Doing a complete rewrite is almost always a bad idea. Joel Spolsky wrote a good article on this. I'm not saying FreeBSD should stand still, but gradual (planned) improvements are almost always a better idea.
 
Carpetsmoker said:
Is there a specific problem with rc.d that needs to be solved?

I'm relatively new to FreeBSD, so I may just not know the tools very well, but here are some things I like about systemd (more complete list here) that I don't think are easy with rc.d:

  • list show loaded daemons, mounts, devices and their current status
  • better designed runlevel-like system - group processes by targets (multi-user, single-user, etc) and enable/disable targets
  • view system logs and filter the output (time ranges, severity, user/system only)
  • enable/disable services without editing files
  • faster boot and built-in profiling tools

I worked on embedded system (Linux-based) where we needed to reduce boot time. It was running sysvinit, so I decided to try out systemd, which resulted in about 33% boot-time savings (45s -> 30s). With systemd-analyze --blame (boot profiling tool), I was able to see which services were taking the most time to boot, and after some configuration (only an hour or two), I got boot time down to 15-20s, which was sufficient for the project.

I like working with systemd a lot more than any other init system (though FreeBSD's init is also quite nice).

There's particularly wrong with rc.d, I just think there is a better way to manage services, and I don't think the current init can be easily retrofitted with the features that I want. systemd is unlikely to come to FreeBSD, but maybe launchd is a better option anyway; I'm excited to test it out once it's ported.
 
Carpetsmoker said:
Is there a specific problem with rc.d that needs to be solved?

rc.d, as a system initialisation and boot management system, is fine. It allows you to control the order things are started, manually start/stop processes, and do checks on their init status. There's even work to allow more parallelisation of the boot process.

However, as a service monitoring and control system, rc.d is lacking. And there's nothing in the way of event-driven startup (meaning, start serviceA once resourceX is available). The question, really, is whether or not rc.d needs those features. Do you want services to be auto-restarted if they crash? Do you want all services to be "started" at once, but not actually start until the resources they need are ready (similar to systemd's socket-activation system)? Do you need a single, monolithic control stack to manage everything?

Some people do. Some people don't.

For me, personally, I like the simplicity and power of the rc.d setup. It does everything I need on the servers I work with. And it's a lot nicer to work with than upstart, especially when it comes to debugging issues.
 
beatgammit said:
throAU said:
So rather than just use XML, it has its own configuration language?

I don't understand why you'd ever want to use XML for a configuration file. It's difficult to edit, hard on the eyes and not particularly suited for a configuration file. XML works well as a markup language, but it's been shoe-horned into places it doesn't belong (like data exchange, configuration, simple databases, etc).

Because XML is extensible, XML parsers are commodity software and already well tested and debugged, etc.

You're not meant to be editing XML with a text editor primarily (although you can easily enough - no more difficult than editing HTML really) - but it makes writing administration tools a lot easier.

Rather than having a million different parsers for every man and his dog's configuration format (if you're say - writing a control panel application or other system configuration tool), you write an XML editor (using publicly available, pre-existing code) and move on to doing something more productive. Other people can easily write tools to deal with your configuration files without needing to know, and potentially adapt to any new knobs you add to the configuration format. It's all just XML and the tools will just work.

Example: the OS X plist editor. It's just an XML editor and can edit pretty much any configuration file on the machine.

edit: Not strictly true any more as there's a binary plist format, but disk space for config files is not a major constraint these days and the benefits listed above are, IMHO significant.
 
phoenix said:
Carpetsmoker said:
Is there a specific problem with rc.d that needs to be solved?

rc.d, as a system initialisation and boot management system, is fine. It allows you to control the order things are started, manually start/stop processes, and do checks on their init status. There's even work to allow more parallelisation of the boot process.

However, as a service monitoring and control system, rc.d is lacking. And there's nothing in the way of event-driven startup (meaning, start serviceA once resourceX is available). The question, really, is whether or not rc.d needs those features. Do you want services to be auto-restarted if they crash? Do you want all services to be "started" at once, but not actually start until the resources they need are ready (similar to systemd's socket-activation system)? Do you need a single, monolithic control stack to manage everything?

But those problems have already being solved with SMIT in AIX thirty years ago. Can Red Hat just port SMIT to Linux instead BSing with systemd and get over with it? As somebody who makes part of my living by managing bunch of Linux servers I never stop to wonder why in the world large companies threw so much money into the Linux just to reinvent the things that already existed 20-30 years ago in comercial UNIXes. My Linux servers run Silicong Graphics file system XFS. They use init.d from System 5 UNIX. NFS comes from SunOS.The RAID implementation comes from DEC and IBM implementations from 35 years ago. /proc file system comes from Plan 9. Network stack and IPTABLES is what you get when bunch of kids start reading BSD code and try to port FreeBSD IPFW to PC. Even LDAP came out from Microsoft kitchen not from Linux. So I just don't get it. Is there a single thing that was invented on Linux?
 
zspider said:
throAU said:
So rather than just use XML, it has its own configuration language?

Yay.

edit:
I don't think you'll find much support for systemd here mate :)

launchd will be a bit of a stretch., and that's not GNU.

So is this thing actually replacing rc.d or do the people porting it just think it will be, just because they did?

No, openlaunchd is not a planned replacement for rc.d. Having said that, there was a discussion during EuroBSDCon 2011 about adding "Concurrent and deterministic rc.d boot"; and launchd qualifies for this; but with some concern:

(1) launchd is designed to replace init. If launchd replaced init, launchd would have to satisfy the security that init promises (e.g. jails support), and launchd would need to be very stable. Some of these issues could be avoided by spawning launchd under init.

(2) All rc.d related scripts (including ports) will need to be transitioned to the launchd plist format. While launchd provides backwards compatibility with rc.d, we won't get any concurrency on the backwards compatible legacy layer, and therefore, no performance benefits. Also, launchd has no concept of dependences; any number of services can be launched concurrently. Instead of relying on dependencies, launchd mandates that services cooperate through IPC. There are many clever ways around both of these issues, e.g. you could find the dependency matrix for the rc.d files and tack on a legacy parallel-erizer extension to launchd.

Some of these issues were encountered in a 2005 GSoC project https://wiki.freebsd.org/launchd.
 
sotownsend said:
No, openlaunchd is not a planned replacement for rc.d. ...

If that's true, then I fully support staying with rc.d. :beer:
 
Does anybody know what the actual status of the possible integration of openlaunchd into FreeBSD is? I ask this because of the interesting talk Jordan Hubbard gave at MeetBSD (Ogg Link: https://archive.org/download/bsdtalk247/bsdtalk247.ogg). The integration has obviously to be done with maximum security if it will be integrated. I know that launchd does a lot for my Mac OS X, a quick application of top in my terminal in Mac OS X shows this, and since I find that Mac OS X runs very stable and is brilliant, I in my naivety see nothing bad in having that in FreeBSD. But I don't really know much about security in operating systems.

I went to the FreeBSD wiki page concerning the launchd port and watched the Google Talk about launchd. It sounds good. But what do I know? :)
 
Back
Top