GNU Shepherd | Hacker News Reader

GNU Shepherd

gnu.org

185 pointscyphar122 comments

There are many amazing GNU projects. Just yesterday I found out about GNU radio. I also remember reading the initial commit for Gneural and thinking "wow, this code is really nice".

I think GNU deserves much more support then it's getting.

How does something become an official project under the umbrella of GNU, other than adopting a GPL? I'm guessing the FSF somehow curates and leads the individual efforts, before it can be called "GNU $THING"?

Happened to come across a thread discussing this when OpenCobol transitioned to GNU Cobol (https://sourceforge.net/p/open-cobol/discussion/cobol/thread...)

It appears that you write to FSF and write out an evaluation proposal.

https://www.gnu.org/help/evaluation.html ← how to add your project to GNU

As others have said, you have to apply to the FSF to become a GNU project. And while being under GPLv3-or-later is one of the requirements, I just want to clarify something on this point:

> other than adopting a GPL

Despite it's name, the GNU General Public License is a license for any software written by anyone. Licensing something under the GPL doesn't make your project a member of the GNU project, any more than licensing something with the MIT/X11 license make your project part of FreeDesktop, or BSD making your project one of Berkley's projects.

There are so many awesome projects, but one that I recently learned about is GNU Taler. Basically it's an attempt to make "socially responsible digital cash", where all customers' transactions are private (you cannot tell who bought what or link their purchase history) but you can audit vendors and mints to verify that they pay taxes.

It's quite an elegant system and strikes the right balance (in my mind) between privacy and accountability for corporations. Also it piggy-backs on existing systems (operating through exchanges) and doesn't require proof-of-work. And the browser extensions are super easy to use (even easier than Flattr in some ways).

> I think GNU deserves much more support then it's getting.

I would recommend donating money to the FSF (if you have the means) and becoming a member. They are an incredible project doing awesome work and deserve the support. You also get free access to LibrePlanet conferences and a few other perks.

A service file looks like this:

  (register-services
    (make <service>
          #:provides '(apache-2.0 apache httpd)
          #:requires '()
          #:start (...)
          #:stop (...)
          #:actions (make-actions
                     (reload-modules (...))
                     (restart (...)))))

It not horrible, but I'm Not a huge fan of that, but maybe it will get much better as it matures.

Much better than XML. A proper and simple language, not just a stupid bloated datastructure, with the ability to naturally define logic in the deps.

reminds me of emacs config file, john wiegley made a tiny dsl called use-package that made everything cuter by a few simplification here and there. A few iteration it became extremely nice to write and read.

Remember the Emacs config file is not a configuration file: it is actually a program that's run as Emacs starts. You can do all sorts of interesting stuff (like installing missing packages, setting font size according to the screen, etc) on it.

Well config vs program is a deep debate. Now J.Wiegley extension brings some resemblance of semantics because it has a few concepts and steps instead of free form imperative (setq ...)

I love use-package, has made my emacs init.el config file sooooo much more maintainable from its prior... lets just say mess.

Some people, smart and famous, still use vanilla emacs config/loading mechanisms (ensuring lazy loading).

I now use req-package so I don't even have to download anything.

I do miss the old style of one file per "kind" though. Doesn't mean use-package is bad but somehow I like having a FS-level idea of my emacs config.

I'm one of those weirdos that sticks my config into org mode files too.

https://github.com/mitchty/dotfiles/blob/master/emacs.org

