4 ms·

That is until you get a process that triggers OOM due to a bug on startup (pissing all over RAM) that ends up getting stuck in a restart loop which cripples you

That is until you get a process that triggers OOM due to a bug on startup (pissing all over RAM) that ends up getting stuck in a restart loop which cripples your machine so you cant get in and fix it. Either that or it fails and neutralises supervisord or something resulting in site down anyway. ulimit is a better solution i.e. set reasonable constraints based on available resources.

derefr 13y ago
I've never seen a process supervisor daemon that didn't have an "if process FOO exceeds X restarts in Y milliseconds, stop trying to start FOO" clause.
- harrytuttle 13y ago
  You've never seen an "enterprise" software init script then. 5-nines? Stick it in an endless loop and no one will notice (Atlassian I'm looking at you).
  - ghc 13y ago
    I have written enterprise software. Guilty as charged.
  - X-Istence 13y ago
    Yeah, but looking at Atlassian is easy, for pete's sake they gave us shitty software like JIRA, Confluence and others... and I say that with a HUGE dislike of those products due to how obtuse they can be.
    - harrytuttle 13y ago
      Fair point! Agree entirely by the way.
- viraptor 13y ago
  daemontools / supervise doesn't have it and it's a fairly popular solution. (not that I recommend ever using it...)
  - DigitalBison 13y ago
    > daemontools / supervise doesn't have it and it's a fairly popular solution. Ok, it doesn't exactly support the quoted feature ("stop restarting if it exceeds X attempts in Y seconds"), but it does sleep for a second between restart attempts to mitigate the same problem: http://cr.yp.to/daemontools/supervise.html http://cr.yp.to/daemontools/supervise.html
  - pmahoney 13y ago
    I'm curious why you wouldn't recommend it. I've never used it myself, but I've been reading about it the past few weeks. The design seems really well done compared to init.d scripts in the sense that every init script must reimplement daemonization, pid files, etc. (which is helped by examples, start-stop-daemon, etc. but is still a huge and delicate chore in my experience). Is your objection that daemontools is largely unused / unmaintained and lacks features (such as flapping-avoidance)? Or something else? Just curious, thanks.
    - viraptor 13y ago
      It's mostly about the lack of features. No support for cgroups, user switching, adjustable backoff, syslog, etc. Sure - it works, but it's the same thing as with qmail - it's the very minimum that you can call a useful SMTP deaemon. The moment you want any feature on top, you have to implement it yourself. Either one of upstart, systemd, supervisord will give you equivalent solution that has more practical features. Daemontools was good enough a couple of years ago. (I used it then happily) In short - there's nothing wrong with it really, but many alternatives are much better.
btilly 13y ago
I disbelieve that ulimit is a real fix. If you disagree, save this shell script, set a reasonable set of ulimits then run it: #! /bin/sh sh $0 & while true do perl -e 'push @big, 1 while 1' & sh $0 done

derefr 13y ago

I've never seen a process supervisor daemon that didn't have an "if process FOO exceeds X restarts in Y milliseconds, stop trying to start FOO" clause.

harrytuttle 13y ago
You've never seen an "enterprise" software init script then. 5-nines? Stick it in an endless loop and no one will notice (Atlassian I'm looking at you).
- ghc 13y ago
  I have written enterprise software. Guilty as charged.
- X-Istence 13y ago
  Yeah, but looking at Atlassian is easy, for pete's sake they gave us shitty software like JIRA, Confluence and others... and I say that with a HUGE dislike of those products due to how obtuse they can be.
  - harrytuttle 13y ago
    Fair point! Agree entirely by the way.
viraptor 13y ago
daemontools / supervise doesn't have it and it's a fairly popular solution. (not that I recommend ever using it...)
- DigitalBison 13y ago
  > daemontools / supervise doesn't have it and it's a fairly popular solution. Ok, it doesn't exactly support the quoted feature ("stop restarting if it exceeds X attempts in Y seconds"), but it does sleep for a second between restart attempts to mitigate the same problem: http://cr.yp.to/daemontools/supervise.html http://cr.yp.to/daemontools/supervise.html
- pmahoney 13y ago
  I'm curious why you wouldn't recommend it. I've never used it myself, but I've been reading about it the past few weeks. The design seems really well done compared to init.d scripts in the sense that every init script must reimplement daemonization, pid files, etc. (which is helped by examples, start-stop-daemon, etc. but is still a huge and delicate chore in my experience). Is your objection that daemontools is largely unused / unmaintained and lacks features (such as flapping-avoidance)? Or something else? Just curious, thanks.
  - viraptor 13y ago
    It's mostly about the lack of features. No support for cgroups, user switching, adjustable backoff, syslog, etc. Sure - it works, but it's the same thing as with qmail - it's the very minimum that you can call a useful SMTP deaemon. The moment you want any feature on top, you have to implement it yourself. Either one of upstart, systemd, supervisord will give you equivalent solution that has more practical features. Daemontools was good enough a couple of years ago. (I used it then happily) In short - there's nothing wrong with it really, but many alternatives are much better.

btilly 13y ago

I disbelieve that ulimit is a real fix. If you disagree, save this shell script, set a reasonable set of ulimits then run it: #! /bin/sh sh $0 & while true do perl -e 'push @big, 1 while 1' & sh $0 done