sysv init doesn't monitor processes, so that doesn't fully answer the question. What do you use to ensure that processes started by sys init are still running?

Seriously it does not ? Add something like this:

   myapp:234:respawn:/path/to/myscript

to your inittab, and sysvinit will relaunch it (if it dies).

Regards.

ps is used for monitoring.

I make sure I write processes that don't fail. This is done with tooling (valgrind, cachegrind, unit tests, integration tests) and testing (automated testing, experienced testers).

The whole process restart mechanism is a combination of string and sticky tape to abstract away the problem of half-arsed poorly written bits of functionality that crap themselves every few minutes.

I can and have written processes that stay alive for years (5 years 122 days pegged at 100% CPU being the record after which a reboot was required as the Sun Ultra 2 hosting it was replaced).

> I make sure I write processes that don't fail.

Please name one major, non-trivial network system software that has gone for 5 years, 122 days without a fault in production anywhere.

Engineers in other disciplines make best efforts not to fuck up. And then they accept that they, or others, will fuck up anyhow and they plan for that.

So do we. And so we should. Betting it all on Red 19 is a strategy of roulette, not serious work.

We don't bet on that, we aim for that.

I can sense we're about to have a circular argument based on where to draw the boundaries of responsibility.

My point is that betting entirely on one strategy for mitigating faults is unnecessarily risky. Especially when additional levels of mitigation are easily installed and configured. In your other post you even point out a series of things that you do.

I don't see why process management is of a different kind.

Edit: removed unnecessary grandstanding.

you have clearly never written a distributed system or similar. Fail Fast, Fail Often.

That mantra is simply bullshit.

I have written massively distributed systems which have an insanely high reliability requirement and it is really not the answer. I've been doing this for 25 years.

A more appropriate statement is:

  Fail early and gracefully, recover always, expect failure.

Fail early - assertions up front. Prevention is better than cure.

Fail gracefully - don't allow assertions to take the entire process out. Don't allow the language to crash the process out.

Recover always - design your system for recovery and understand recovery conditions.

Expect failure - know where and when something is going to fail and handle it.

Fail fast, fail often results in nasty shit like processes hung in restart cycles etc.

This is much closer to the actual Erlang philosophy that gets misquoted so often.

Cron ?!