(actually i use org mode to compile all of my dot files based on predicates, i'm double plus weird here >.<)

I really rather like this way of working with things as it just sticks stuff into ~/.emacs.d/elpa. I can rsync that around if i need/want. And it even bootstraps itself if i'm opening things on a new system. I just like keeping each package in its own use-package declaration so I can have config+setup all in one spot.

I planned to do that too. Having a readable.. even story tellable code instead of a too succint result of brain sweat.

I might try to make one from scratch using yours as an inspiration. Just to see how my mindset evolved along the years.

Go for it, its mostly inspired from nix in how I set it up. I can just run make and create dot files for whatever I need then rsync it over to where I need it.

Aka I can customize my dot files based on if i'm going to a bsd/mac/linux box with(out)/nix/perl/haskell/git/whatever and have an easy way to copy things over the top of things or not.

I declared dot file bankruptcy a few years ago and this is my "perpetual penultimate dot file solution" (yes I'm making a joke at my own expense with penultimate here).

But this new setup is easily the most sane I've found so far. Most dot file management uses softlinks which sucks for rsyncing, or some hokey templating language.

All mine amounts to is just a stupid .el file that holds predicate definitions that just controls via stupid elisp when an org babel block gets tangled out into a file. Its pretty simple and straightforward. Wonder if I should do some sort of show and tell for it or not.

Good luck! Hope it helps or inspires something better.

I find it quite comfortable actually. Same goes for all of Guix.

I'm curious. Why are you not a huge fan of it?

My first thought is how I'd parse, modify and write it back without losing user's comments, formatting, changes and suchlike. Is this some well understood format with libraries for common programming languages? If not, it is just likely to proliferate more crappy config management with chunks of regexes and suchlike

Elsewhere people are saying it's just Scheme. I'm sure I could find a parser for that in Python, and maybe if I'm really lucky that parser will record whitespace and comment nodes, and have a reverse transformation, but do I really want to be writing error prone 20-line AST visitors just to tweak an integer setting? (No, I most certainly do not, and I consider design decisions like this a massive code smell that'd ward me off any further investigation of a system)

edit: downvotes? Is this really such a difficult concept?

edit 2: so apparently the big whoopsie was insulting the religion that is LISP. Yes, using a turing complete language for config syntax causes pain. Nobody does this stuff in the real world for a reason. Deal with it, meanwhile go back to obsessing over novelty code-is-data academic exercises on your obsolete Symbolics machines, you'll cause less damage that way.

It's Guile s-expressions, so at least there's a good C reader and writer?

You would just use Guile. That's the magic of the Lisp family.

Edit: downvotes are because you're sort of insulting Lisp (which is older than you and all your "best practices") with an ignorant complaint.

>> downvotes are because you're sort of insulting Lisp (which is older than you and all your "best practices") with an ignorant complaint.

I recognized it as lisp right away, but I share the complaint about the format. If you want to write a lisp program then do so. If you want to format something for human readability it's probably a good idea to do it differently. This is just a opinion of course, but I suspect it's not an uncommon one.

Maybe uncommon over all, but you should definitely expect the GNU project to use Guile for scripting needs. In this context, it's the obvious choice.

Furthermore, anything that tricks you into learning Scheme is a good thing. Like eating vegetables.

Are you suggesting that Lisp programs aren't readable by humans?

So all I asked is whether it was possible to roundtrip an edit to one of these files from Python without writing an AST visitor, and without losing formatting and comments. I have absolutely no idea how this could be considered ignorant.

Ignorant of the cave-dwelling depths some would go to ensure the practicality of the arcane religious icon that is LISP as a massively overgeneral solution to a problem, at the cost of all downstream users who must now "just switch to Guile" or link against chunks of a C compiler just to introspect a config? Maybe, but I'm content with that.

So the example you showed with XML uses XPath, what do you think that does? I am sure something similar can be created in python for editing lisp code as easily as this.

> My first thought is how I'd parse, modify and write it back without losing user's comments, formatting, changes and suchlike. Is this some well understood format with libraries for common programming languages? If not, it is just likely to proliferate more crappy config management with chunks of regexes and suchlike

> Elsewhere people are saying it's just Scheme. I'm sure I could find a parser for that in Python, and maybe if I'm really lucky that parser will record whitespace and comment nodes, and have a reverse transformation, but do I really want to be writing error prone 20-line AST visitors just to tweak an integer setting? (No, I most certainly do not, and I consider design decisions like this a massive code smell that'd ward me off any further investigation of a system)

XML satisfies all the above: no AST visitors, no custom parsing routines, no attempting to solve the halting problem in order to introspect a simple scalar value.

What you're saying is that the same is "possible" with Scheme. At least one followup comment (finally) described an algorithm that would actually allow machine-driven file changes, but we're still left with rather than a working out of the box solution, a description of an algorithm that "might someday work" and that's not the sort of thing I want to be dealing with while building business solutions on somebody else's dime, which drives my conclusion above: this config file syntax is not for me, and my original comment explained precisely why.

You're complaining that there isn't good tooling around the config file format for a project that is described as "in its early development stages" and provides "alpha releases". If you're talking about using this "while building business solutions on somebody else's dime" your getting way ahead of yourself. I'm sure they will expose a library for parsing and editing the config format before a general release.

It's Scheme s-expressions. Parsers for it have existed for it longer than C or Unix have existed (Scheme came out in 1970, First Edition Unix in 1971), let alone Lisp parsers which have existed for even longer.

EDIT: Complaining about downvotes and then going on a tirade about how Lisp users are cave-dwellers is not constructive. Personally I think your argument was a valid concern (and I just went to try to find a Scheme parser in Python to help you), but you're not helping your case.

