4 ms·

Kinda sad that "nothing" isn't on the list. I just use software that isn't broken, so it doesn't need to be constantly restarted.

by asdasf 13y ago

ekimekim 13y ago
While it's true that "nothing" or "custom" should be poll options, I don't agree with your reasons. Supervisor programs aren't just about restarting processes if they die. They manage dependencies, reloading, a central authority for starting/stopping and other administrative tasks. Some additionally do things like logging. And besides, even the most stable software can't be guaranteed bug-free (though I do agree that a better action might be to stop and yell loudly rather than blindly restart). Why forego a safety net?
- harrytuttle 13y ago
  I think there are some problems with your statement. All these process-reloading and management options are a symptom of a much larger problem. The problem is simply: People have stopped writing software designed to run continuously. Some notes from 20 years of Unix fudging: If a process dies, it's a problem with the process, not an external problem. Make it reliable. Software shouldn't fail at all. PostgreSQL, Postfix, init never crash from experience. Why shouldn't your software do the same? Reloading: system-wide: "service whatever restart/reload" Dependencies: Dependencies are hell. Having used BIG Unix kit with power sequencers and stuff, I wouldn't ever take on a dependency. If I did, the dependent processes should fail gracefully and retry. Central authority: service xxx restart/reload again... Logging: syslog? On our kit, we use Splunk but it's pretty much overkill for most people. If you can't sleep at night because your processes crash, there's no good employing someone (a supervisor) to go around and do CPR on them. Fix the root problem.
  - icebraining 13y ago
    Funny you should mention PostgreSQL, since it includes a monitoring process - the postmaster - that restarts the workers if they die ;) (and they do, occasionally).
    - asdasf 13y ago
      That's because the child processes can load and run third party code, which obviously can crash them. Just like apache modules can crash httpd worker processes. So why run an extra layer of monitoring on top of the existing one for apps like those?
      - icebraining 13y ago
        I don't think that's what's being suggested.
        asdasf 13y ago
        All the software in the poll is general purpose monitoring/restarting software. It isn't software designed to be multi-process and monitor its own child processes.
dmourati 13y ago
Agree. I've been at this for a long time and never needed anything in this capacity. Not once.
buster 13y ago
Then you never had to guarantee a SLA and pay for service downtime, so not seriously done a _business_ that earns money by providing a service.
- harrytuttle 13y ago
  We do guarantee an SLA and use precisely nothing other than sysv init. We pick software that is reliable and trustworthy then test it thoroughly. Those are forgotten arts outside of the enterprise. Elsewhere, any new technology that falls from the sky is picked whether it works properly or not.
  - buster 13y ago
    How do you cope with hardware failure, corrupt memory banks, temporary network failures, you also just buy "hardware that never fails"? Just testing something and deeming it reliable enough to "just run" is a horrible practice. There is no software on earth that is bug-free, you do realize that, yes? Why do you think the NASA builds rockets with many many safety measures? Because they use the latest and greatest hardware and software? Or because they KNOW that at some point something WILL fail. It's not a only a question of picking stable software. The skill is to be prepared for the emergency at any time, even if it is on a rare occasion. If your only safety measure is to "just pick stable stuff", i'd surely never buy your service.
    - harrytuttle 13y ago
      Firstly, calm down. I gave you a small peek into my world and you're drawing a lot of bad assumptions from it. We mitigate hardware issues with either hot spares or clustering. We have three datacentres distributed geographically with entire redundant sets of equipment (4x 42U racks in each). With respect to software failures, we test everything thoroughly including failover conditions etc. Everything is load tested as well. We are prepared for emergency. We have dedicated people ready to jump on that. However preventing these things ever being needed is a professional responsibility which is my point.
kalleboo 13y ago
I wish I lived in the perfect world you inhabit :( Some of us are dealt shitty cards and told to make it work.

Kinda sad that "nothing" isn't on the list. I just use software that isn't broken, so it doesn't need to be constantly restarted.

by asdasf 13y ago

Kinda sad that "nothing" isn't on the list. I just use software that isn't broken, so it doesn't need to be constantly restarted.

ekimekim 13y ago

While it's true that "nothing" or "custom" should be poll options, I don't agree with your reasons. Supervisor programs aren't just about restarting processes if they die. They manage dependencies, reloading, a central authority for starting/stopping and other administrative tasks. Some additionally do things like logging. And besides, even the most stable software can't be guaranteed bug-free (though I do agree that a better action might be to stop and yell loudly rather than blindly restart). Why forego a safety net?

harrytuttle 13y ago
I think there are some problems with your statement. All these process-reloading and management options are a symptom of a much larger problem. The problem is simply: People have stopped writing software designed to run continuously. Some notes from 20 years of Unix fudging: If a process dies, it's a problem with the process, not an external problem. Make it reliable. Software shouldn't fail at all. PostgreSQL, Postfix, init never crash from experience. Why shouldn't your software do the same? Reloading: system-wide: "service whatever restart/reload" Dependencies: Dependencies are hell. Having used BIG Unix kit with power sequencers and stuff, I wouldn't ever take on a dependency. If I did, the dependent processes should fail gracefully and retry. Central authority: service xxx restart/reload again... Logging: syslog? On our kit, we use Splunk but it's pretty much overkill for most people. If you can't sleep at night because your processes crash, there's no good employing someone (a supervisor) to go around and do CPR on them. Fix the root problem.
- icebraining 13y ago
  Funny you should mention PostgreSQL, since it includes a monitoring process - the postmaster - that restarts the workers if they die ;) (and they do, occasionally).
  - asdasf 13y ago
    That's because the child processes can load and run third party code, which obviously can crash them. Just like apache modules can crash httpd worker processes. So why run an extra layer of monitoring on top of the existing one for apps like those?
    - icebraining 13y ago
      I don't think that's what's being suggested.
      - asdasf 13y ago
        All the software in the poll is general purpose monitoring/restarting software. It isn't software designed to be multi-process and monitor its own child processes.

dmourati 13y ago

Agree. I've been at this for a long time and never needed anything in this capacity. Not once.

buster 13y ago

Then you never had to guarantee a SLA and pay for service downtime, so not seriously done a _business_ that earns money by providing a service.

harrytuttle 13y ago
We do guarantee an SLA and use precisely nothing other than sysv init. We pick software that is reliable and trustworthy then test it thoroughly. Those are forgotten arts outside of the enterprise. Elsewhere, any new technology that falls from the sky is picked whether it works properly or not.
- buster 13y ago
  How do you cope with hardware failure, corrupt memory banks, temporary network failures, you also just buy "hardware that never fails"? Just testing something and deeming it reliable enough to "just run" is a horrible practice. There is no software on earth that is bug-free, you do realize that, yes? Why do you think the NASA builds rockets with many many safety measures? Because they use the latest and greatest hardware and software? Or because they KNOW that at some point something WILL fail. It's not a only a question of picking stable software. The skill is to be prepared for the emergency at any time, even if it is on a rare occasion. If your only safety measure is to "just pick stable stuff", i'd surely never buy your service.
  - harrytuttle 13y ago
    Firstly, calm down. I gave you a small peek into my world and you're drawing a lot of bad assumptions from it. We mitigate hardware issues with either hot spares or clustering. We have three datacentres distributed geographically with entire redundant sets of equipment (4x 42U racks in each). With respect to software failures, we test everything thoroughly including failover conditions etc. Everything is load tested as well. We are prepared for emergency. We have dedicated people ready to jump on that. However preventing these things ever being needed is a professional responsibility which is my point.

kalleboo 13y ago

I wish I lived in the perfect world you inhabit :( Some of us are dealt shitty cards and told to make it work.