Improving TrueOS: OpenRC

The major features that made TrueOS people to switch seem to be:
- Faster boot.
- Use of runlevels. (Can this be an advantage?)
- The builtin supervisor and start-stop daemon. (Don't we have sysutils/daemontools already?)
 
Well, it appears a considerably good development from my stand point. May someone educate me more on this matter. I have noticed that since around 2012 most Linux distributions have gone the systemd route. Since, the BSD world and the Linux world share a lot of programs, eg the Desktop environment, does this OpenRC, sort of, fill the gap that systemd seeks to fill in the Linux world?

I know, this issue has potential to get touchy, but all I am trying to find out is whether OpenRC makes porting of Linux software easier to the BSD world, given that most Linux software is getting sucked into the systemd idea?
 
There were actually a few reasons we moved to OpenRC for TrueOS:
1) Speed (as mentioned) - OpenRC is a (nearly) drop-in replacement for the current FreeBSD RC system, but since it is written in C instead of tons of shell scripts you get massive performance improvements (even without parallelization enabled)
2) Reliability: OpenRC is *very* reliable at managing/reporting the state of your services at any given time. With the FreeBSD RC system ~50%+ of the running services are nearly unmanagable (return errors when you run `service <name> status`, cannot be reliably started/restarted/stopped due to the "unknown" state of the current service, etc..)
3) Persistence: OpenRC has a couple built-in supervisor systems for watching/managing services:
`start-stop-daemon` is the standard start/stop supervisor which reports states such as starting, started, running, stopped, crashed, and I am sure a couple more as well.
`supervise-daemon` is a superviser for critical services which should "always" be running - in addition to the start-stop-daemon, this has built-in crash handling for critical services and will automatically restart them as needed. This is worlds better than running additional layers of shell scripts and backdoor daemons (such as the daemontools mentioned previously) to try and "fix" things in the current RC system.
4) The history/license: OpenRC was created by a NetBSD developer and distributed under a two-clause BSD license. While it was adopted and "battle-tested" in a few Linux distros such as Gentoo, there are no real "Linux-isms" in it (we just had to clean up the Makefiles to work with the BSD make instead of the GNU make). If you look at the current `rc.d` system in FreeBSD, it had a similar history where it was developed on/by a NetBSD developer and FreeBSD adopted it later on. This move to OpenRC is just seems like the next logical evolution of the current FreeBSD RC system and continues the path set in motion previously by the FreeBSD project.


These are number of additional niceties that we have discovered after the switch to OpenRC on TrueOS - they were not part of the initial reasons for the move, but they definitely solidify our position that OpenRC was the right way to go, but I want to mention one of the big ones:
**Per-device management**
If you list all the current services you will see things like "network","network.em0", "network.wlan0", and more. These "network.<device>" services can be started/stopped/restarted individually *without* touching any other network devices and helping to ensure stable network connectivity on servers and such even when making configuration changes to particular devices. This is a ton better than the old way of completely tearing down and rebuilding the networking stack just because you wanted to change a static IP on one device.
This actually continues with other non-networking services as well (such as `moused`), so you can manage/restart particular devices on-demand rather.

I hope this helps to clear up some of the talk about *why* we moved to OpenRC for TrueOS. My personal hope is that we are "battle-testing" it for FreeBSD right now on TrueOS and that we can help spearhead this for including it in FreeBSD for version 13+ or something.
 
Greetings, beanpole

Apparently it sounds to me that some points listed here are not entirely correct. I do not doubt that there are improvements OpenRC brings, but let us use facts to justify our positions.
Myth
beanpole said:
If you list all the current services you will see things like "network","network.em0", "network.wlan0", and more. These "network.<device>" services can be started/stopped/restarted individually *without* touching any other network devices and helping to ensure stable network connectivity on servers and such even when making configuration changes to particular devices. This is a ton better than the old way of completely tearing down and rebuilding the networking stack just because you wanted to change a static IP on one device.
Click to expand...

Well there is nothing to tear down on this matter in FreeBSD, you just edit /etc/rc.conf add say
ifconfig_em0="inet 10.10.10.100 netmask 255.255.255.0" then #ifconfig em0 down | up for that particular interface. That is not tearing down a network stack. I believe this applies to the moused et cetera.

Nonetheless, this is besides the point. The question I asked is straightforward, does OpenRC provide a way of mitigating porting code from GNU projects given that they are entangling their code with systemd? This daemon supervisory role you talk about, sounds a lot like what systemd is said to do. The difference, if I understand it right, is that the OpenRC project has a narrower scope, respecting the Unix philosophy. May you kindly answer this one, if you are informed on it.
 
Hmmm - but speed ? Dunno how often you reboot your systems that this is really a problem. Even the Jails / VM's I'm running are up in seconds so boot speed isn't a problem. Also reliability, there're daemontools / monit and a lot of other tools that can provide reliability, as OpenRC's supervise-daemon does.
And a configured service doesn't crash by itself, if it does (personally) I like Monit's mails informing me something went very wrong and I can check the logs, what was going on.

Just saying, while highly appreciate choice, FreeBSD's init system is perfect for my needs and can be kept the way it is.
 