Also, like it or not, but both of the most widely-used editors (emacs and vim) both have turing-complete "configuration" languages. By your statements, that would make the majority of programmers academic cave-dwellers (oh wait... :P).

> both of the most widely-used editors (emacs and vim)

https://insights.stackoverflow.com/survey/2017#technology-mo...

If you include full-blown IDEs in your definition of editor (which I think you should), Visual Studio was the most widely used editor among all the 19,772 people that responded to this question in the Stack Overflow Developer survey 2017.

Notepad++ was the second-most popular editor.

Sublime Text was the third-most popular editor.

Vim was the fourth-most popular editor.

Visual Studio Code, IntelliJ, Atom, Eclipse, Android Studio, PHPStorm, Xcode, NetBeans and PyCharm followed.

Emacs was the 14th-most popular editor.

The point still stands if you substitute "both" with "two". I admit that I assumed Emacs and Vim were higher in the "leaderboard" (and I'm not sure StackOverflow is the best place to sample developers) but the point stands regardless.

As others have pointed out, it's s-expressions (and possibly simply scheme) so reading and writing shouldn't be difficult. If it uses scheme comments, those will be a problem just as when transforming any programming language. I the other hand, if they syntax supports doc-strings, you're all set.

Add far as AST visitors, you're probably better off with XPath/XSLT tree transformations. (Anyone know of a suitable library?)

On the other hand, the don't-swim-upstream approach would be to use one of the best programming languages in existence, Scheme, you do your config management tasks directly, rather than an arm's-length parse, modify, write approach.

> using a turing complete language for config syntax causes pain

That may sometimes be so, but only as a general consequence of "programming computers causes pain". You can do something complicated, which can have a bug; then someone comes along with a half-conceived thought like, "that solution shouldn't have been doble in the config language; therefore config language caused pain".

A non-computational config language also causes pain. Sometimes to the point that a Turing-complete language is used to generate a configuration. Then you have pains like "# this was generated ... don't touch!".

I have no dog in this fight, but I downvoted because your subsequent edits are not at all constructive.

So, since nobody mentioned that, i'll ignore your edits and try to answer your original concern. Generally speaking, this is S-Expressions (as others have said) and S-Expressions are trivial to parse and edit - you can write a parser in C that converts this to a tree easily. Note that the comments and such are a problem regardless of the config syntax used but the solution is the same: instead of rewriting the file, edit it in-place (to do that a simple way is store the index range of each node's value in the code buffer when parsing it and when you modify the node's value update the buffer's contents - make sure you also update the other nodes' ranges if the value changes length in characters).

All these assuming you want to implement the thing yourself. Which is fine, S-Expressions are one of the easiest tree syntaxes to parse. But there are already libraries that can do this for you (including full Lisp/Scheme interpreters) and some of them can even 'pretty format' the code like the quoted snipped above.

So generally speaking this wont be a problem in practice.

So you want to programmatically edit a config file, preserving formatting and comments, without using regexes, AST visitors, or XSLT? What's left? I seriously don't know of any other ways to manipulate data while preserving formatting and comments.

    $ cat my-config.xml
    <root>
        <!-- i am a comment -->
        <thing attr="foo">
            <!-- i am another comment -->
            <setting>value</setting>
        </thing>
    </root>
    
    $ cat c.py
    import lxml.etree
    
    doc = lxml.etree.fromstring(file('my-config.xml').read())
    for setting in doc.xpath('.//thing/setting'):
        setting.text = 'set without screwing up the file'
    print lxml.etree.tostring(doc)
    
    $ python c.py
    <root>
        <!-- i am a comment -->
        <thing attr="foo">
            <!-- i am another comment -->
            <setting>set without screwing up the file</setting>
        </thing>
    </root>

... but you just chewed someone out for suggesting XML. And you are doing tree walking here, you're just reducing some of the boilerplate with XPath. You can do the same thing with Scheme using car, cdr, cadr and friends.

The suggestion was to use XSLT to transform Scheme syntax

My mistake then. You can still use car, cdr, cadr etc. to accomplish more or less the same thing as XPath. S-expressions are a completely valid serialization format. You can't easily manipulate JSON or YAML data while preserving formatting and comments with any library I've used (though it is possible), that doesn't mean JSON and YAML are invalid.

XPath and a tree transformation? Works well.

This isn't applicable to scheme as a config format, but some config formats are line based and have programmatic tools to manipulate them, e.g. the .ini-like format Git uses, try adding some comments to ~/.gitconfig and manipulating it with `git config --global <...>`, it'll all be preserved.

You will lose any comments like this though:

    [user]
        name = My Name ; that's my name!

Programming is hard in the face of arbitrary user data.

My first question would be in what use case do you require the ability to alter via a program the same config file that you expect the user to be able to hand edit and never have a conflict?

It was my understanding that issue was best handled by having multiple files and having one take precedence over the other. Like having a global config that is pushed to the machine and allowing the user to locally override values set globally in the local config.

Another solution to multiple parties needing to define configuration for the same area without stomping all over each other would be to have a directory wherein all files contained therein are applicable. That way multiple people can maintain their own particular files but some precedence has to be established.

Even if you do need to do this I wouldn't think it would be that hard to modify lisp with lisp.

Regarding edit 2: Using a non turing complete language results in hacks to attain the flexibility that would have been provided by the more powerful language.

And that was kind of the whole point with GuixSD and Shepard.

Nix has limited "Nix-expressions" which resulted in a bunch of bash scripts to get around the limitations, and Systemd ends up requiring C services or bash scripts because it has a limited INI-like syntax. On the opposite end, GuixSD is entirely configured, packaged, and maintained with Guile.

It may be stupid but that syntax makes me feel a little uneasy. The unmatched single quotes reminds me of TemplateHaskell.

Single quote denotes a symbol in scheme. But this snippest is not strictly scheme. Perhaps it is SXML but I am not familiar with it.

While I don't write Scheme, I believe it is Scheme -- one of the goals of the GNU project is to have every GNU tool be configurable with Scheme (which is why GNU has a Scheme implementation as opposed to a Common LISP implementation).

Not only does GNU have a Common Lisp implementation, in fact there are two:

GCL: https://www.gnu.org/software/gcl/

CLISP: http://clisp.org/

I've installed CLISP before, why didn't I know it was a GNU project? Fair enough, I stand corrected. :D

Well, they have GCL and CLisp too!

This is just Scheme. It's nothing to do with SXML.

#:foo is a keyword argument and '(apache httpd) is a quoted list containing the symbols apache and httpd.

Angled brackets have no special meaning, they are just part of the identifier.

A single quote is actually shorthand for the quote special form

  'foo
  (quote foo)
  '(1 2 3)
  (quote (1 2 3))

It basically does not evaluate its arguments but returns whatever it is. So instead of the value of foo, it the symbol foo. The list example does not evaluate it either, it would normally try to apply the first element as a function, but instead we get the list of numbers.

Template Haskell (and Rust) gets this from Lisp, ultimately.

Rust's usage of single quotes comes from CS language theory (lifetimes are denoted using quotes) which I believe comes from the normal usage of quotes in possessive words (James', Amanda's). I don't think LISP's usage comes from the same place (it means something very different semantically).

Lisp's quote (or ') comes from the word quote and the context:

  (quote something)

