# Improving TrueOS: OpenRC



## vejnovic (Jan 23, 2017)

https://www.trueos.org/blog/improving-trueos-openrc/


----------



## Cthulhux (Jan 23, 2017)

Yay. 

Hooray. 

Why?


----------



## vejnovic (Jan 23, 2017)

I like FreeBSD rc...


----------



## gkontos (Jan 23, 2017)

Really irrelevant topic


----------



## Maxnix (Jan 24, 2017)

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?)


----------



## gkontos (Jan 24, 2017)

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.


----------



## MarcoB (Jan 24, 2017)

Faster boottimes seems the only given reason for it. For a system aiming at the desktop like TrueOS this can be useful.


----------



## Kernan Mzelikahle (Jan 24, 2017)

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?


----------



## beanpole (Jan 24, 2017)

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.


----------



## Kernan Mzelikahle (Jan 24, 2017)

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.



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.


----------



## rudelgurke (Jan 24, 2017)

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.


----------



## beanpole (Jan 24, 2017)

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).


----------



## Kernan Mzelikahle (Jan 25, 2017)

Thank you beanpole. It is clear now.https://forums.freebsd.org/members/41306/


----------



## drhowarddrfine (Jan 25, 2017)

gkontos said:


> I also see no benefit if a system boots faster.


There is a certain slice of users that seem transfixed by boot times to the point where they will reject an OS based on that no matter how bad the rest of the system is.


----------



## roddierod (Jan 25, 2017)

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?


----------



## drhowarddrfine (Jan 25, 2017)

Who reboots their laptop every day?


----------



## roddierod (Jan 25, 2017)

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.


----------



## ANOKNUSA (Jan 25, 2017)

drhowarddrfine said:


> Who reboots their laptop every day?



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.


----------



## aht0 (Apr 20, 2017)

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..


----------



## roddierod (Apr 20, 2017)

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.


----------



## kpedersen (Apr 20, 2017)

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


----------



## ronaldlees (Apr 20, 2017)

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.


----------



## aragats (Apr 20, 2017)

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.


----------



## recluce (Apr 26, 2017)

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?


----------



## ompadu (May 2, 2017)

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.



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.


----------



## recluce (May 2, 2017)

ompadu said:


> 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.



I strongly disagree here:

on my state of the art desktop system, UEFI post takes most of the boot time (30s plus), OS boot is just a fraction of that (Linux with upstart about 7s, FreeBSD maybe 12 to 15s). Suspend and Resume is about 1 second for both. Windows is similar. Nothing to fix here, really - we could talk about the resilience of the suspend function in FreeBSD, though.

Each and every boot sequence must be identical and race conditions should be impossible by design, both for operational safety and for security. FreeBSD's RC system delivers that, parallel startup makes this difficult, if not impossible.
"Nicely coloured boot messages" is what systemd gives me. Too bad that they flash by too fast to be read and cannot be found in a log file later. I prefer a simple "dmesg" to tell the whole story, as on FreeBSD.


----------



## Carpetsmoker (May 5, 2017)

I like rc.d because it's a good system, but I also dislike it because the very concept of daemons is not a very good one.

Every daemon has to properly "daemonize". Many programs don't do this properly. In addition, they'll have to take care of their log files and such. It's also difficult to see which services are actually running; PID files "solve" that, but it's not very robust, and many programs don't handle this properly either (so the init system has to fix that for them).

Compare this to a system where the process *doesn't* daemonize but stays attached to the init system. Now, the init system can detect failures reliably; it can send signals reliably. It can consistently handle log files by redirecting stdout and stderr, there are no "stale PID files", and a lot of boilerplate code is spared for every daemon written.
This is exactly what tools such as runit/daemontools and systemd do, and this seems to be a much improved way of doing things (regardless of implementation shortcomings).

Unfortunately, OpenRC seems to be using the "old" daemon mode of operation, which is a shame. It seems to have some support for daemontools' way of doing things via the supervise-daemon program, but judging from its documentation here and here, it seems to be only half a solution. It still uses PID files for example.

OpenRC could very well be better than rc.d, but it's still a flawed concept.


----------



## ompadu (May 5, 2017)

Carpetsmoker said:


> I like rc.d because it's a good system, but I also dislike it because the very concept of daemons is not a very good one.
> 
> Every daemon has to properly "daemonize". Many programs don't do this properly. In addition, they'll have to take care of their log files and such. It's also difficult to see which services are actually running; PID files "solve" that, but it's not very robust, and many programs don't handle this properly either (so the init system has to fix that for them).
> 
> ...




Are you familiar with jobd? It's a job manager that started as a clone of launchd. Presentation on BSDCan 2016 (video, slides), earlier interview on BSD NOW.


----------



## gkontos (May 5, 2017)

ompadu said:


> 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.



If you want faster boot then get an SSD. I also don't reboot my system (desktop) for at least 40 days. I always put it to sleep. Regardless, changing from spin up to SSD has given me a tremendous speed increase in everything, including boot time. 



ompadu said:


> 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.



I am not saying that it is bad. I just like the traditional RC.


----------



## wblock@ (May 6, 2017)

OpenRC works, it's like a more polished version of rc.d.  The worst thing about it is that they called something "runlevels" which is unrelated to the SysV stuff.  But it misleadingly implies it and is the first thing anyone hearing it thinks.  If they changed that stupid name, it would be a huge improvement.

Faster booting is a good benefit, but it's not the only one.  Simpler rc scripts are another.


----------



## rigoletto@ (May 7, 2017)

I am very well used to OpenRC as a former Gentoo user, for several years. It work quite well and I do not remember of a single major problem with it, but I can say the exactly same about the current FreeBSD rc.d - but taking in consideration I am using FreeBSD for less than a year.

That said, any of them are equally fine for me but (IMHO) the only real justification to swap them on FreeBSD would be if OpenRC gain/acquire some useful-nice-extra capabilities, like daemontools and some others cited before. I mean, a more modern/improved version of what already do exit.


----------

