How to install nosh init system on FreeBSD?

[Jose]

• vulnerable to mistakes in the service scripts; these are very common as it's shell script syntax, and often they are subtle errors (notably, the depency handling is commonly called dependency hack)

Please. I would much rather deal with crappy POSIX sh(1) syntax than with the systemd unit file nightmare. Quick quiz, what's the difference between Requires, Requisite, and After?

...
Please come up with arguments against runit & OpenRC instead.
...

Hard pass on Openrc. It's one of the reasons why I'm a Gentoo refugee. The current maintainer is a systemd fanboi and keeps introducing "improvements" to make it more like his preferred init system. Look into the tmpfiles fiasco if you want to see awe-inspiringly over-engineered crapware. I wound up maintaining my own ebuild of an old version of Openrc to work around the current maintainer.

I gotta admit that the Void Linux (uses runit) startup is insanely fast. I think there's a use case there for embedded systems, but I disagree with the whole premise that faster boot times are some kind of killer desktop feature. There are far bigger fish to fry first before that becomes a pressing issue for Freebsd.

In OpenRC it is switched off by default.

Did you ever wonder why this is the default? Because parallel initialization introduced too many problems that were hard to debug.

 

[Jose]

At least ntpdate(8) can run in the background while other services are started.

And all services are robust to the system clock going backwards, of course.

 

[Alain De Vos]

A rather general question. Take for instance the dbus port or the sndiod port.
Do these ports work out of the box correctly with runit or deamontools-encore ?
Or does the maintainer need to patch the ports ?
How do I know which ports work and which one don't work out of the box with runit or deamontools-encore ?

 

[mark_j]

And all services are robust to the system clock going backwards, of course.

Years ago on Solaris when they first introduced their current init management, one of my admin guys on a test server went mad with svccfg and auto restart of services. Solaris had a buggy ntpd service that kept crashing because of a mangled config, and it spewed so much information out into the logs it locked the system up; disk full. Lesson learned.

 

[mark_j]

By n-amount do you mean parallel startup or disparate init systems? The latter would not happen since there's one FreeBSD. At least one FBSD-based distribution (TrueOS) used OpenRC IIRC, but TrueOS is history now.

GhostBSD uses OpenRC.

Your point was "if an alternative init system is done right, it would neither hurt nor restrict you, but enable less skilled people to govern it ", to which I replied as I did. My reply was the history behind GNU/Linux changing their init system was because of diversity of systems, maintainability and the NIH syndrome they suffer from.

See above: I'm not promoting systemd... In contrast, my concern is: it's reasonable to evalute runit vs. OpenRC as a replacement for the

Ok, so there's a language issue here. There's alternative, proposing FreeBSD have more than one choice for an init system or replacement, proposing FreeBSD has a new init system.

This is obviously where the confusion comes in. Ok, so replacement it is.

