
nosh: Linux/BSD init, with systemd compat - lvh
http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html
======
vezzy-fnord
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
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
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
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
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
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.

~~~
simoncion
> Disk intensive daily jobs shouldn't run if the system is being crushed.

ionice(1) works _really_ well on Linux.

> Have you had the fun of cron jobs getting stuck and seeing them just
> endlessly build up...

It sounds like this would be _fairly_ easy to fix. Either set a timeout for
each cron job, or make a mark when each job completes and don't start a second
copy of that job if the mark is not found.

Regardless, I don't see how these are reasons that cron needs to _die_. They
_are_ decent reasons for _improving_ cron. ;)

~~~
click170
I think there's an argument to be made that these things dont belong in cron,
they belong in logic that lives elsewhere.

Do one thing and do it well.

~~~
lobster_johnson
It can be argued that Systemd _does_ do just one thing, and well.

Unix has a process model which has historically been lax. Things built on top
of it tend to be shell scripts. Cron is probably the worst example of "do one
thing well", because it does that one thing very poorly. It can only _start_
stuff. If you want to avoid dogpiling, enforce timeouts, enforce resources,
prevent multiply-forking jobs from leaving orphan processes, preserve
historical per-job output, pause or delay jobs, manually start jobs, balance
jobs across multiple nodes, etc. — then you just have to cobble that together
yourself. I certainly have.

What "cron" and "/etc/init.d/something" and "scripts that run on ifdown/ifup"
and "scripts ran run on DHCP changes" and "scripts that run at specific times"
have in common is that they are arbitrary processes whose lifetimes are
bounded — by time (cron-like behaviour), dynamic events (such as networks
going up or down), human input (manual start or stop) or other factors.
There's no conceptual difference between a clock and a human action, for
example. If job X is set to run at midnight, and I want to run it a little
sooner today, couldn't I just trigger it manually? For Cron to have this, and
for Cron to fix the other deficiencies I mentioned, it would have to replicate
features to the point where it becomes... Systemd. Because Cron starting
processes at specific _times_ is just a special case of starting processes at
boot (init) or starting processes when networking goes up (/etc/network/if-
up.d or whatever).

Systemd is a process lifecycle supervisor. It tracks the lifetimes of
processes. That's about it. Everything else is pragmatic problem solving. Just
like grep's simplicity ("finds stuff by text") is clouded by the dozens of
arcane flags it must support to real-world use cases (styles of regexps,
reading patterns from a file, printing options), so must Systemd cater to many
minor aspects.

It can be argued that Systemd could be less monolithic and more pluggable, but
I feel that's another story.

~~~
simoncion
> It can be argued that Systemd _does_ do just one thing... Systemd is a
> process lifecycle supervisor. It tracks the lifetimes of processes. That's
> about it.

It's also a /dev node manager, and a syslogd replacement, and a cron
replacement, and a dhcpcd replacement, and a mount/umount, insmod/modprobe
reimplementation, [0] and a bootloader, [1] and...

The systemd project is _huge_ , _sprawling_ , and _continues_ to grow.

> Cron is probably the worst example of "do one thing well", because it does
> that one thing very poorly. It can only start stuff. [If you want something
> sophisticated you _inevitably_ have to implement systemd.]

It turns out that you don't! Check out fcron. Its crontab is described here:
[2]. If you're impatient, search for "The options can be set either for every
line".

> Things built on top of [Unix's process model] tend to be shell scripts.

The phrase "shell scripts" gets tossed around like it's a slur.

What are the _essential_ differences between a Bash program, a Python program,
a TCL program, an Erlang program, and a C program that all do the _very_ same
thing? What makes "shell scripts" so undesirable?

[0] Given the number of times things like recursive bind umounts, module
loading/unloading, and _more_ core stuff have broken on systemd-enabled
systems and _only_ such systems, it's almost impossible to believe that
mount/umount, insmod/modprobe & etc. aren't being reimplemented in the systemd
project. ;)

