How to install nosh init system on FreeBSD?

I looked Nosh is a special software for BSD and Linux, support FreeBSD / OpenBSD and Debian.
The nosh package is a suite of system-level utilities for initializing and running a BSD or Linux system, for managing daemons, for managing terminals, and for managing logging.
Code:
https://jdebp.eu/Softwares/nosh/
 
The great thing about FreeBSD compared to worse UNIX-like operating systems (such as Linux) is that we already have a solid init system. We don't need to worry about using non-standard alternatives :)
Nosh same to systemd, there are many advantages.
 
Nosh same to systemd, there are many advantages.
Haven't seen one, only the opposite quite often… anyway: There's plenty documentation on the website posted by you - even as txz package; So how to install txz archives: Download all relevant packages, and then just execute for every package: "pkg install /path/to/filename". Then nosh and its documentation is installed.

But if that's really the question I would recommend not to install such a software.
 
The great thing about FreeBSD compared to worse UNIX-like operating systems (such as Linux) is that we already have a solid init system. We don't need to worry about using non-standard alternatives :)
Well, I'd rather say it works than call it solid. FreeBSD is great, but that doesn't mean each & every part of it is great, too. The SysVinit we have is really old-fashioned, to put it politely.
  • no parallel service startup
  • 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)
  • missing features that nowadays can be considered standard on most alternative solutions: service supervision, automatic restart
IMHO it is EoL and I hope in 2-5 years we'll switch to sysutils/runit (sysutils/daemontools or sysutils/daemontools-encore?) or OpenRC. There's a nice article on how not to do it in ewontfix.org (and the follow-up). Maybe we do not need to worry about alternatives, but IMHO the time is ripe to widely test & explore these two.

zoujiaqing, you might want to have a look at these alternatives, as they are either already available as package/port, or in case of OpenRC, were already in use on a FreeBSD derivative (TrueOS). You'll be able to find details in the old sources of TrueOS.
 
Service supervision should not be the concern of init. If you need supervised services, there are separate tools for that.
IMHO it should be. It's the same realm. Of course the init process itself should be as simple as possible, but the alternatives mentioned above and others do include such functionality in their related tools for good reason.
EDIT From my understanding it can be named SysV-style init. I may be wrong here... the name does not matter. The functionality does.
 
IMHO it should be. It's the same realm. Of course the init process itself should be as simple as possible, but the alternatives mentioned above and others do include such functionality in their related tools for good reason.
I don't think there's any good reason to have such functionality in the same software package. If init doesn't have that feature itself (which it clearly shouldn't), your supervisor will run as a child of init anyways.
 
I don't think there's any good reason to have such functionality in the same software package. If init doesn't have that feature itself (which it clearly shouldn't), your supervisor will run as a child of init anyways.
Then there would be many configuration doubled (redundant), e.g. flags to start/restart a service. These topics overlap, they are very closely related, and that's a clear indication that it's the same realm. In fact, that is a good reason, indeed.
 
No, it isn't. I don't see any reason for any doubled configuration -- if I want a "supervised" service, I only configure it in the tool used for that, not in the system's init.

This wording (configuration) brings me to the next criticism: shell scripts. With mewburn rc, there's a large and useful library, so your init script for a "normal" service needs only a few lines. Dependencies also work rock solid. Still, with these scripts, I can do anything unforeseen by the designers of the init system. I personally wouldn't ever want to use a system that replaces scripts by some "configuration".

The only thing FreeBSD's init system can't do at the moment that might make some sense to me is parallelization. Of course, this would just gain faster startup times. If I have the choice between shell scripts and faster startup, I choose the scripts. Sure, would be nice to have both.
 
No, it isn't. I don't see any reason for any doubled configuration -- if I want a "supervised" service, I only configure it in the tool used for that, not in the system's init.
E.g.: maybe the flags to restart a service slightly differ from the flags applied to start it. In standard BSD style, this could be solved by xy_flags="-a -b -c" & xy_restart_flags="$xy_flags -x" in rc.conf(5). But it could also be xy_restart_flags="-a -b -x". It should be clear that these overlap because their common topic is the service in question.
This wording (configuration) brings me to the next criticism: shell scripts. With mewburn rc, there's a large and useful library, so your init script for a "normal" service needs only a few lines. Dependencies also work rock solid.
Experience shows that it's too easy to get it wrong? At least it is error-prone, since it's shell syntax.
EDIT And it's not easy for newbies & non-nerds. You & me can write/fix/change those scripts, they can not.
Still, with these scripts, I can do anything unforeseen by the designers of the init system. I personally wouldn't ever want to use a system that replaces scripts by some "configuration".
With the same argument you could ban ports & packages and instead use old-fashioned tar balls with ./configure scripts, like in the old days. To use a more modern approach does not neccessarily mean there can not be room for pre/post/alternative scripts. IIRC even the overly complex Solaris SMF does allow you to completely bypass the pre-defined standard methods and provide your custom start/stop script, if you think it's reasonable.
 
no parallel service startup

That is good. More deterministic behavior. Less bugs.

Servers don't shutdown and Laptops / workstations sleep. Fast "reboot" time is an old-fashioned concept. Even Windows doesn't shutdown by default these days.

