Hacker News Reader

Comment by moonboots | Hacker News Reader

I use runit in production for http://typing.io. I appreciate runit's strong unix philosophy (shell scripts instead of dsls). However, I'm starting to experiment with systemd because of features like properly tracking and killing services [1]. This feature would be useful with a task like upgrading an nginx binary without dropping connections [2]. This isn't possible with runit (and most process monitors) because nginx double forks, breaking its supervision tree.

[1] http://0pointer.de/blog/projects/systemd-for-admins-4.html

[2] http://wiki.nginx.org/CommandLine#Upgrading_To_a_New_Binary_...

View on HN

Side note: that's a wonderful page, but I think it would benefit greatly from using something like Mozilla persona instead of Google account.

why? Google account is so universal. Who has a Mozilla persona?

> Who has a Mozilla persona?

Anyone whose email provider provides persona automatically, or who runs their own identity provider, or who has taken 10 seconds to create an account on Mozilla's.

Because Google sells your data, I guess. And the NSA scandal.

And because you're telling Google more when you log into a site with OpenID (or any Google-specific mechanisms) than you're telling anyone when you log in with Persona.

Does nginx ever really crash, though? It hasn't in my experience.

Supervision has many benefits besides automatic restarts after crashes. Supervising programs provide a consistent way to start, monitor, and log long running programs. Nginx reinvents its own interface for some of this functionality (like daemonizing, log rotating/compression, conf reloading, etc.), but it's useful for all services to work under the same interface. This is especially true for monitoring nginx's status, where a supervisor like runit is much nicer than 'pgrep nginx' or 'ps aux | grep $(cat /where/nginx/dumps/its/pid)'.

There are some good points there, but they're not particularly applicable to nginx. nginx's relative robustness, its need to log to more than one file, and its need to fork itself in order to perform graceful configuration state transitions suggests that it's not really a low-hanging fruit for robust process supervision.

Besides, its control interface is the same as any other subsystem if you've configured it correctly -- i.e., "service nginx <verb>".

I agree that nginx needs supervision less than most processes because it reinvents many wheels. However, supervision is still nice, e.g. your 'service nginx' example that uses Ubuntu's supervisor Upstart.

I agree it's not worth straining to make nginx's binary upgrade work with arbitrary supervision. However, if someone created a supervisor that solves this problem (systemd), I might give it a try.

service(8) is supposed to be supervisor-independent. If it's not, that's a problem.

My bad, I've only used the service command on Ubuntu post-upstart and thought they were more deeply related.

Like with all software... it doesn't until it does. And when it does you wish you had an auto-restart system in place.

It doesn't even have to be nginx's fault. It could be that some other process started fork-bombing the system and OOM-killer decided that killing nginx is the way to resolve it, before trying the actual offender.

I enjoyed how the page scales when I zoom in :)

You can turn of daemonization in nginx.

Disabling daemonization allows nginx to be monitored initially and through conf reloads but not binary upgrades (e.g. nginx 1.5.1 -> nginx 1.5.2). The binary upgrade process forks the master process, which it 'orphans' from runit and reparents under pid 1.

oops, edit: pid 0 -> pid 1

pid 1, actually :)

Reply on news.ycombinator.com