[1] [https://wiki.archlinux.org/index.php/Systemd-
boot](https://wiki.archlinux.org/index.php/Systemd-boot)

[2]
[http://fcron.free.fr/doc/en/fcrontab.5.html](http://fcron.free.fr/doc/en/fcrontab.5.html)

~~~
atombender
> Check out fcron ...

Well.

* Can it let me start jobs manually?

* Can I defer their scheduling programmatically without editing a file to comment it out?

* Can I add or remote new jobs programmatically and atomically?

* Can I ask it about the status of a job?

* If a job fails, is it retried, up to a limit?

* Can I give it a time budget after which the job is killed?

* Can I give it a resource budget (e.g. CPU usage)?

* Can it log the output tagged with an identifier that identifies the job uniquely across time?

* Can it notify me by some programmatic mechanism (so that I can pipe it to a webhook, say) if a job fails?

* Can I programmatically start jobs, edit jobs, etc. from a different host?

* Can I ensure that only a single instance of the job runs in a cluster, if multiple hosts have been configured with the same job?

* If the job runs so long that it overlaps with the next scheduled period, can it ensure that the next job doesn't start yet?

* If the job forks, can it ensure that the children are cleaned up?

These are some of the features that I want from a job scheduler. Yes, _some_
of it can be cobbled together with wrapper scripts, manual cgroups, and so on.
But I don't want to write all of that.

> What are the essential differences between a Bash program

Shell scripts are brittle. That's hardly debatable. You _can_ write solid
shell scripts, but people generally don't because it takes a lot of effort and
arcane knowledge to do it successfully.

A lot of people don't know about classic safeguards such as "-e", "-o
pipefail", exit traps and so on. Some of the safeguards you want are hard to
do safely and atomically.

Unix has a nice pipe system, but shell scripts that need to drive a lot of
things invariably mess it up because everything pipes to the same place. You
get errors and information output intermingled and there's often no way to
tell who emitted it without going step by step.

Throughout my 20+ years of using Unix variants, shell scripts and "shell-
scripty interdependencies" have always been a source of problems, usually
related to things like escaping, quoting, option parsing, alias expansion,
variable expansion, bad toolchain detection (e.g. assuming your "ls" is GNU),
ignoring exit codes, bad output parsing, etc.

"find | xargs" works just fine until the day you encounter a file name
containing spaces. Then you do "find -print0 | xargs -0" and you're happy
until the _next_ edge case comes along that touches on space handling, of
which the shell language family is rife. It gets worse when shell scripts try
to be nice over SSH.

At least languages like Python and Erlang have first-class support for
primitives, even if their dynamic typing leads to a lot of potential
situations where the runtime parameters aren't what the author assumed, and
things blow up because someone didn't sufficiently duck-type. I'm not a huge
fan of Go, but Go is a surprisingly good fit for command-line tools, and its
strictness and static typing helps avoid a whole class of errors.

I love shell scripts, and I write them nearly every day, but I would never
build an OS on top of them.

~~~
simoncion
Several of the items in your bulleted list make it seem like you either didn't
read all of, or didn't thoroughly understand fcron's crontab manpage. I urge
you to go back and re-read the documentation, or -at least- the Options
section.

I'll address the items that aren't covered by the documentation that I linked
to. :)

> * Can it let me start jobs manually?

> * Can I ask it about the status of a job?

Yep. [0]

> * Can I defer their scheduling programmatically without editing a file to
> comment it out?

I'm not sure what it means to "defer" scheduling. That sounds like changing
the time a job starts. If I'm wrong about that, please do let me know. :)

Anyway. _Every_ job scheduling system stores its non-volatile info on disk.
fcron's full-featured interface to its job scheduling system is found in [1].
I don't know if that meets your requirement.

> * Can I programmatically start jobs, edit jobs, etc. from a different host?

Yep. [0] [1]

> * Can I add or [remove] new jobs programmatically and atomically?

AFAICT, yes. [1]

> * Can it log the output tagged with an identifier that identifies the job
> uniquely across time?

> * Can it notify me by some programmatic mechanism (so that I can pipe it to
> a webhook, say) if a job fails?

Yep. That's in the email that it sends. What your reporting infrastructure
does with that email is up to you.

> * Can I ensure that only a single instance of the job runs in a cluster, if
> multiple hosts have been configured with the same job?

AFAIK, Systemd doesn't do this, so I don't know why you're asking for it.
(Other than the fact that it would be _rather_ nice to have.) :) But, no.
AFAICT, fcron runs on a _single_ host. I _have_ heard about chronos, though.
[2]