vulnerable to mistakes in the service scripts; these are very common as it's shell script syntax, and often they are subtle errors

I would rather mistakes in plain-text scripts than binary Win32/systemd units. Either way, bugs happen in all approaches. BSD's are just easier to debug.

(notably, the depency handling is commonly called dependency hack)

Code:
ExecStart=
ExecStart=/path/to/program

This hack doesn't have a name yet because systemd is too young. I call it ".ini files are crap for handling services". Catchy huh? ;)

missing features that nowadays can be considered standard on most alternative solutions: service supervision, automatic restart

These have different use-cases. For example Windows, macOS and systemd all target consumer desktop environments.
 
IMHO it should be. It's the same realm.
Thought over the last 13 years of server crashes. In none of it it would be a good idea of something restarted automatically; Instead there has something to be done before the restart (!).

And if I wanted f.e. an Apache to restart automatically, I would simply check by a cronjob if it's running, and if not: start it. But really: Never ever I wanted that a init tool to be done for me. (Side note: Someone remembering just setting X up 20 years ago? That was fun reaching a terminal and getting a single char typed in while X always tried to restart…)

Also I wouldn't want any init system to decide "if daemon X starts, than we need daemon Y also" - won't be fun debugging something when trouble is around. Starting f.e. Apache and MySQL separate isn't that much work that it legals its price. If I would want two to be started in dependency I would write a 3 line shellscript which starts both and use that instead of getting a more complex init configuration.

…and my yesterdays adventure was getting to know who else can overwrite my resolv.conf on a systemd machine (and where its sources are spread over the system)… 99% you don't have to bother about this little file, but when automatic things fail you spent hours to fix it - instead of writing one simple line in a config file.

And yes, such things could be done configurable, so that it behaves as I want. But even then: The price is getting things much more complicated.

…so: In which cases would such a init thing be usefull? I've heard many times that this would be great to have, but I've never heard of an example or usecase with a real benefit.
 
That is good. More deterministic behavior. Less bugs. Servers don't shutdown and Laptops / workstations sleep. Fast "reboot" time is an old-fashioned concept. Even Windows doesn't shutdown by default these days.
Parallel service startup works reliable on other OS. It's principle handling is known for decades.
Tell me one laptop where hibernation works on FreeBSD. I managed to get suspend-to-disk to a special IRST partition (after a timeout fires in suspend mode); that's UEFI/BIOS not FreeBSD, a workaround, and one of very few exceptions. The partition can't be used for anything else yet. Plus it requires careful setup e.g. USB, modem, etc. I can do it, a newbie/non-nerd, s/o who just wants to use a solid system build of and providing sound & proven modules & methods, can not (easily enough, e.g. here). To make FreeBSD more user-friendly is a key to widen it's user base, which will result in more skilled developers after some years. Currently, young IT people leaving university employ Linux for their 1st professional projects, because that is what their're used to.
I would rather mistakes in plain-text scripts than binary Win32/systemd units. Either way, bugs happen in all approaches. BSD's are just easier to debug.
100% d'accord.
This hack doesn't have a name yet because systemd is too young. I call it ".ini files are crap for handling services". Catchy huh? ;)
I did not promote systemd. Instead, I posted a link with the comment: "a nice article on how not to do it"
These have different use-cases. For example Windows, macOS and systemd all target consumer desktop environments.
So why do you think FreeBSD should not be targeting desktop use-case? Same argument as above: people like to use the same system they already know for any new use-case. Are you one of those who's attitude is: "It was hard to write, it should be hard to use"? I can't find any "For Nerds Only"-sign on any FreeBSD website.

…and my yesterdays adventure was getting to know who else can overwrite my resolv.conf on a systemd machine (and where its sources are spread over the system)… 99% you don't have to bother about this little file, but when automatic things fail you spent hours to fix it - instead of writing one simple line in a config file.
Again here too, I'm not promoting systemd. Just because there's a very bad example doesn't mean others are equally bad, right? I explicitely noted runit & OpenRC.

