RC vs OpenRC: Why not both?


Hi there, I was wondering what the status was regarding the dual branches of TrueOs mentionned in https://www.trueos.org/blog/housekeeping-update-infrastructure-trueos-changes/. I am really looking forward to this as I am still running last October’s version. I did try out every edge and stable versions for 6 months after that and a few sporadically since but none would give me the stability I needed because of service start-up and networking issues. It is a testimony to Lumina and TrueOs’ worth that I could still keep my main working machine (very) productive in what was an interim release, so a great big thank to all of you developers for your work.


The work was commited to a branch for now. Installs work fine. FreeBSD does not provide a mechanism to merge the required changes to /etc with pkg base. Therefore some changes need to happen in pc-updatemanager to support upgrading from both existing openrc layouts, and the older october 2016 rc.d style layouts. In short more work, and testing has to be completed to ensure no one system breaks badly due to restoration of rc.d. Meanwhile 50 % of ports have openrc scripts, and almost 100 ports per week have been getting openrc scripts. Perhaps by the next stable this could be targeted, and in an unstable sooner. Time, and proper testing permitted that might be possible. I will provide some more info early next week on what exactly needs updated in /etc to make it work along with instructions on how to test the branch work.


Wow, great news Joe. It will be great to be able to test the branch work.

Though of course being able to switch from an openrc to a non-openrc installation and vice-versa, would be nice, I do not think it is absolutely necessary to start with. I am talking from the perspective of my use-case which is that due to some aspects of openrc not working yet for me (bhyve vms that were created under the non-openrc version not starting correctly in the openrc version, networking problems etc…) I have to stick with the non-openrc version for the moment. I do see the advantages and cool things in openrc but I just cannot take advantage of them now. Another use-case I can imagine is someone who has a lot of work invested in tweaking the init scripts. In both cases, being able to stick to an updated TrueOS is still a great outcome, even if there is no clear migration path to the openrc version yet.

Whatever I can do testing-wise, count me in. Thanks for the great work, as usual


Hi @jmaloney! any news on this front?


Here is the branch:

No further progress there yet at this time as I have been swamped. Will try to post basic instructions next day, or two.

However the team did finish conversion of every last port to openrc which should be in the next unstable. 100 percent done for all ports.


Wow, that’s a landmark! Thanks for all your efforts and do not let me stress you out, Believe me, I know what it is to get swamped and I will take what comes, when it comes.


I will be very glad to be able to just use FreeBSD’s normal RC on TrueOS. I am very sick of not being able to use information online to do things like configure network stuff for jails or bhyve. IMHO, no amount of improving boot times is worth the extra pain of having to deal with doing the service configuration differently from standard FreeBSD - especially stuff that I do rarely and don’t remember how to do the next time I need to do it. If OpenRC were a drop-in replacement with all of the commands being the same and all of the configuration being done exactly the same way, I wouldn’t care - it might even be nice - but I’m sick of trying to get something to work only to figure out that I’m doing it wrong, because TrueOS does it differently from standard FreeBSD. And half the time, even when I realize that that could be the problem, I really don’t have a good way of knowing whether I’m doing something that works with RC but not OpenRC or whether I’m just doing it wrong.

So, it’s great that OpenRC is becoming more usable, but the fact that it does things differently just means that it’s getting in my way.


Yep, I find it confusing, too. I really wonder though if the boot time is reduced that much. It still takes “ages” to boot if I compare it to a systemd-boot. Anyway, great achievement that you converted the stuff but I am really happy when I can use standard-rc and apply my existing knowledge.


I hope OpenRC will be documented in detail. It would be great to have a table with one column showing how to tweak things in FreeBSD RC next to the other column explaining OpenRC stuff.

I understand that in the future there will be both systems in parallel for the user to choose which to use: https://www.trueos.org/blog/housekeeping-update-infrastructure-trueos-changes/


There is already a table/comparison between RC and OpenRC in the TrueOS handbook.
Basically it only boils down to 2 differences in configuration/usage:

  1. The service files for OpenRC are placed in */etc/init.d instead of */etc/rc.d
  2. Instead of placing [service]_enable="YES" into /etc/rc.conf to enable a service at boot, you run rc-update add [service] to enable it in OpenRC.

That is it.

While OpenRC is faster, it is not significantly faster at the moment because the base services themselves are nearly identical between RC/OpenRC - meaning that the network service is still the biggest factor in service startup times. One of the next phases of development for OpenRC on TrueOS is to review and cleanup the base services (now that the bulk conversion of the ports tree is finished).
We had a prototype of an updated network service (using the OpenRC built-in functionality) a while back and it dropped the service startup time down from ~30 seconds to ~5 seconds. This savings was primarily because it gets rid of thousands of lines of shell commands and replaced it with a much more streamlined script that uses pre-compiled C for lots of the heavy lifting (OpenRC built-in functions).


As you can see above OpenRC does more than simply decrease the speed of boot time. We can also use it to monitor services, show how long a service has been running, and how many times it has been restarted. Which is just one of the features this new capability will bring as it is expanded upon.

I do appreciate the feedback which inspired changes like this, and as an end user myself I totally feel the same way about a lot of this. I do realize some mistakes were made in how this was rolled out, and I apologize for my part in them. So yes the rc toggle effort is one of the things I wanted to do to help resolve that.

Sometime ago I had stepped down from making any further commit contributions to the project. So I am not sure when this rc toggle feature will land. One of the ways the project can benefit more is more QA towards TrueOS/FreeBSD from me which I can make time for a little easier as a means of contributing. I am very hopeful our next 6 month release will be the best thing this team has ever put out!


@jmaloney, I see ue0 in your network adapters on the screenshot. Does it mean you have connected a usb device or tethered a smartphone? I hope it does, since that’s one of the few things I found impossible to do with the OpenRC version a few months back, a deal-breaker in my use case.


Yep that is a USB hub with an ethernet port. It does work. If yours does not load you could try the following as root:

cd /boot/kernel
kldload if*

Then run ifconfig to see if your new device shows up. If it does then we know it is an issue with module autoloading with devd. I am not currently sure how to solve that with devd but it can be resolved manually by finding the specific kernel module you need, and loading it with with loader.conf, or rc.conf.


Thanks for the advice but the problem is elsewhere. The correct driver
loaded and the hardware is recognized. I can actually use it without any
problem in my TrueOS install from October, it’s just that it stopped
working with the openRC version (it looks like a DHCP client related
problem). I have not tried new builds regularly since April though,
since by that time no network adapter on my Toshiba A50 was getting
DHCP. I will try a fresh install of the latest stable when I have sorted
out the urgent business.


Oh maybe just enable dhcp for the device in rc.conf? Or using network manager to enable dhcp? I do know it will not do that yet automatically with newly attached devices that are attached post install.


gentle nudge :blush:


I’m reading that a lot of work went into joining OpenRC startup scripts and ports together. But I still can’t figure out how to start chyves. I’m running Trueos Server: FreeBSD 12.0-CURRENT (GENERIC) #10 d26791952(trueos-stable-17.12)

After installing chyves via pkg I can start virtual machines and I set its boot flag to on by running

# chyves <vm-name> set rcboot=1

To start it automatically on FreeBSD I just put chyves_enable="YES" to /etc/rc.conf and vm would start automatically. But TrueOS does not respond to that change. I tried (blindly filling the gaps) with:

# rc-update add chyves
 * rc-update: service `chyves' does not exist

Am I just unfortunate this port did not yet get rc-scripts or am I it doing completely wrong? What can be done to start VMs automatically on boot?

Docker is on FreeBSD now?