Except it's... not quite correct. getent performs NSS resolution, not DNS resolution, so its output depends on the value of the hosts field in your /etc/nsswitch.conf, which could be set to something fun like LDAP or something else.
I don't know Kubernetes, so it's very possible that Kubernetes enforces that name resolution is always DNS and only DNS (a "hosts: dns" line in /etc/nsswitch.conf, without any additional stuff like files which would mean resolution via /etc/hosts), in which case getent is indeed correct, but in the general case, there is no system-intrinsic tool that tests DNS only, and you have to use something like dig.
Not at all. I'm referring to the structure of the Alpine packaging, especially around boot scripts, that hardcodes busybox in a number of places and makes it difficult to package an alternative without workarounds - which accumulates tech debt.
And if you look under the hood, you will see that it's only possible because of a bunch of ad-hoc hacks, which is exactly what my proposal was about: level the playing field and make it possible to have alternatives _without_ the ad-hoc hacks.
"Avoiding spinning up new processes" is incorrect characterization of s6. Processes are not a scarce resource; spawning a process is not a costly operation in the context of process supervision, even on embedded systems. s6 focuses on optimizing some metrics that are indeed important to embedded systems, like RAM use and code path length, but "spinning up new processes" isn't one of these metrics.
It is not, and has never been, necessary to learn execline, the scripting language you're speaking of, in order to use s6. execline is used _internally_, and you can also use it in your own scripts if you so choose, but it is not a requirement.
"Sending a polite shutdown signal, waiting for some time, and sending a harsher shutdown signal" is a matter of exactly one command: s6-svc -d. That is precisely one of the benefits of s6 over other daemontools-style supervisors: it handles this sequence natively.
I welcome fact-based criticism of s6. I do not welcome FUD-based criticism.
There is no good solution for servers that, mistakenly, background themselves; the practice of backgrounding itself comes from a time where supervision was not as widely known as it is today, and nowadays there is no excuse for a daemon to fail to at least provide an option to avoid backgrounding itself.
The best thing to do is to contact the daemon's authors and insist they change that. In nginx's case, they think it's ok if they perform their own supervision, but it would be nice if they also could integrate with existing supervision systems.
In the meantime, as a workaround, the accepted practice for supervising forking daemons is known as "fghack": maintaining a process keeping track of the forking daemons via a few pipes that close when the daemons die. s6, for instance, provides such a tool: https://skarnet.org/software/s6/s6-fghack.html . AFAIK, so does nosh.
You need to read the archives of the supervision mailing-list at list.skarnet.org, as well as http://skarnet.org/software/s6/overview.html - there is a lot of value in process supervision, it's just that most people who whip up their own solution end up doing it wrong. Like crypto, in a less dramatically noticeable way.
I agree with Jonathan on everything here, with the additional caveat that the Go runtime is particularly heavy, and thus not really suitable for low-level system software (which should use resources sparingly, leaving them for production applications). So I don't think Go is a suitable language choice for a supervisor in the first place; and apart from the language choice, all of Jonathan's criticism applys.
I strongly recommend the author of immortal to join the supervision mailing-list on skarnet.org, follow the discussions there and ask questions if needed. We have about 19 years of experience with process supervision, there has been a lot of prior art and successive refinements, and we hold extensive knowledge about what constitutes good practice. If someone aims to design a process supervisor, even if it's a completely new take with a specific spin, it would be a mistake not to tap into our pool of experience. We always want users to benefit from good, rigorous software.
Still in active development too. :) And no, Jonathan, I haven't heard anything from TrueOS people.
Which is a shame, because if a distribution is being built today, with no existing legacy service script base to cater to (or if it has to be converted anyway), going for anything else than s6 or nosh is staying in the past.
I see nothing there that can't be achieved by a simple supervision suite. s6, nosh, even runit provide those features; the extra complexity of systemd isn't needed at all.
If even embedded developers are getting pulled in by the sirens of systemd because OH MY GOSH IT HAS WATCHDOG CAPABILITIES, then we definitely need to work more on raising awareness about supervision.
Honestly, the people who use Busybox are probably aware of the problems - political as well as technical - with systemd, and most likely not using systemd in the first place because it's not exactly a good choice for embedded systems.
Also, for busybox syslogd, it does not matter at all whether you can hold its socket. syslog isn't a reliable mechanism anyway, and busybox is light enough that the non-ready period is really short.
So, on the technical side, the impact is quite minimal.
On the political side, however, it looks like Denys made a splash, and I'm not going to complain about it. :)
But how would you go with restoring such an image? It won't be instant, there will still be a window where the service manager is continuing its work but the image hasn't been restored yet. One way or the other, you need a synchronization mechanism, so how would you design such a mechanism without support from the daemon?
You don't need a complicated case to have a race with acquiring some resource. A server opening a socket is providing a resource; clients connecting to that socket are using it. Clients should not be started before the server is listening to the socket. How would you solve this case - are you advocating socket activation by the service manager? ;)
You seem to dislike the idea of asking for notification support in the daemons themselves. Granted, it's impractical, but it's the only way to avoid race conditions which are rare for most services, but very real for a few programs that may take ages to get ready.
How would you address the problem of slow starters without support from the daemons, while keeping a "the dependency graph is always respected" invariant?
It's important to realize that "a replacement for systemd" is neither achievable nor desirable.
systemd has grown fast and conquered large market shares because it was backed up by a company, which put a lot of money and manpower into it - to write it, to integrate it, to advertise it. The only thing that has not been correctly funded in systemd is research and design.
systemd is only Open Source if you read the license; all its other aspects are proprietary - it's software made by a company and aiming to capture a market. It is impossible to compete with systemd on the same grounds, because no real Open Source developers will have as many resources as Red Hat.
And even if it was possible, the result of such an attempt would simply be another integrated behemoth, powered by money and marketing instead of good technical decisions. (Or even worse, powered by ideology - can you imagine a systemd-like controlled by the FSF?) In the end, the situation for the users would be even worse than it is today. You don't fight Goliath with Goliath; you don't fight Microsoft's hegemony by buying Apple products.
About interface compatibility: the author of the DnE article (vezzy-fnord) has written uselessd, and finally abandoned the project because the systemd interfaces are so tightly integrated with the systemd design in the first place that it's impossible to be compatible without simply being a systemd clone, which he did not want uselessd to be. No, interface compatibility is not an option, because it would simply acknowledge the validity and superiority of the systemd architecture, and nobody wants a copy of systemd.
I believe that the way to provide an alternative to systemd is to provide all the functionality that the systemd users like, but in a technically better, less integrated, more unixish way.
With s6, s6-linux-init and s6-rc, I now have respectively a process supervision system, a simple init process and a service manager, which should be sufficient for a majority of applications. The next important thing that sysadmins like in systemd seems to be cgroup management, so I'd like to study the thing soon and assess what needs to be done next; but for now, I believe that the s6 family of programs is now viable as a serious alternative to systemd, and I would love to give it a broader audience.
As Jonathan said: the reason for the compilation phase is efficiency. The information in the compiled database is organized for fast loading and immediate access to the complete dependency tree.
And yes, efficiency is important. The point of s6-rc is to provide a dependency-based system manager with minimal overhead. Time a s6-rc run against an equivalent openrc run, and you will see a notable difference. strace both runs and you will understand why: OpenRC performs all its dependency analysis at run time, every time you run a script, and it has to read the whole database of scripts to do so. s6-rc performs the "read a zillion scripts, do the dependency analysis" part only once, and offline.
There are also other benefits: for instance, simple checking - when you write an invalid set of services, the error is detected at compile-time, not at run-time when it could prevent your machine from properly booting.
The database format is not proprietary. It's undocumented, which is not the same thing; and if people insist, I may document it. In the meantime, the code that reads it is in src/libs6rc/s6rc_db_read.c, a function that you can use in your own code, or that you can analyze to understand the format. It's not a complex one.
Going out of sync is not specific to s6-rc. It's a risk as soon as you compile something. It may happen with OpenRC too, if you forget to rc-update. It may happen with your binaries, if you forget to make install. "Things may go out of sync" is not an argument against compiled designs, it's an argument in favour of paying a little attention.
Yes, that was exactly the idea behind s6-fdholder-daemon: set up a central server to keep fds open when you need to restart a process. The old process stores the fd into the fdholder, then dies; the supervisor starts the new process, that retrieves the fd from the fdholder, and starts serving.
And if you don't want to use a supervisor or a fdholder, you don't even need to coordinate, and you never need to fork: simply re-exec your executable with your serving socket in a conventional place (stdin is good). Daemons should be able to take a preopened listening socket and serve on it; hot-restarting is then a simple matter of one execve(). There's really no reason to make it more complicated.
Note that:
- You do not have to follow the slashpackage convention to use or build s6. You can configure it out.
- You do not have to write your init scripts in execline. Any scripting language, including the shell, will do; I use execline because it allows me to do things /bin/sh does not, or not easily.
- There is a mailing-list, [email protected], dedicated to software like s6 and runit. If you have trouble building, installing or using such software, please subscribe and ask for help. I'm absolutely willing to make s6 easier to use, but I need the feedback.
Thanks for giving s6 a chance! You won't be disappointed - and if you are, make sure to let me know why.
I don't know Kubernetes, so it's very possible that Kubernetes enforces that name resolution is always DNS and only DNS (a "hosts: dns" line in /etc/nsswitch.conf, without any additional stuff like files which would mean resolution via /etc/hosts), in which case getent is indeed correct, but in the general case, there is no system-intrinsic tool that tests DNS only, and you have to use something like dig.