FreeBSD has resolvconf.conf(5) and it can easily bite you the same way. In fact, it bites me because by default dhclient(8) does not seem to use resolvconf(8) (or there's a bug).
And yes, such things could be done configurable, so that it behaves as I want. But even then: The price is getting things much more complicated.
That is to be verified. I do not know if runit & OpenRC are leightweight or blown up.
…so: In which cases would such a init thing be usefull? I've heard many times that this would be great to have, but I've never heard of an example or usecase with a real benefit.
Desktop. Despite I'm one of few who can hibernate, my setup of devices is not 100% perfect, thus I prefer to reboot.
Embedded devices.
 
Again, all that's to be gained here is a quicker startup. If you really want this, it could probably be implemented without abandoning scripts. I don't see why it matters that much, I personally don't care to wait 30 secs once before using my desktop. I would care a lot if I couldn't have init scripts any more. And I still didn't see a single argument, why "supervision" and automatic restarts of services should ever be part of an init system. It's questionable whether you want that at all, as already mentioned -- I personally never had a need. But if you want that, it makes much more sense completely separated from the system init.
 
There are numerous service monitoring & supervision tools in the ports tree, from small utilities to full-blown solutions for large-scale server plants. So there seems to be a need for such functionality. I do agree that automatic restart of a service is not reasonable in most cases, as there must have been a reason to be inspected why the service died.

So the two topics that I'm concerned about the most, are parallel startup & ease of use for newbies.
 
  • Like
Reactions: a6h
Again, all that's to be gained here is a quicker startup.
That benefit was mostly gone since SSDs became standard. Today I get a old Debian 7 VM in 7 seconds till login, a Debian 10 VM in 5 seconds. So it is faster, but whether a boot takes 5 or 7 seconds isn't really interesting anymore.
 
So why do you think FreeBSD should not be targeting desktop use-case?

Because then it makes it defective for any other use-case. As it stands FreeBSD is generic enough for everything. Desktop should never take priority above others so a desktop-centric init system would be an incorrect choice.

Parallel service startup works reliable on other OS. It's principle handling is known for decades.

No it doesn't. It is a mess on Linux. For example this classic bit of systemd when trying to shut down ;)

Code:
A stop job is running for Session c2 of user ... (1min 30s)

Because of the broken design of systemd, this bug where the user has to wait over a minute to shutdown their computer creeps up time and time again. Many distros even use the monolithic dhcpcd system to get around the fact that systemd-networkd is too fragile in bootup order.

Tell me one laptop where hibernation works on FreeBSD.

Thinkpad x61, HP z400, Thinkpad x230 are three that I use currently. They suspend fine. Why hibernate? If you are interested in speed, suspend is faster than hibernate on all platforms.

Are you one of those who's attitude is: "It was hard to write, it should be hard to use"? I can't find any "For Nerds Only"-sign on any FreeBSD website.
Why do you think waiting for worse init systems like systemd to boot up is easier? Surely you just sit there ;)

FreeBSD is a simple tool. Just like a hammer, it is impossible to make it more user-friendly without replacing it with something else entirely. If people want a "fun" experience and to play, they don't use a hammer and they use Microsoft Windows instead.
 
Because then it makes it defective for any other use-case. As it stands FreeBSD is generic enough for everything. Desktop should never take priority above others so a desktop-centric init system would be an incorrect choice.
An init system like runit(8) or OpenRC does not make the OS desktop-centric. E.g. for shure Solaris' SMF did not make it desktop-centric, right? Instead, many of it's features were demanded by server use-case. And before you come up with SMF's deficiencies: I'm not proposing this either.
No it doesn't. It is a mess on Linux. For example this classic bit of systemd when trying to shut down ;)
Again, you're refering to systemd, which I explicitely noted as defective... Please do me a favour and stop using this as an example why my suggestion is invalid. I am 100% d'accord with you that we do not want this b*t on FreeBSD.
Please come up with arguments against runit & OpenRC instead.
Code:
A stop job is running for Session c2 of user ... (1min 30s)
Because of the broken design of systemd, [...]
[again, systemd...] I'm having the exactly same behaviour with the current init system: squid(8) takes ~ half a minute (? did not measure) to shut down, delaying every shutdown.
Thinkpad x61, HP z400, Thinkpad x230 are three that I use currently. They suspend fine. Why hibernate? If you are interested in speed, suspend is faster than hibernate on all platforms.
Because for a mobile system, power consumption counts. Suspend still uses power, while hibernation uses nearly zero (only the ME runs). Beside that, I still did not measure startup times from hibernation vs. power-off. Resuming from disk might even be slower than normal (even non-parallel) startup, because it blindly reads the whole hibernation partition instead of only the size of RAM in-use. Plus, as noted above, resuming correctly requires careful setup, which can be hard even for experienced users, and s/t it's impossible to do right because of bad devices. A "clean" startup is usually much safer.
FreeBSD is a simple tool. Just like a hammer, it is impossible to make it more user-friendly without replacing it with something else entirely. If people want a "fun" experience and to play, they don't use a hammer and they use Microsoft Windows instead.
I doubt the 1st & 2nd sentence ("replace entirely"). FreeBSD is a good base for desktop & server. I know many ordinary, non-nerd people who switched from Windows to Linux for various reasons. If they see FreeBSD starting up, they call it computer-stone age. It's much easier to write a user-friendly input mask for some configuration values than fishing those values from scripts. IMHO if an alternative init system is done right, it would neither hurt nor restrict you, but enable less skilled people to govern it.
 
IMHO if an alternative init system is done right, it would neither hurt nor restrict you,
Well, it would restrict me if it doesn't allow init-scripts any more. Therefore, I'm fundamentally opposed against such ideas. It would definitely add complexity in any case, and that's something I'm at least very sceptical about.
 
[...]

The only thing FreeBSD's init system can't do at the moment that might make some sense to me is parallelization. Of course, this would just gain faster startup times. If I have the choice between shell scripts and faster startup, I choose the scripts. Sure, would be nice to have both.

Meh, parallel startup? I'm not attacking your 'nice to have' opinion but it's overrated. In linux it might make sense with hundreds of processes at startup, it's really only ever going to add complexity & huge chance of race conditions
 
Back
Top