61–69 of 69 posts
Runit is fantastic. If you are using Chef - the runit cookbook integrates very nicely. https://supermarket.chef.io/cookbooks/runit
Given the other glowing comments, maybe this would be a place to ask: should I bother with Upstart, or Systemd? I see Shuttleworth announced the move to systemd, but it's not available on Ubuntu 14.04 servers right now. I'm writing provisioning for our production fleet, what should I use? The vagaries of the OS wars make something like Runit tempting.
runit is what the Phusion Docker base image http://phusion.github.io/baseimage-docker/ is using, and it's the perfect tool to start and supervise containerized apps. I also love the fact that it can wait for a service to run (in order to wait for dependencies), and that stuck services can be restarted in a more radical way than a single TERM signal.
I'm using this too (after suffering all the other supervisors), and I have no clue why runit isn't the standard tool in Linux. Can any Linux expert explain that?
Runit is amazing. I've used it on several large scale websites with great success. Runit follows the unix philosophy of being stupid simple and doing one thing incredibly well. If you're starting up a new project, consider using Runit.
Not only is it simple and does the do-the-one-thing-well thing well, which is true, it's also _correct_. It's hard to overstate how valuable runit is in production because of that. It does the right thing with regard to clearing the environment, detaching from controlling terminal, logging, and many other subtle aspects of operating a service. I never worry about runit.
I use runit. It's great. (Daemontools didn't have the ability to sleep for 30 seconds after my daemons crashed at startup because, like, some filesystem wasn't mounted or something.)
How did you manage that? We currently have a problem with crashing services using up all system resources trying to constantly restart. Or better yet, exponential backoff.
#!/bin/sh
sleep 30
Earlier quoted context omitted.
Having dynamic memory allocation, let alone garbage collection, in my pid 1 doesn't sounds like a great idea. (I know, as long as I'm using Linux, I'm stuck with dynamic memory allocation in the fucking kernel . I don't have a plan for how to fix that yet.) (Also, thank you so much for all your help with Guix this last week!)
There's nothing wrong with dynamic allocation in a kernel. It is for example better than having fixed size process tables and all the crap that comes with that. "holy crap I've got to recompile my kernel to get more processes" is so 1995...
Earlier quoted context omitted.
There's nothing wrong with dynamic allocation in a kernel. It is for example better than having fixed size process tables and all the crap that comes with that. "holy crap I've got to recompile my kernel to get more processes" is so 1995...
You know what else is "so 1995"? 400-day uptimes.
Earlier quoted context omitted.
OpenRC isn't an init daemon. It's only a process management framework, hence the name. It's usually used in conjunction with sysvinit as PID1. OpenRC was originally motivated by replacing the older baselayout scripts, from what I recall. Upstart didn't come about until later from many of the alternatives I listed, and its origins were mostly in response to launchd. It was quite rudimentary initially. [1] [1] https://…
I never said or meant that Upstart wasn't younger than those alternatives. What I disagree with was the idea that there was much apathy and then a sudden crisis when systemd appeared. The development and adoption of Upstart and OpenRC (even if the latter isn't an init daemon, it's still an alternative to the init system ) by some of the biggest distros contradicts that claim.
My first encounter with the existence of systemd was while keeping half an eye on the whole consolekit+polkit+udisk rigamarole i apparently needed to get thunar (or more correctly gvfs) to automount stuff.
This when i learned that consolekit was to be replaced with logind, and logind required systemd as init.
That, to me, was a very WTF moment. It basically made a file manager dependent on a specific init being used.
Earlier quoted context omitted.
Back when I changed from supervisord to runit my life was substantially improved. That correctness means way fewer emergency maintenance ops issues in production.
What is wrong with supervisord?
This was a few years ago and I don't remember all the details. We just had occasional issues with stopping/starting and especially restarting processes when pushing a new version out or when a process crashed. I do remember it could occasionally report a successful restart and still leave the old process(es) running.
All my developers became very familiar with supervisord, and it was number 2 on the troubleshooting list (1. Did we introduce a bug in a recent commit? 2. Did supervisord do something weird again).
After we switched to runit, only devs that touched ops knew about it at all. And we all forgot it was there. That's what you want in an ops tool.