Meaning: take whatever follows and leave it alone. Do not interpret it. If it's a list it stays a list (one of the main uses for this). The single quote ' is shorthand for that. It's meant to be an easier way to create a literal list (and other things) without escaping all the parts of a list that might be misinterpreted as symbols to evaluate (to values or functions).

OCaml's usually what I see cited as the reason for Rust adopting the syntax.

... where it's a type variable.

I think we can blame the use for lifetimes entirely on the Rusties.

Lifetimes are also types, or more specifically, generic type parameters.

I believe the community name is Rustacean[1].

[1]: http://www.rustaceans.org/

That's a mere function call in a complete, standards based language.

Here is a complete (and simpler) example, taken from my ~/.config/shepherd/init.scm:

  (define xscreensaver (make <service>
                         #:provides '(xscreensaver)
                         #:start (make-forkexec-constructor
                                  (list "/run/setuid-programs/xscreensaver" "-nosplash"))
                         #:stop (make-kill-destructor)))
  (register-services xscreensaver)

Any reason for the fugly #: syntax? That's mandated by Guile?

They're keyword arguments, I suspect the #: prefix was chose precisely because it is ugly so it'll almost never conflict with a name a programmer might actually want to give as an argument, Racket uses it too. http://docs.racket-lang.org/guide/keywords.html

The # is extensible reader syntax. You can install your own readers for characters following the #. #\ is for the character reader, #: for keywords, etc.

Guix uses #~ for G-expressions, for example.

Thanks for providing the link to the documentation in Racket. For people like me who don't know how to program in Scheme, this quote from the documentation might make it click (it is at the end of the page):

Despite their similarities, keywords are used in a different way than identifiers or symbols. Keywords are intended for use (unquoted) as special markers in argument lists and in certain syntactic forms. For run-time flags and enumerations, use symbols instead of keywords. The example below illustrates the distinct roles of keywords and symbols.

Examples:

    > (define dir (find-system-path 'temp-dir)) ; not '#:temp-dir
    > (with-output-to-file (build-path dir "stuff.txt")
        (lambda () (printf "example\n"))
        ; optional #:mode argument can be 'text or 'binary
        #:mode 'text
        ; optional #:exists argument can be 'replace, 'truncate, ...
        #:exists 'replace)

It's pretty close to "horrible" though.

"A service file looks like this:"

Am I correct that the equivalent to this service file, in the world of systemd, is a binary file ?

You are incorrect. Systems uses plaintext 'ini'-ish files.

No; the format is text: http://0pointer.de/public/systemd-man/systemd.unit.html

Maybe an example is easier to read than a manpage. Here's nginx.service from Arch Linux: https://git.archlinux.org/svntogit/packages.git/tree/trunk/s...

And I personally love it. When writing my own servers/daemons I can very quickly and easily write a new service file for it.

I can appreciate how holistic the GNU ecosystem seems to be. I'm a lover and user of Nix, so whenever something about Guix comes up, I draw the contrast. In this case, GuixSD is using Shepherd, which uses Guile for configuration and feels like natural continuity within the system. NixOS, on the other hand, provides systemd (and only systemd). In the case of nix, it's smart to leverage existing technologies, for velocity, yes, but also as a sort of proof that the core principles behind nix can apply even over systems and tools that are completely unaware of nix concepts; on the other hand, GNU really makes me a believer in the fact that Guix is very pure.

How do they keep eye on all the processes for a service. They don't seem to use namespaces.

In what way don't they use namespaces? It's object oriented using a lisp system (hence arbitrary macro support for lexical and dynamic scoping). Each service object would track its own processes.

I assume gp meant "Linux kernel namespaces" not namespaces for the code?

GuixSD supports this:

https://www.gnu.org/software/guix/news/running-system-servic...

This is not part of GNU Shepherd.

I'm trying to read the code now. I'm not sure whether I do or don't want them to use cgroups. Anything is better than using ptrace.

Aren't cgroups a Linux thing? Don't know if Hurd has them.

Cgroups are just an API. I think there was an effort to add a translator for them on top of the Hurd, possibly as a Summer of Code project.

GNU Shepherd works on GNU/Linux as well as GNU/Hurd. The problem is that Linux doesn't really have any sane way of tracking double-forked processes. A misuse of the cgroup API is to do that (and I do mean misuse, reading cgroups.proc is not atomic and will cause repetitions and dropped entries if you read more than a single page of data). But that's still better than using ptrace's POSIX-breaking pseudo-parent semantics (see Upstart, though they apparently switched to using the proc connector API which is sort of like ptrace-lite).

I would presume they'd separate out that particular detail into separate modules.

I don't know what they use. I do know that you can use the proc events over "connector" to get all the forks and execs. That is how I would do it.

For those too lazy to click the link

> The GNU Daemon Shepherd or GNU Shepherd, formerly known as GNU dmd

dmd was short for "daemon management daemon". Basically, it's what powers all services running on GNU Guix instead of something else, like systemd.

I think this new name may sound "friendlier", but at the cost of precision. I immediately realized what dmd would be, but I had no idea what GNU Shepherd would be about.

Daemon managing daemons, actually. Also note that Guix is technically just the package manager - the distro is called GuixSD.

It will be interesting to see if we can use this in linux with minimal changes to the test if the system

(I am looking at you systemd)

It's already used in Guix, that is a GNU/Linux distribution, so why not?

Actually, it's used in GuixSD, the GNU system variant built on top of Guix.

Oh come on. And what's the kernel for GuixSD? Linux.

We all know RMS is bitter that he can't take credit for a functional kernel, but it's still there.

I don't know what exasperates you so much to justify a comment like this. My point is that it's "GuixSD", not "Guix" that uses the Shepherd.

I happen to call the system I work with and hack on "GNU", not "Linux". That's just a different perspective.

And I'm not RMS, nor am I bitter. I find your comment very confusing and confused.

The difference between Guix and GuixSD isn't about alternative names for the same thing (like whether e.g. Ubuntu is "Linux" or "GNU/Linux"). Instead these names describe two distinct, but related, software projects.

Guix is a collection of programs for building, installing and distributing software (or other digital artefacts). It is specifically designed to work alongside alternatives, like apt, yum, etc. on many operating systems.

GuixSD is a particular OS distro, which uses Guix for all of its packaging, etc. If you use GuixSD, you're going all-in on Guix for everything.

The distinction between these projects is important, since Guix might be a good engineering choice for some project (say, a Web site backend, requiring particular versions of Apache, Python, various modules, etc.), whilst it may be a bad idea to switch the whole underlying OS to GuixSD.

As a concrete example, I've not used Guix or GuixSD myself, but exactly the same distinction exists between Nix and NixOS. I personally use NixOS, and I include Nix configurations in my own projects, so others can use Nix to install them with all of the right dependencies, etc. They don't need to switch distro to NixOS though; Nix will work on whatever system they already use (e.g. Ubuntu, OSX, etc. Though not yet Windows).

You call your OS Linux, RMS calls it GNU, I call it Bash, my wife calls it XFCE, her granma calls it "that one with the blue mouse" (and uses it without a problem).

But I really think that the name should be Bash, because that's what holds it all together.

> Oh come on. And what's the kernel for GuixSD? Linux.

They called you out on a minor mistake: Guix being a package-manger of sorts and GuixSD being a Linux distro (built on Guix).

And Guix doesn't run anything like dmd or systemd. GuixSD does.

It's not a big deal though. Honest mistake to make.

I'm the one who said Guix instead of GuixSD, I'm a different person than the one who made the comment about Linux and RMS.

Yup, my bad. I've always called the distro just Guix in my mind, but I know the difference.

Anyway, thanks for pointing that out.

So is this GNU/systemd?

It's the exact opposite, it's an init system for the GNU project.

Much closer to a GNU/Upstart. Doesn't try to do much more than manage services, from the looks of it.

This is init, with the exceptional property that you write your scripts in Guile Scheme (an implementation of a standardised Lisp dialect). That should allow for a more robust and debuggable way to write init scripts.

GuixSD is kind of immature at the moment, and I have driver issues with linux-libre, but in the coming weeks I'll have the time to try to run it with a custom kernel that supports my hardware. If I succeed, as an Emacs user it'll become turtles all the way for me, which is very exciting (GuixSD is Guix + Shepherd + GNU + Linux Libre).

"kind of immature" is a bit vague, but I disagree. I'm using GuixSD on almost all of my machines (a server, two laptops, an audio workstation) without problems.

It is quite easy to overwrite the kernel package to use in a system configuration (e.g. to use a kernel with the RT patches applied), but I should say that I use the default kernel on all but one machine.

Kinda odd they ever called it dmd at all considering that's the name of the official D compiler.

Not so odd considering that Shepherd was started in the year 2002 and the D language appeared at the end of 2001.

That makes more sense to me, I was not aware of the history of Shepherd. Funnily enough they changed the name to avoid this very confusion in 2016.

That's because the D language people asked for a name change then. The Shepherd was actually a dormant project for many years until it was revived for GuixSD.

Would it be a suitable replacement for supervisord in containers?

Most likely. It can even run as an unprivileged user (and users can manage their own daemons with it).

Though in most cases I find that people just want the "zombie problem" to go away. I wrote a simple init[1] that implements all of the key pieces of an init and signal forwarder.

[1]: https://github.com/cyphar/initrs

I see you mentioned tini (another such init) in the README as being "not as simple as it should be". We're using https://github.com/Yelp/dumb-init at work; if you know it, what do you think of it?

dumb-init is better, but they don't use socketfd which means they might drop signals in certain cases (in the race between consecutive sigwaits). I will concede this is a minor point, and I still have to finish implementing all of the necessary signal semantics in initrs, but it is kinda important.

Also I'm learning Rust and it was a good opportunity to practice by implementing something I already knew how to easily do in C.

Any reason you didn't go with something like dumb-init[1]?

[1] https://github.com/Yelp/dumb-init

See https://news.ycombinator.com/item?id=14478725

I'm waiting for the same. Supervisord seems to be dead project now, without any releases since the last 10 months or so.

I'm not sure what their release process looks like, but the Github for supervisor seems reasonably active: https://github.com/Supervisor/supervisor

Sadly it doesn't seem to play well when run under Python 3. Not a big deal now, but hopefully one of these years, desktop Linux distributions will have a 3.x release of Python as the default.

how compares against SystemD kraken ?

Reply on news.ycombinator.com