2 ms·
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 s
by 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 agoFunny 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 agoThat'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 agoI don't think that's what's being suggested.
- asdasf 13y agoAll 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.