So, I need to preface the rest of this commentary with the following: Bash is
clunky, kinda unwieldy, and very, very far from my favorite language. There
are several reasons why I select Python for scripts that get much more complex
than "rather simple". Please keep this fact in mind while reading the rest of
my commentary. :)

> Shell scripts are brittle. ... You can write solid shell scripts, but people
> generally don't because it takes a lot of effort and arcane knowledge to do
> it successfully.

But C programs written by people who can't be arsed are _also_ brittle and
-even worse- the language itself is filled with hidden and subtle pitfalls!

> Unix has a nice pipe system, but shell scripts that need to drive a lot of
> things invariably mess it up because everything pipes to the same place [and
> this makes unwinding intermingled output difficult sometimes].

So, why not religiously do something like using logger(1) with appropriate
tags and ids? I mean, you actually have to _work_ a little to get reasonable
logging in (almost?) _every_ language. Hell, -IIRC- C doesn't _ship_ with
anything substantially more sophisticated than printf(3) and friends. ;)

> Then you do "find -print0 | xargs -0" and you're happy until the next edge
> case comes along that touches on space handling...

How does

    
    
      IFS=$'\n'
    

and/or the

    
    
      "${VAR}"
    

pattern not fix _all_ space handling problems when using bash? (Bash is one of
my _weaker_ languages, so if you know, I'm _genuinely_ interested in hearing
about it.)

However, if your answer is something like "Some other script you use might
screw things up!", then my reply is "Bash and sh programs are _not_ the only
languages in which we might find an erroneous program on which we depend.". :)

> It gets worse when shell scripts try to be nice over SSH.

How's that? I'm seriously asking, for my own edification.

> I love shell scripts, and I write them nearly every day, but I would never
> build an OS on top of them.

I don't think that I (or anyone else who has an _informed_ opinion on the
topic of sysvrc replacements) has _ever_ seriously suggested that one built an
entire OS on top of shell scripts. Frankly, they're insufficiently powerful
(not to mention [comparatively speaking] too damn slow) to reasonably
accomplish the task.

However, OpenRC -and _so_ many other RC and init systems- demonstrate that
shell scripts can provide _rather_ powerful, relatively foolproof methods for
a packager or service author to control services on their system.

> At least ... Erlang [has] first-class support for primitives, even if their
> dynamic typing leads to a lot of potential situations where the runtime
> parameters aren't what the author assumed, and things blow up because
> someone didn't sufficiently duck-type.

I am _totally_ , _seriously_ , _not_ (!!) getting on your case here, but how
much work have you done with Erlang? I'm a novice-to-middling Erlang
programmer, and the situation you described seems... difficult to run into
unless you're _unusually_ careless. (Python, OTOH...)

> I'm not a huge fan of Go...

