Improving TrueOS: OpenRC

[recluce]

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.

 

[arp242]

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]

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.

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]

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.

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@]

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@]

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.