current BSD init, like e.g. is done here for Linux. Both allow for parallel services start, and they might be easier to manage for newbies (that's to be evaluated). Additionally, they supply service monitoring/supervision, which seems to be a demand of professional server plants. It should easily be possible to switch off parallel startup, I you want that. Likewise, it should be possible to not monitor a service. Both are reported to be fairly slim & KISS. Thus, you'll loose nothing, while others could benefit.

As I wrote in another message, I have anecdotes galore of the failure of service monitoring OSs like Solaris's. Only a lazy administrator would trust them. If, for example, postgres crashes, we DO NOT want it to restart and possibly hide the issue.
Now, for sure, there's probably a service that can be restarted automatically, however, that's not a new phenomena, and shell scripts monitoring services have been around since the first UNIX rolled out.

It does not, because the current BSD init does not have a feature that is demanded by many desktop users: parallel service startup. The only arguments against this so far were 1. added complexity, which I doubt; at least the added complexity will not be overly much IMHO; and 2. race conditions, i.o.w.: in most cases, it works well. There are race conditions in any system beyond a certain complexity, e.g. currently my wpa_supplicant(8) does not start automagically, but it does start w/o errors & warnings manually. If I want parallel startup, I would probably run into many issues right now. If it comes by default, I'd be happy.

There's a lot of supposition in there.

First, let's address you major issue: parallelism.

What makes you think this is something demanded of desktop users? Was it not you who said FreeBSD does not hibernate, so, by implication, it must be shut down and started up again, rendering an init system that has parallelisation, a must?
My reply is to fix the problem of non-hibernation, not adjust the init system to fix this one use-case. Should it be fixed? Yes, of course.
Is there a workaround?


Second, the issues of another, replacement init system:

1. Legacy change of all ports to the new init system, where those ports use daemons.
2. Scope creep. As changes to the init system require parallel processes to run, these need to be "aware" of other processes and interact accordingly. If we take systemd as a model (eek!) then the use of sockets for parallel start ups means a significant change to ALL daemons.
3. Parallelizations cause race conditions. Race conditions are bad, more so in a program that between programs. Mitigating them takes work. It's not a real problem with separate processes of course, compared to one process, but it's nonetheless a potential issue. In the case of an init it requires a strict adherence to rules about what can run before/after/required/desired etc.
In the case of something like runit, I tinkered around with this a while back on (ahem) NetBSD. It's parallel, sort of. It just starts as many as possible and keeps retrying until they stick. Not what I call a great system.

Again: please stop complaining about systemd and using it's deficencies as contra argument. We are 100% d'accord that this mess is broken by design. Come up with arguments against runit (sysutils/runit) and/or OpenRC instead.

Why? It's pertinent because the fast startup that systemd apparently gives you was driven by the points you raised. It's extrememly germane because to have a "proper" parallel start up init service you need something like systemd's init or launchd or even svc.


Yes, it is possible to employ an alternative init system for FreeBSD, but then you will lose compatibility with (almost 100%) NetBSD and to a lesser degree OpenBSD. I think that should be a consideration as well. (At the risk of mentioning systemd again, this is the contrarian view held by systemd - ignore compatibility, we're going it alone).

 

[unitrunker]

I like rcorder because it is easy to understand and write RC scripts that can be run in the correct order.

When things break, sequential logs are easier to read.

It would be a great experiment to augment rcorder to support a thin layer of parallelism. This could be done without disrupting existing RC scripts.

 

[Deleted member 63539]

Hi. Desktop user here. Some of you assumed desktop users must have a bunch of services to start on startup. It's not true. I only have dbus enabled.

If you want to improve the startup time of FreeBSD, I think it's wrong to look into the init system. With my own observation, the major slowness come from DHCP. It's the slowest part. I have to wait to my link state up, then down, then it's up again, and the output of ifconfig printed to be able get into actual start of the services. The startup of these services is pretty fast, though. So I have no complains about it.

I used both Linux (Sparky) and FreeBSD, I would say FreeBSD startup time is only 2x slower than Linux. I don't know where you got your value from. But from my experience I found FreeBSD startup time to not that slower to Linux. Sparky is a rolling release system, it always uses the latest and greatest systemd.

I used GhostBSD before go with vanilla FreeBSD. As I know that time they already switched to OpenRC. I would say the startup is a bit faster indeed but the shutdown time of it is much worse than vanilla FreeBSD. Sometimes the shutdown stuck for no reasons. I have to use the reset button to get out of it. My conclusion is OpenRC is not that stable as the vanilla FreeBSD's RC. The vanilla RC has never got me stuck at shutdown. You could say it's because OpenRC is not matured enough, though.

 

[aragats]

• suspend & resume
• parallel service startup

Aren't they kind of mutually exclusive in the context of the discussion? If suspend/resume is perfectly working why should I worry about start-up time? Besides several servers, I use FreeBSD in a laptop and a desktop with GUI for everyday activities. Suspend works fine in my ThinkPad, and I never shut it down.
Another aspect is the servers. In other forums' threads there were discussions (with real-life arguments) on the need of quick start-up as a really essential thing for many servers when down time is very critical.

 

[Mjölnir]

I appreciate all of your pertinent and factual responses. In contrast, hruodr, obviously I can only guess about your level of emotional involvement, so I can only kindly ask you to check that for yourself. If you think I do lie to you intentionally, well, here's the truth: I work for the chinese government & they hired me to have an eye especially on you... Our ultimate goal is to obfuscate all BSDs & their users. Alternatively, you can review my threads & posts and reflect your decision. You'll find both useful & not-so-useful ones, please pick only my bad quick-shots and report them on the forum's blacklist.

As I wrote in another message, I have anecdotes galore of the failure of service monitoring OSs like Solaris's. Only a lazy administrator would trust them. If, for example, postgres crashes, we DO NOT want it to restart and possibly hide the issue. Now, for sure, there's probably a service that can be restarted automatically, however, that's not a new phenomena, and shell scripts monitoring services have been around since the first UNIX rolled out.

I had similar experience on Solaris, too. For one there's the principle issue that service supervision is a very hairy topic, and 2nd SMF was very new & premature then. Don't know the current state of such issues, though.
Nevertheless, there seems to be a demand. I'm not focusing it, we are 100% d'accord that in many cases it's a bad idea to blindly restart a service that died, for there must have been a reason that needs to be fixed 1st. Minix 3 aims to be self-healing, and they have a long way to go.

What makes you think this is something demanded of desktop users? Was it not you who said FreeBSD does not hibernate, so, by implication, it must be shut down and started up again, rendering an init system that has parallelisation, a must? My reply is to fix the problem of non-hibernation, not adjust the init system to fix this one use-case. Should it be fixed? Yes, of course. Is there a workaround?

Yes, I hibernate to a special IRST partition. But as I stated already, to correctly resume requires careful setup, and some devices have issues e.g. they do not 100% conform to standards. 2nd issue: the environment changes between standby & resume, e.g. network. Tools exist to handle this via profiles. Unless you have sufficient time & experience to correctly configure your system & "good" hardware, it's much safer to reboot than to suspend/resume. The issue is not parallel startup itself, but startup speed. Many answer to this: "I'm not concerned about", which is perfectly ok, but the unspoken implication to deny such demand of others, is not.

Second, the issues of another, replacement init system: [...many issues...]

Shure. I did not propose to do such a change at the same hastiness this (and other vital changes) has been done on some Linux distributions. As kpedersen pointed out, such change would require careful thinking and slowly dripple down from -CURRENT. After all, that's why I started this discussion: to collect pro & contra. I found some of it already happened here.

Why? It's pertinent because the fast startup that systemd apparently gives you was driven by the points you raised. It's extrememly germane because to have a "proper" parallel start up init service you need something like systemd's init or launchd or even svc.

Let's wait for a report on runit. I asked s/o who actually has some experience with it. Again, I explicitely did not suggest to switch to one of these, instead I noted all of these as defective (excl. launchd & upstart, which is in history's trash bin).

Yes, it is possible to employ an alternative init system for FreeBSD, but then you will lose compatibility with (almost 100%) NetBSD and to a lesser degree OpenBSD. I think that should be a consideration as well. [...]

This is a reasonable argument.

[...] If you want to improve the startup time of FreeBSD, I think it's wrong to look into the init system. With my own observation, the major slowness come from DHCP. It's the slowest part. [...]

If sysrc -v background_dhclient tells NO, try sysrc background_dhclient=YES

I used both Linux (Sparky) and FreeBSD, I would say FreeBSD startup time is only 2x slower than Linux. [...]

That's a factor and often expressed as such, instead of "100% slower" or "50% faster". some would even call that a magnitude.

Aren't they kind of mutually exclusive in the context of the discussion? If suspend/resume is perfectly working why should I worry about start-up time? Besides several servers, I use FreeBSD in a laptop and a desktop with GUI for everyday activities. Suspend works fine in my ThinkPad, and I never shut it down.
Another aspect is the servers. In other forums' threads there were discussions (with real-life arguments) on the need of quick start-up as a really essential thing for many servers when down time is very critical.

I see no reason why these should be mutually exclusive. We have ThinkPads, which are known to be very conformant to FreeBSD. Many other brands do not behave that well on FreeBSD. Of course, many vendors have improved in this regard in the last few years. Still there is old and/or non-conformal hardware in use, and Linux comes with more quirks to support them. Which amplifies my argument that a wider user-base is advantageous. The developers simply would gain access to more system's data & hardware to test on.

 

[Deleted member 63539]

mjollnir sysrc background_dhclient=YES has no effect. The startup time is pretty much the same regardless of this setting is on or off.

 

[Mjölnir]

mjollnir sysrc background_dhclient=YES has no effect. The startup time is pretty much the same regardless of this setting is on or off.

There are some other sysrc(8) variables you can set, e.g. defaultroute_delay & defaultroute_carrier_delay. Have a look into /etc/defaults/rc.conf if it's important enough to you. Of course do not change them there, but via sysrc xyz=10.

 

[ralphbsz]

This is a very interesting thread. The OP asked a question: How to do X. Within a few hours, there was an answer (from gpb), explaining that its not so easy, but how to do it.

Then we go on for 3 pages arguing why doing X is not such a good idea. With very few real technical arguments, mostly with "we all hate Linux and we even more hate systemd and FreeBSD is perfect so don't mess with it". This makes me sad.

Here is a suggestion: If you have never created a service from scratch (in source code) and installed it in a systemd-based system and in FreeBSD, maybe you shouldn't have such strong opinions? Or have done another interestingly complex task that involves other init systems compared to FreeBSD (and not just set up a system).

 

[unitrunker]

I looked at nosh not long ago.

Nosh anyone?

Is anyone using nosh as their init system? https://jdebp.eu/Softwares/nosh/index.html If so, how and why?

forums.freebsd.org

I tried to verify nosh claims that the service command was hopelessly broken.

C - Sample daemon in C

The handbook has so much good information. After a few minutes of reading, I understood enough to create a bare bones do-nothing daemon. Enough to install it and either start / stop it using the service command and a ridiculously short rc.d script. First, the rc.d script that goes under...

forums.freebsd.org

It seems the original complaints were fixed. I could not reproduce them. There's always room for improvement but the sky isn't falling for RC

 

[mark_j]

This is a very interesting thread. The OP asked a question: How to do X. Within a few hours, there was an answer (from gpb), explaining that its not so easy, but how to do it.

Then we go on for 3 pages arguing why doing X is not such a good idea. With very few real technical arguments, mostly with "we all hate Linux and we even more hate systemd and FreeBSD is perfect so don't mess with it". This makes me sad.

Here is a suggestion: If you have never created a service from scratch (in source code) and installed it in a systemd-based system and in FreeBSD, maybe you shouldn't have such strong opinions? Or have done another interestingly complex task that involves other init systems compared to FreeBSD (and not just set up a system).

Well as I qualify for this, then I apparently meet your demands for posting to this thread.

Thanks for allowing me to participate.

 

[zirias@]

Then we go on for 3 pages arguing why doing X is not such a good idea. With very few real technical arguments, mostly with "we all hate Linux and we even more hate systemd and FreeBSD is perfect so don't mess with it". This makes me sad.

So, you think my arguments are not technical? I think I made it perfectly clear what I expect from an init system and that I'm not against change in general, but just want to see good (technical) reasons for it, especially when touching such a central component.

If you have never created a service from scratch (in source code) and installed it in a systemd-based system and in FreeBSD, maybe you shouldn't have such strong opinions?

Having done exactly that not too long ago (here's the source, I didn't even attempt to add any "init integration" to the repository, but it runs for me between a FreeBSD and a Linux machine), do you still think I'm not qualified to an opinion here?

 

[zirias@]

I tried to verify nosh claims that the service command was hopelessly broken. [...]
It seems the original complaints were fixed.

Well, there are a few things you can't "fix" without some sort of "service manager", like e.g. inherited file descriptors. The workaround you see from time to time (a service closing all file descriptors from 3 to 1024 on startup) is of course badly flawed and should be avoided.

But then, the usecase of service always was to control services from a "normal" root shell. Such a shell is not expected to carry / pass on any opened file descriptors except for the stdio streams. The example given (launching a service from a script executed by a web-server in response to a request) seems pretty strange to me, it's definitely a mis-use of service.

Therefore, sure, there is sometimes a need for some "service management" with more features than traditional init. I'm just saying this can be implemented without ever touching init itself. My argument that it shouldn't go in init is: Most of the time, you won't need it, so init should stay as simple as possible.

IMHO, a well-behaved *nix daemon nowadays needs two modes of operation: One (arguably the default) mode where it "self-daemonizes" on startup, and sets up some logging, e.g. to a file or using syslog(3). This is the mode for manually launching the service from a root shell with service, or from RC scripts called by /etc/rc. And then, a second mode bypassing all that and just using the stdio streams for logging, which is the mode for using the service with some "service manager".

 

[hruodr]

Here is a suggestion: If you have never created a service from scratch (in source code) and installed it in a systemd-based system and in FreeBSD, maybe you shouldn't have such strong opinions?

But the lots of desktop users mjollnir speaks for and not even use FreeBSD also have
strong opinions about FreeBSD init system and want other one. Did they all create a
service from scratch?!

 

[unitrunker]

Well, there are a few things you can't "fix" without some sort of "service manager", like e.g. inherited file descriptors. The workaround you see from time to time (a service closing all file descriptors from 3 to 1024 on startup) is of course badly flawed and should be avoided.

I think the flaw is in fork-and-then-exec. I did not see this with a call to daemon(3). The service manager idea is a bit scary. What happens to the child services when the service manager dies?

The example given (launching a service from a script executed by a web-server in response to a request) seems pretty strange to me, it's definitely a mis-use of service.

If you run something like salt this is not so strange though the specific implementation above sounds buggy.

 

[zirias@]

I think the flaw is in fork-and-then-exec. I did not see this with a call to daemon(3).

No, the "flaw" is fork(2), as all open file descriptors are inherited in the child process. Of course, that's not really a flaw cause many usecases (e.g. pipes) will need exactly this behavior of fork(2). As a side-note: daemon(3) is just a convenience function you probably shouldn't use in portable code; doing the correct steps of fork, setsid, chdir, etc manually will have the same effect. What you would need after fork is something like "close all fds > 2", which doesn't exist. But then, again, the assumption is to start services from a shell that doesn't have any open file descriptors.
With an exec after fork, there's less of a problem if the parent correctly uses the FD_CLOEXEC flag, so an automatic close happens on exec. In fact, if a shell has open file descriptors for its internal use, it should use exactly that flag, so these descriptors are gone before the started service even tries to "daemonize". The same is probably true for a webserver launching some external process...

The service manager idea is a bit scary. What happens to the child services when the service manager dies?

Well, the same that happens to all processes when init dies, of course. This is also an often cited reason to not add too much complexity to init. Still, if you need more features, you can run a service manager offering them -- and of course, you have to trust its quality as the stability of all services managed by it directly depends on the stability of the manager itself.

 

[unitrunker]

I'd prefer a new function where the caller explicitly specifies ...

• uid
• gid
• env
• list of file descriptors

... to pass on to the child process. No, that's not POSIX but I'm not aiming for compatibility. If proven successful, the rest of the world would mimic it.

 

[zirias@]

Well, the same that happens to all processes when init dies, of course.

I have to add that this is simplified and not really correct, my bad... If a service manager is run separately (not as the init process), what would happen is that init would inherit all its child processes in case it dies. So, in theory, those processes could keep working. But as a service that doesn't daemonize typically uses the stdio streams and the service manager would handle the logging, there would be broken pipes in practice and the result would be that these processes die as well.

 

[Mjölnir]

It might be useful to clarify some topics. runit(8)'s /sbin/init is very simple. Man page: runit-init(8). Service supervision is not done by it's /sbin/init itself, but delegated to one of it's companions. There's a recipe how to replace the standard init system. Quote: "[...] The migration can be done smoothly. By default runit runs the /etc/rc scripts in stage 1 as a one time task, so the services are started automatically: [...]" Migrated scripts are already available for many commonly used services.

I'd like to repeat that I started this proposal solely because I see the demand for a faster startup, and naturally it comes to one's mind that parallel service startup can be beneficial in this regard. Since the current init system does not offer this, it's normal to look for existing, mature solutions instead of patching this into the current one. But maybe that's possible, as unitrunker suggested.

But the lots of desktop users mjollnir speaks for and not even use FreeBSD also have strong opinions about FreeBSD init system and want other one. Did they all create a service from scratch?!

I agree 100% to the 2nd (implication). You don't have to be a developer to express a wish for some added functionality or other improvement. On the 1st, no, most of them do not have strong opinions about technical topics. An ordinary user does not care about which init system is used and about it's internals. S/he cares about robustness, ease of use, functionality, and performance. FreeBSD is obviously lagging behind other OSs in the latter regarding startup speed.

 

[hruodr]

FreeBSD is obviously lagging behind other OSs in the latter regarding startup speed.

If that is the case, it is clearly not a problem of the init system. I have in my desktops
rc.local:

local_unbound_enable="YES"
nfs_server_enable="YES"
inetd_enable="YES"

With other init system you will sure not boot faster: most time is consumed by device probing.
I start manually wpa_supplicant, dhclient and xinit with
twm in .xinitrc as normal user, they take their time and with other
init system you will not get faster a system with internet and desktop. I do not have
the fastest computer, but startup speed is not a problem.

Your desktop users are an imaginary construct to support your argumentation.

 

[Deleted member 63539]

most time is consumed by device probing.

From my observation, I'm 100% agree with you.

 

[Mjölnir]

Many of those technical topics are covered in http://smarden.org/runit/benefits.html. Obviously these may be biased by the author's opinion, but it shows he was aware of such issues when he wrote runit. I'm not saying each & every solution he implemented is right. I suggested to explore & verify, as well as OpenRC, where the latter seems to have already been rejected on FreeBSD's review site.
gh_origin, you wrote your Linux starts about twice as fast as FreeBSD. So you say it's device detection is so much faster to account for the difference?

Your desktop users are an imaginary construct to support your argumentation.

Please stop this kind of argumentation, it's getting ridiculous. When I suggest FreeBSD to Linux users (ordinary, non-nerds), usually they come up with three topics:

• many of my friends & buddies have Linux, it's widely deployed and in case I run into a problem, I can ask them & search many forums. And some do not have good english skills, so they prefer information provided in their native tongue.
• startup speed (until GUI login)
• suspend/resume/hibernate