Kernan Mzelikahle :
You make a valid point that highlights exactly what I mentioned in an alternate way: The "netif" service on FreeBSD right now is great at bootup, but terrible for restarting/managing network devices later on. Instead you have to resort to manually running `ifconfig`, `wpa_supplicant`, `dhclient`, or other tools directly to get around the fact that the service does not work for individual devices. Even those workarounds have their own set of "gotcha's" though - such as sometimes having to manually read/apply the configuration file options to apply your changes on top (such as when starting `moused` for instance), and you may end up with different results than what is actually configured for the device at bootup. OpenRC does not change the availability of these workaround , but is does ensure that the service itself works properly, so most people won't need to resort to weird/obscure workarounds anymore for basic service management.

OpenRC itself has no bearing on the systemd/init discussions that are going on in open source communities - it is just a replacement for the service management system.
OpenRC **does not** replace `init`. OpenRC **does not** have any kind of integration/compatibility with systemd and/or systemd-capable applications as far as I know (completely different technology which is designed for solving a different set of issues).
 
I think boot time is important to laptop users, on a server I really don't see the point. I use a desktop machine and boot time is not important at all to me. But, personally I think that the boot time speed needs to be replaced with something like "time to uses" or something. It really nice that your OS gets you to the login prompt in 3 seconds, but if it takes 3 or 4 minutes for you to be able to actually use an application after you login, what really is the point of a fast boot?
 
I've no idea, I don't use a laptop. I just assume if you have a laptop you are moving it from one location to the next and possibly rebooting multiple times a day. But not being a laptop users, maybe my uses case is outdated.
 
drhowarddrfine said:
Who reboots their laptop every day?
Click to expand...

I do. And the 9 seconds it takes to boot the system from an SSD certainly won't kill me. Probably two-thirds of that time is just the WiFi starting up, so if I could postpone that until after everything else has started, the time from the loader menu to my window manager would be much shorter. But like I said, the boot time is fine as it is, so I haven't actually looked into whether postponing network connections until the end is possible. Replacing the current init system just for that one thing would be overkill, though other advantages might be worth some consideration.
 
HTPC would also benefit from shortest boot time. I've got FreeBSD machine running KODI (using x11/slim for autologin). Large SATA drive in it, not a SSD. It's taking about 30sec before screen would show up Kodi's main menu. I've considered trying TrueOS for it but have't really had time for making myself familiar with Openrc..
 
I tried out TrueOS a few weeks ago, and boot time is definitely longer. At least when you are running with the default setup. TrueOS enables far more services on the default install than FreeBSD. I'm just talking time from machine start till login, if we go from machine start to 1st application launch it was probably close to 1.5x longer on my machine.
 
I would value a desktop OS more if it could cut down on its required services rather than increase the speed in which they start up.

Looking at old operating systems such as Mac OS X < 10.3, Windows 2000 etc... These actually needed very few services to be run and yet provided over 99% of what I need in a desktop OS.

So I say keep with the slightly slower BSD rc since it more effectively flags up superfluous services that do not need to be there ;)
 
I agree the easiest way to speed up the boot is to decrease the default services. Even on TrueOS I disable stuff, because out-of-the-box it starts more services than I want (auto-update, ntpd, cupsd, RSS feeder, etc). I usually set it up for a "zero ports" config by default, and turn on what I want when I want it. Then again, due to TrueOS's target audience I understand why the extra stuff is included by default.

For me, the OpenRC system feels exactly like Solaris. Just an opinon, but I wonder if there is any ancestry there? In the boot speed race, Solaris is easy winner IMO.
 
I use OpenRC in Debian at work. It looks good and works well.
The only small issues I have are possible dependency conflicts. They are "solved" automatically by OpenRC (and reported in boot messages), but I hate the idea of editing the scripts headers to solve them manually. Maybe there is an "official" way of doing it.
 
I have OpenRC running on Manjaro here (on a notebook) and it runs very well (systemd was a train wreck on the same system).

That said, I have no issues with FreeBSD's RC system. Boot time on my server: shrug, I don't care. This is only ever rebooted if we have a power failure exceeding 30 minutes or when I update the kernel. I also have a HTPC running BSD (Older Celeron 847 Intel NUC at 1.1 GHZ, m.SATA SSD, 8GB RAM, zroot) that boots in about 15 seconds to the SLIM login manager. That is more than good enough for me.

So I would say: RC ain't broken, so why fix it?
 
gkontos said:
I already hate it. Smells a lot like Linux. No, thanks, I like the current RC. I also see no benefit if a system boots faster.
Click to expand...

Ever since I can remember, the booting time and application startup time served on desktops as a subjective performance meter akin to 0-100kmh (0-60mph) for cars. Besides that, faster startup and less waiting makes people happy, instant-on being the holly grail. Also with open operating systems like the UNIX-based ones, desktop users find satisfaction not only in customizing for looks but also for speed. "Desktop" being the key word.

I'm not saying OpenRC should necessarily replace RC but I think it would benefit everyone if RC made use of today's multiple core hardware for parallel startup, had built in daemon tools and include niceties like colored boot messages to instantly spot problems.
 
You must log in or register to reply here.
Back
Top