Me either! It's _so_ opinionated. Does it _still_ consider unused imports to
be compile-stopping errors? :(

[0]
[http://fcron.free.fr/doc/en/fcrondyn.1.html](http://fcron.free.fr/doc/en/fcrondyn.1.html)

[1]
[http://fcron.free.fr/doc/en/fcrontab.1.html](http://fcron.free.fr/doc/en/fcrontab.1.html)

[2] [https://aphyr.com/posts/326-call-me-maybe-
chronos](https://aphyr.com/posts/326-call-me-maybe-chronos)

~~~
lobster_johnson
I could talk about this all day, but I don't have the time, so I'll just
address some of your more important points.

Fcron has some features that I like that I didn't find when I looked at it
(the documentation is _very_ poor: "dialog dyn-amically with a running fcron
daemon" didn't really invite me to think that it had a job scheduling UI), but
it's not sufficiently built out that I will be able to trade my current
toolset for it. For example, it seems that it lacks any process isolation.
Email-only reporting is not acceptable. And so on.

I agree that Fcron is a better Cron. But I also think that it's a very poor
Systemd. Like Systemd, it controls the lifetime of processes; it has an
overlapping feature set (job files, backing store, control UI) and if one made
it complete, it would look a lot like Systemd. I'd rather have one tool do
process orchestration, rather than two.

> But C programs written by people who can't be arsed are also brittle

Certainly. But it's hard to write C programs that fail for the same half-assed
reasons that shell scripts do. C programs suffer from _other_ problems. I'd
much rather have a C program segfault on bad input right away than have a
shell script happily continue to run because it ran some text file through tr,
got a different result than it expected, stored it in a variable, passed it
badly-quoted to some tool 27 lines down in the script, and triggered an
impossibly obscure error message unrelated to the original cause.

But the real alternative isn't C, of course. It's one of the languages you
mentioned. Ruby, Python, Erlang, Go, Nim, etc. all improve on the historical
sloppiness of Unix.

> How does ... not fix all space handling problems when using bash?

There's much more to it than that, I believe.

For example, preserving quoted arguments is a nightmare. Let's say you read
some file that contains command-line options. It contains something like:

    
    
        -x -y --string="hello world"
    

You want to read that, preserving quoting, into an environment variable, which
you then want to modify and pass on to another script. Turns out this is hard.
Normally, quoting "$foo" works; but the moment you fiddle with it, the quoting
is lost. There's a neat bash trick few people know about which exploits its
array support:

    
    
        #!/bin/bash
        configopts=`cat configfile`
        eval ARGS=($configopts)
        ARGS+=("--anotherflag")
        ARGS+=("$@")
        ./somecommand "${ARGS[@]}"
    

Throughout this script, $ARGS' internal token structure is preserved, even
when it's manipulated. There are other ways to accomplish this, but none of
them are pleasant, and this way is quite pleasant, once you get past the
weirdness. But I would bet that most developers don't even know that bash has
first-class array support. (If you know a better solution,

This is just one horrible corner case where a naive implementation would blow
up. As I said originally, it's possible to write safe, resilient, mostly well-
behaved shell scripts. But it's hard; you have to know about every possible
pitfall [1] and divergent behaviour on GNU and BSD. Shell scripts implement
most of their functionality through external commands, not functions, so you
cannot assume much about the interface of commands. This takes time and
effort. But shell scripts are easy to write, which invites sloppiness. Few
people write unit tests for shell scripts. Few people use something like
autoconf to sniff the runtime environment (e.g., GNU vs BSD).

As for "entire OS built on shell scripts", every Unix distro out there is
built on tons of shell scripts. Even Upstart and Systemd can hardly avoid
using a bit of scripting.

As for SSH, you're in a pretty good spot if you send your script using <<'EOF
and disable the tty. Otherwise you run into quoting issues fast, and scripts
that expect interactivity will hang. There might be some other corner cases, I
forget. Controlling SSH from scripts has always been painful and brittle for
me.

> [Erlang] ... difficult to run into unless you're unusually careless

Sure. But it's there. Erlang's duck typing means it's susceptible to sloppy
inputs just like any other duck-typed language. It's a lot better than the
shell script situation, to be sure.

[1]
[http://mywiki.wooledge.org/BashPitfalls](http://mywiki.wooledge.org/BashPitfalls)

~~~
simoncion
> (the documentation is very poor: "dialog dyn-amically with a running fcron
> daemon" didn't really invite me to think that it had a job scheduling UI)

I... uh.... read the documentation -rather than the second headings- and
immediately understood that it had a job scheduling UI. :) I understand that
we're all busy, but it does pay to take fifteen minutes or an hour every
couple of weeks to sharpen the axe.

> it's not sufficiently built out that I will be able to trade my current
> toolset for it.

I never was claiming that you should. I was addressing your initial claim,
mentioned a little bit later in this comment.

> For example, it seems that it lacks any process isolation.

Linux does that.

> Email-only reporting is not acceptable.

Consuming email is trivial. There are something like 349024823904 libraries
and like a handful of good ones to do so in _every_ popular language. :)

> I agree that Fcron is a better Cron. But I also think that it's a very poor
> Systemd.

Your initial assertion was that the only way to get a good cron was to
implement systemd. I demonstrate that that's not true, and you counter with
"Well, _that_ cron's not systemd!"!

 _sigh_.

> I'd much rather have a C program segfault on bad input right away...

You and I _both_ know that it's trivial to write a C program that does
_exactly_ the same thing that your hypothetical poorly-written bash program
does. :) Bash didn't invent Heisenbugs.

> It's one of the languages you mentioned. Ruby, Python, Erlang, Go, Nim, etc.
> all improve on the historical sloppiness of Unix.

/s/Unix/Bash or sh/ and I agree with your statement. I also note that Perl (
_shudder_ ) is conspicuously absent from your list. :)

> There's much more to it than that, I believe. For example, preserving quoted
> arguments is a nightmare.

Thanks for the examples! I'll go over them over the next couple of days and
see what I can learn from them. :D

> But I would bet that most developers don't even know that bash has first-
> class array support. (If you know a better solution,

Did you accidentally a sentence or two? Also, the recurring theme that I've
been spotting here has been "Programmers who don't know their language often
write bad or broken programs in that language.". Is this _not_ one of the
larger themes of your statements? :)

> Controlling SSH from scripts has always been painful and brittle for me.

Sorry, this is something that I've not yet had call to do. What exactly do you
mean by "controlling SSH from shell scripts"? Something like

    
    
       ssh user@host "someRemoteCommand $AND_A_SCRIPT_VAR_TOO"
    

embedded in your script? (Or the equivalent here-document?)

> As for "entire OS built on shell scripts", every Unix distro out there is
> built on tons of shell scripts.

That hardly means that the entire OS is built on shell scripts. I argue that
the vast majority of the shell scripts out there are to handle process
startup. While this is _quite_ important, it's important to remember that the
stuff that _actually_ gets work done in the OS is _very_ rarely written in
Bash.

> Erlang's duck typing means it's susceptible to sloppy inputs just like any
> other duck-typed language.

I see what you're saying (and agree with your final sentence), but one could
just as justifiably say

"C and C++'s ability to permit the programmer to override the specified type
of a given variable means that such programs are susceptible to errors of
sloppy logic. We should _really_ be using Haskell to write our system
management programming." ;)

Anyway. Thanks for the ongoing conversation. This has been quite informative.

~~~
lobster_johnson
Actually, you pointed me to Fcron, to which I countered that for Fcron to be
an satisfactory scheduler (that is, satisfactory to me) it would have to
become Systemd. I think I was pretty clear on that, actually.

No, I really did mean "historical sloppiness of _Unix_." It's a fine
foundation, circa 1985, but it's time to make some progress. For example (just
a minor example), the fact that Cron's error reporting is email is ridiculous.
This means that the only way to collect reports is to either use a mail
client, or to set up a special rule (in Postfix or whatever) that pipes
incoming mail to a special directory or a process. Both options are insane,
not to mention horribly brittle. Surely Cron violates the Unix principle (the
"do one thing well" one) here; the right thing would be to not support email
at all, but to mandate that every error report is piped through a per-job
command. So PIPETO rather than MAILTO. If you really want email, according to
the Unix principle, you just pipe to sendmail, after all. But a whole lot of
the traditional Unix toolset is weirdly crufty this way.

As for shell scripting, my original point was precisely that the shell
language family is very hard to get right, and so it's a poor foundation to
build complicated, resilient moving parts on top of, emphasis on "moving". The
situation is much worse than C; the _class_ of possible bugs is completely
different, and much more damaging. Things like process management should not
be done using shell scripting. Lots of things suffer from bad scripting;
autoconf, for example.

By controlling SSH: Yes, I mean interacting with SSH commands. You have to
cover a bunch of pitfalls: disabling tty, disabling the control master
multiplexing (has never been stable), always using heredocs, etc.

------
jrapdx3
Interestingly, FreeBSD is well along in resolving remaining issues such that
nosh can supplant the init/rc.d tools in use for ~15 years. See [0].

Haven't yet learned about nosh in detail. It does appear to be well thought
out, and obviously it's been around for quite a while reaching some state of
maturity. While I've not noticed particular difficulties with the current init
system in FBSD, my system is relatively straightforward. I can see how
dependency complications can arise in complex situations.

Given the notorious controversy over systemd, it's curious that at least some
Linux distributions haven't adopted nosh as an alternative to systemd. Perhaps
such distributions exist, though if so not well publicized.

[0]
[https://www.freebsd.org/news/status/report-2015-07-2015-09.h...](https://www.freebsd.org/news/status/report-2015-07-2015-09.html#The-
nosh-Project)

------
LukeShu
nosh is cool, but the "systemd compatibility" is for the systemctl command,
socket activation, and automatic unit file conversion; it doesn't offer
implementations of the systemd APIs, which is where "systemd compatibility" is
really needed.

~~~
pekk
Would there be any point of re-implementing all those APIs rather than using
systemd?

~~~
astine
Systemd cannot be used on the BSDs because it uses Linux kernel specific
features.

~~~
avar
I've just read that it uses a lot of Linux-specific things, but are there
features that inherently can't be ported to BSD? And are those features
absolutely critical to running it at all?

What I've read sounds more like "we're focusing on Linux, and won't be porting
it" rather than "this software is inherently Linux-only, and can't be ported".

I daresay coming up with a shimmy layer to port it to BSD is probably less
effort than completely rewriting it.

~~~
JoshTriplett
I like systemd, but I do think it'd be far easier to write a compatible system
for FreeBSD (or enhance the FreeBSD kernel to provide the necessary features)
than to port it. For instance, systemd fundamentally depends on cgroups;
without an equivalent mechanism, it won't work at all. The same goes for
dozens of other features. The necessary functionality doesn't exist in POSIX;
rather than attempting to write a half-functional "portable" implementation,
it would make more sense to embrace the FreeBSD kernel, use its features as
appropriate, and build a full-featured init system specifically for FreeBSD.
In an ideal world, that system would provide all the features of systemd.

(Note, for instance, that I said "FreeBSD", not "BSD"; portability is not
worth trying to enhance 3-4 kernels to support the features you need, or
sinking to the lowest common denominator.)

------
cm3
It's inspired by daemontools, AIX SRC, Solaris SMF, launchd and systemd.

------
JdeBP
Daniel J. Bernstein asked a question:

* [https://twitter.com/frioux/status/661348744604991488](https://twitter.com/frioux/status/661348744604991488)

For what it's worth, see what I wrote on the subject back in June:

* [https://www.mail-archive.com/supervision@list.skarnet.org/ms...](https://www.mail-archive.com/supervision@list.skarnet.org/msg00716.html)

------
ck2
BSD was supposed to be the chosen one, our last best hope for no systemd,
ever.

~~~
josh64
OpenIndiana will likely stick with the (excellent in my opinion) Solaris SMF.

~~~
skissane
I'd love to see a side-by-side comparison of systemd vs SMF. (I just searched
for one but could not find it.) I wonder if those Linux folks who are so anti-
systemd would feel the same way about SMF? When SMF came out, I don't remember
any of my Solaris sysadmin friends complaining about it, they all seemed
pretty excited.

~~~
dijit
As an originally Linux admin, and then a UNIX admin, and now back to Linux..

I liked SMF.. Fuck SystemD with a rake in the rain on a Monday.

SMF had a lot of improvements also after opensolaris died off and we were left
with openindiana.. the thing is, it didn't fly in the face of the current
system, logs were referred to not 'journaled' away, and it didn't try to
gobble up the networking stack at all, but it did allow the system to verify
networking ability.

it was very nice, and I regret not understanding it more.

Although I didn't like that it was XML, yaml,JSON or even INI would be
preferable in my mind.

~~~
gh02t
It sounds like you've had specific bad experiences with systemd, would you
mind sharing what they were? A lot of the criticisms I've seen of it were
philosophical and many hadn't actually ever used it, so I'm curious to hear
some practical complaints. Personally, I've been using it for a while and it's
been pretty good to me, so it is interesting to hear from people who have been
less fortunate.

I've also used SMF a bit and thought it was pretty decent.

~~~
dijit
mostly in the logging, it's hard to get anything truly meaningful when shit
hits the fan, I even studied the man pages fairly religiously but because the
native application had it's own logging mechanism which was removed by the
distro maintainer/packager (fedora) it took a while to realise and reenable.
this is the first listed not because it's a big deal but it cost me a day of
work, which is hard to explain to my boss.

There are multiple issues in how it handles networking, notably that 802.3a/d
bonding is kinda broken and nobody seems to give a crap, which means using it
in production is somewhat dangerous for me, the same way that loading modules
breaks, gets fixed then rebreaks in odd ways (lsmod/modprobe)

the fact that nobody seems to give a crap about the previous bug, and that
bugs get introduced and the developers hostile attitude also rubs me wrong.

FirewallD is a shitshow, and yes it _can_ be disabled, but that doesn't mean
that it's -not- going to be the officially supported method of interfacing
with netfilter in the kernel.

I've had systems become unbootable because systemd introduced a bug which
caused it to segfault and I couldn't "revert" the change like I would with a
bad kernel, but this is the cloud era and I should really be adopting
ephemeral builds- but if it ever happened on a stageful machine I'd be angry,
I can HA all I want but I want to be able to recover and more robustness is
significantly better than less.

My problems are fewer because I never wanted to touch systemd, I've been
skeptical and rewarded somewhat for my skepticism when i actually started
using it out of curiosity or because I really hate being on the previous
version of a thing.

Actually, what I really hate most is not the issues I've had, new systems
often have warts and we should encourage discussion to get them fixed.. not
shut them down when problems are shown because there _are_ problems.. my issue
is how under-represented other init systems are, I didn't like systemd and was
basically told (by developers, mostly) to "suck it up" and to stop "getting in
the way of progress", and while I've never tried to defend sysVinit, I was
always keen to have a discussion about a _well engineered_ solution to this
would be.. somehow SystemD has taken over and it's more windowsy than we
imagined and growing daily.. it even has a bootloader now.

Nosh is a cleaner implemented init system and so is SMF, they fix a problem
and do so well..

systemd works great on my laptop though! (arch linux)

~~~
jononor
Got some links to the 802.3a/d bonding issues?

~~~
dijit
[https://github.com/systemd/systemd/issues/599](https://github.com/systemd/systemd/issues/599)

similar bug;
[https://github.com/coreos/bugs/issues/298](https://github.com/coreos/bugs/issues/298)

and when it _does_ get configured (after boot) it has a tendency to drop
packets.

[http://unix.stackexchange.com/questions/235474/random-
packet...](http://unix.stackexchange.com/questions/235474/random-packet-loss-
with-bonded-interfaces)

