8 ms·

nosh is, by far, the single most masterfully architected and carefully researched toolkit for init, process management, supervision (also with auxiliary utiliti

nosh is, by far, the single most masterfully architected and carefully researched toolkit for init, process management, supervision (also with auxiliary utilities for user mode VTs and UCSPI) out there at present, trailing only with s6. The FreeBSD community will do itself a great favor by adopting it over the NextBSD experiment. It is, indeed, daemontools++ with lots of optional compatibility layers, carefully planned module boundaries and a small chain loading language for composing execution state. That said, compared to what is standard fare in DevOps, it will likely be found too esoteric. There is also a tad more to be explored in reexamining this controversial problem domain, which I hope to unveil in the coming months.

feld 11y ago
nosh does not solve every problem that launchd, mach, and libdispatch does, which is why launchd will still exist in the BSD world through Jordan, iXSystems, and NextBSD. bringing in launchd provides many more features, but is also the stepping stone to: * networkd * configuration files that are never directly edited by humans * Never having to HUP a process again * The proper death of cron * Processes never being stuck in the wrong state just because something in the system changed, and being able to take intelligent action based on state changes nosh probably can get into FreeBSD faster, but really -- whoever can replace rc scripts first wins. nosh is far with the base system rc scripts, but ports... oh, ports....
- dijit 11y ago
  I would argue the validity of some of these statements. why does my init system need anything to do with my networking, they're completely separate systems in my mind. Cron has a use, it's not like it's overused or underused, it has a niche and it fills it well, what is your argument that it's bad and needs to go into init? Config files will always be hand edited, wether you facilitate that or punish that is up to you, most tools that exist for managing config files exist based on the premise that they can be changed by hand and that you "probably didn't want that" (a-la config management) but having hand-editable config files for testing things is a good thing. HUP'ing a process hasn't been an "issue" for some time, initscripts tend to wrap HUP with a "reload" command, and I'd like people to keep signal handling inside their programs.. since that's well understood as a standard and is POSIX compliant. Now, I won't argue that POSIX is the best thing ever, but unless there is a new better standard to supersede it comfortably, I am not in favour of adopting radical ideologies "because it seems like a good idea" right now, and, evidently, it doesn't anyway.
  - feld 11y ago
    This is exactly the counter-argument that Jordan & co constantly have to battle. "I've never had this problem!" Networking: not what I said Cron: Cron is terrible. Paul Vixie says so himself. Get over it. (everyone, not directed at you) Config files: you're inferring the wrong thing HUP: I shouldn't have to HUP a process to make it learn new things. It should be able to learn them automatically by listening for an event. Please, take a listen of exactly the scenarios Jordan lays out in the latest BSDNow podcast. It makes sense. If we want to be able to build really cool reliable non-kludgey things in the future we need these kinds of features. If your Unix is a server that never moves or changes this is going to sound uninteresting and overkill. But I want the future to allow us to be able to do really awesome stuff. I envision being able to live migrate servers from my basement to Amazon to Vultr to Digital Ocean and not have a single process puke because of changes (network interfaces, IPs, hostnames, etc)
    - lvh 11y ago
      Parent was asking for (among other things) reasons why cron needs to die; saying Vixie ipse dixit is true, but not a technical argument. Notably, it doesn't help the reader understand what the replacement ought to look like.
      - feld 11y ago
        Yes, I should clarify Cron doesn't understand system load Cron doesn't understand suspend/resume Cron doesn't understand *anything* Disk intensive daily jobs shouldn't run if the system is being crushed. I don't want to update my locate database during a backup or during a zpool resilver. If I pause/suspend a {VM, server, laptop} and wake it, jobs are missed ... because it's not time to run them. What if I'm live migrating a VM and there's an important job that needs to run during the time it momentarily freezes the VM for migration? VM resumes on new cluster, job wasn't run. Sure if you're doing this once by hand you can be smart about making sure the timing of migration is safe and the job actually runs. But what if you're running thousands of servers? Ok, so now we throw a ton of code at the wall customized to our environment and hope we don't miss any edge cases. Or we can stop reinventing the wheel and use a job scheduling system that solves this problem. Have you had the fun of cron jobs getting stuck and seeing them just endlessly build up, each one starting the job over from scratch, I/O grinding to a halt as the server gasps for breath under their weight? Alright, lesson learned, customers were angry, now we know we should wrap the job with a lockfile (and hope it's a proper BSD lockf(1) which guarantees atomicity) ... or you can have an intelligent scheduling system that knows not to do such a thing. The possibilities are endless when you feed intelligence into a cron replacement.
- profquail 11y ago
  What does libdispatch have to do with nosh or launchd? libdispatch is already in FreeBSD, are you saying it'd be removed if they switched to nosh?
- JdeBP 11y ago
  > nosh is far with the base system rc scripts, but ports... oh, ports... I recommend reading the nosh Guide. It has a whole chapter on creating service bundles, and lays out in detail the three-pronged approach to ports that nosh enables. This is just a précis. * run scripts are short and simple. One can just write one for a port. It can be a shell script, a perl script, a python program, an execline script, a nosh script, or something else. * You'll find that ports are growing systemd unit files. Indeed, they not only are but have been. The writing has been on the wall about this development for some years, now, and it's well into actually happening. The nosh toolset includes a mechanism that can take the majority of such unit files and generate a native service bundle from them. * One can just take the stuff that's already out there and that's already supplied. Recently the 157 rc.d scripts part of the project has hit the Russian news. That's only part of the story, though. Read the nosh Guide, and you'll find pointers to four prominent collections of daemontools/runit scripts that have existed for years. Look into the package itself, and you'll find almost four hundred service bundles pre-made and supplied in the box. Which of course feeds into the first approach: One can take an existing service bundle for a similar program and adapt it.
vox_mollis 11y ago
Active in this industry for several decades, and I've yet to hear a convincing argument why kitchen-sink init systems are somehow an improvement over rc.d. Can someone please enlighten me?
- geocar 11y ago
  http://cr.yp.to/daemontools/faq/create.html http://cr.yp.to/daemontools/faq/create.html
  - vox_mollis 11y ago
    Thanks, but I don't follow this. Saving a few keystrokes here and there, and process monitoring (which can be provided for by plenty of other packages ) is sufficient cause to reinvent init? Even if djb's /service claims makes sense, it still doesn't support the significantly expanded scope of, say, systemd. I mean, hijacking system logging? What could possibly justify doing that in an init system?
    - otabdeveloper 11y ago
      > I mean, hijacking system logging? What could possibly justify doing that in an init system? DBJ's /service also hijacks logging. In fact, every decent init system hijacks logging -- you want your init to daemonize processes, and when you daemonize a processes you want its stdout to get logged properly.
    - jononor 11y ago
      systemd is not really an init system project. Its a project to make GNU/Linux systems work better. Logging is one of the things I think they have tackled, along with service startup ("init"). I'd argue that logging is better and more useful with systemd as compared to with typical sysvinit (say in Debian/Ubuntu).
    - geocar 11y ago
      Fifteen years ago there weren't plenty of other packages that offered process monitoring: There was init (inittab), /etc/ttys, and roll your own (init.d aka rc.d). People didn't use inittab or /etc/ttys because telling programmers to edit these files was error prone and if they got it wrong, the system wouldn't boot up correctly. init.d didn't have that problem, but programmers so frequently and regularly and consistently got "init.d" wrong in some other way (supervision, logging, etc) that some time in the last fifteen years most unix sysadmins stopped expecting programmers to daemonize and write pid files and simply started monitoring their services for them with tools like daemontools.
2trill2spill 11y ago
Can you give examples of how nosh is superior to launchd?
- simcop2387 11y ago
  The nosh page has a bunch about that: http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/launchd-on-bsd.html http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/lau... Largely, the author doesn't believe that launchd will ever successfully come to BSD. It's had a number of attempts, all of which either failed or fizzled out.
  - feld 11y ago
    It's a hard requirement of the next FreeNAS/TrueNAS release. So it's going to exist in production on many machines. We need competition and I urge him to continue but this dismissive attitude is not healthy.
  - 2trill2spill 11y ago
    I wouldn't call that a very compelling argument about why nosh is better than launchd. So what if previous attempts to port launchd failed when this port(NextBSD) appears to be working. So far I've seen several people on hacker news say that nosh is a better alternative to launchd, but I haven't seen any specifics, right now it just seems like politics.
    - simcop2387 11y ago
      Yea not saying I buy that argument either, the compatibility/conversion layers that exist for nosh could probably be built for launchd, so I wouldn't consider those significant advantages. I also wouldn't consider launchd being deployed on OSX that much of an advantage either given that it seems large parts had to be rebuilt to use the BSD kernel interfaces rather than the darwin ones. Maybe that it's already got configurations for a bunch of services for things from Homebrew/MacPorts/Fink, but they would still need to be reviewed for any broken paths and things from OSX that aren't on BSD.
- 11y ago
aidenn0 11y ago
nosh is by far the worst system I've used in the daemontools line. I experiment with init scripts on a vm I have and have run several variations of daemontools on it. nosh was the only one I couldn't get working, and so I looked at the code to try and figure out what was going on... It appears that they have sacrificed readability of the code in exchange for never having to call fork(). After being unable to fix my problem, it is, in my opinion, not a good tradeoff.

feld 11y ago

nosh does not solve every problem that launchd, mach, and libdispatch does, which is why launchd will still exist in the BSD world through Jordan, iXSystems, and NextBSD. bringing in launchd provides many more features, but is also the stepping stone to: * networkd * configuration files that are never directly edited by humans * Never having to HUP a process again * The proper death of cron * Processes never being stuck in the wrong state just because something in the system changed, and being able to take intelligent action based on state changes nosh probably can get into FreeBSD faster, but really -- whoever can replace rc scripts first wins. nosh is far with the base system rc scripts, but ports... oh, ports....

dijit 11y ago
I would argue the validity of some of these statements. why does my init system need anything to do with my networking, they're completely separate systems in my mind. Cron has a use, it's not like it's overused or underused, it has a niche and it fills it well, what is your argument that it's bad and needs to go into init? Config files will always be hand edited, wether you facilitate that or punish that is up to you, most tools that exist for managing config files exist based on the premise that they can be changed by hand and that you "probably didn't want that" (a-la config management) but having hand-editable config files for testing things is a good thing. HUP'ing a process hasn't been an "issue" for some time, initscripts tend to wrap HUP with a "reload" command, and I'd like people to keep signal handling inside their programs.. since that's well understood as a standard and is POSIX compliant. Now, I won't argue that POSIX is the best thing ever, but unless there is a new better standard to supersede it comfortably, I am not in favour of adopting radical ideologies "because it seems like a good idea" right now, and, evidently, it doesn't anyway.
- feld 11y ago
  This is exactly the counter-argument that Jordan & co constantly have to battle. "I've never had this problem!" Networking: not what I said Cron: Cron is terrible. Paul Vixie says so himself. Get over it. (everyone, not directed at you) Config files: you're inferring the wrong thing HUP: I shouldn't have to HUP a process to make it learn new things. It should be able to learn them automatically by listening for an event. Please, take a listen of exactly the scenarios Jordan lays out in the latest BSDNow podcast. It makes sense. If we want to be able to build really cool reliable non-kludgey things in the future we need these kinds of features. If your Unix is a server that never moves or changes this is going to sound uninteresting and overkill. But I want the future to allow us to be able to do really awesome stuff. I envision being able to live migrate servers from my basement to Amazon to Vultr to Digital Ocean and not have a single process puke because of changes (network interfaces, IPs, hostnames, etc)
  - lvh 11y ago
    Parent was asking for (among other things) reasons why cron needs to die; saying Vixie ipse dixit is true, but not a technical argument. Notably, it doesn't help the reader understand what the replacement ought to look like.
    - feld 11y ago
      Yes, I should clarify Cron doesn't understand system load Cron doesn't understand suspend/resume Cron doesn't understand *anything* Disk intensive daily jobs shouldn't run if the system is being crushed. I don't want to update my locate database during a backup or during a zpool resilver. If I pause/suspend a {VM, server, laptop} and wake it, jobs are missed ... because it's not time to run them. What if I'm live migrating a VM and there's an important job that needs to run during the time it momentarily freezes the VM for migration? VM resumes on new cluster, job wasn't run. Sure if you're doing this once by hand you can be smart about making sure the timing of migration is safe and the job actually runs. But what if you're running thousands of servers? Ok, so now we throw a ton of code at the wall customized to our environment and hope we don't miss any edge cases. Or we can stop reinventing the wheel and use a job scheduling system that solves this problem. Have you had the fun of cron jobs getting stuck and seeing them just endlessly build up, each one starting the job over from scratch, I/O grinding to a halt as the server gasps for breath under their weight? Alright, lesson learned, customers were angry, now we know we should wrap the job with a lockfile (and hope it's a proper BSD lockf(1) which guarantees atomicity) ... or you can have an intelligent scheduling system that knows not to do such a thing. The possibilities are endless when you feed intelligence into a cron replacement.
profquail 11y ago
What does libdispatch have to do with nosh or launchd? libdispatch is already in FreeBSD, are you saying it'd be removed if they switched to nosh?
JdeBP 11y ago
> nosh is far with the base system rc scripts, but ports... oh, ports... I recommend reading the nosh Guide. It has a whole chapter on creating service bundles, and lays out in detail the three-pronged approach to ports that nosh enables. This is just a précis. * run scripts are short and simple. One can just write one for a port. It can be a shell script, a perl script, a python program, an execline script, a nosh script, or something else. * You'll find that ports are growing systemd unit files. Indeed, they not only are but have been. The writing has been on the wall about this development for some years, now, and it's well into actually happening. The nosh toolset includes a mechanism that can take the majority of such unit files and generate a native service bundle from them. * One can just take the stuff that's already out there and that's already supplied. Recently the 157 rc.d scripts part of the project has hit the Russian news. That's only part of the story, though. Read the nosh Guide, and you'll find pointers to four prominent collections of daemontools/runit scripts that have existed for years. Look into the package itself, and you'll find almost four hundred service bundles pre-made and supplied in the box. Which of course feeds into the first approach: One can take an existing service bundle for a similar program and adapt it.

vox_mollis 11y ago

Active in this industry for several decades, and I've yet to hear a convincing argument why kitchen-sink init systems are somehow an improvement over rc.d. Can someone please enlighten me?

geocar 11y ago
http://cr.yp.to/daemontools/faq/create.html http://cr.yp.to/daemontools/faq/create.html
- vox_mollis 11y ago
  Thanks, but I don't follow this. Saving a few keystrokes here and there, and process monitoring (which can be provided for by plenty of other packages ) is sufficient cause to reinvent init? Even if djb's /service claims makes sense, it still doesn't support the significantly expanded scope of, say, systemd. I mean, hijacking system logging? What could possibly justify doing that in an init system?
  - otabdeveloper 11y ago
    > I mean, hijacking system logging? What could possibly justify doing that in an init system? DBJ's /service also hijacks logging. In fact, every decent init system hijacks logging -- you want your init to daemonize processes, and when you daemonize a processes you want its stdout to get logged properly.
  - jononor 11y ago
    systemd is not really an init system project. Its a project to make GNU/Linux systems work better. Logging is one of the things I think they have tackled, along with service startup ("init"). I'd argue that logging is better and more useful with systemd as compared to with typical sysvinit (say in Debian/Ubuntu).
  - geocar 11y ago
    Fifteen years ago there weren't plenty of other packages that offered process monitoring: There was init (inittab), /etc/ttys, and roll your own (init.d aka rc.d). People didn't use inittab or /etc/ttys because telling programmers to edit these files was error prone and if they got it wrong, the system wouldn't boot up correctly. init.d didn't have that problem, but programmers so frequently and regularly and consistently got "init.d" wrong in some other way (supervision, logging, etc) that some time in the last fifteen years most unix sysadmins stopped expecting programmers to daemonize and write pid files and simply started monitoring their services for them with tools like daemontools.

2trill2spill 11y ago

Can you give examples of how nosh is superior to launchd?

simcop2387 11y ago
The nosh page has a bunch about that: http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/launchd-on-bsd.html http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/lau... Largely, the author doesn't believe that launchd will ever successfully come to BSD. It's had a number of attempts, all of which either failed or fizzled out.
- feld 11y ago
  It's a hard requirement of the next FreeNAS/TrueNAS release. So it's going to exist in production on many machines. We need competition and I urge him to continue but this dismissive attitude is not healthy.
- 2trill2spill 11y ago
  I wouldn't call that a very compelling argument about why nosh is better than launchd. So what if previous attempts to port launchd failed when this port(NextBSD) appears to be working. So far I've seen several people on hacker news say that nosh is a better alternative to launchd, but I haven't seen any specifics, right now it just seems like politics.
  - simcop2387 11y ago
    Yea not saying I buy that argument either, the compatibility/conversion layers that exist for nosh could probably be built for launchd, so I wouldn't consider those significant advantages. I also wouldn't consider launchd being deployed on OSX that much of an advantage either given that it seems large parts had to be rebuilt to use the BSD kernel interfaces rather than the darwin ones. Maybe that it's already got configurations for a bunch of services for things from Homebrew/MacPorts/Fink, but they would still need to be reviewed for any broken paths and things from OSX that aren't on BSD.
11y ago

aidenn0 11y ago

nosh is by far the worst system I've used in the daemontools line. I experiment with init scripts on a vm I have and have run several variations of daemontools on it. nosh was the only one I couldn't get working, and so I looked at the code to try and figure out what was going on... It appears that they have sacrificed readability of the code in exchange for never having to call fork(). After being unable to fix my problem, it is, in my opinion, not a good tradeoff.