| 1 |
On 05/08/2013 04:06 PM, Chí-Thanh Christopher Nguyễn wrote: |
| 2 |
> Michael Mol schrieb: |
| 3 |
>>> Sounds like a great feature. A crashed process is a buggy one, and I |
| 4 |
>>> would want to investigate said program before I relaunched it, and |
| 5 |
>>> not have it automatically relaunched as if nothing had happened. |
| 6 |
>> |
| 7 |
>> That's highly, highly, highly use-case dependent. If it's a |
| 8 |
>> non-critical service, or in a non-critical environment, that's one |
| 9 |
>> thing. If it's a service whose downtime can be measured in value lost, |
| 10 |
>> that's quite another. |
| 11 |
> |
| 12 |
> You could be looking at someone trying to compromise your system through a |
| 13 |
> buffer overflow or similar vulnerability. If you enable automatic respawn |
| 14 |
> then congratulations, you just gave the attacker unlimited tries to guess |
| 15 |
> the correct address/offset for his exploit. |
| 16 |
|
| 17 |
Without respawn, you're already bending over and taking a DoS. And when |
| 18 |
you're in a situation where service uptime is a cap on revenue, uptime |
| 19 |
is pretty darn important. |
| 20 |
|
| 21 |
That's not to say analyzing the crash isn't important, but if I allowed |
| 22 |
a prod service to remain down while I investigated a crash, studied the |
| 23 |
problem, evaluated a fix for correctness and lack of regressions, |
| 24 |
scrubbed the fix and tried again, I wouldn't have that job for very long! |
| 25 |
|
| 26 |
Certainly there are environments where it's sensible to take things slow |
| 27 |
while you investigate (OpenVPN crashed? ssh crashed?), but there are |
| 28 |
environments where that's not the case, too. It depends on your threat |
| 29 |
model and a variety of cost/analysis factors. That's why I said "highly, |
| 30 |
highly, highly use-case dependent." |
| 31 |
|
| 32 |
If upstream provides a unit file, and that unit file specifies a |
| 33 |
behavior, you should (by default) trust the upstream. If you don't like |
| 34 |
what upstream does, convince them to change. If they won't, make your |
| 35 |
changes locally. If it's _really_ bad, obviously you have an interesting |
| 36 |
position as a dev in a distribution, and you might make your change |
| 37 |
there, but that certainly shouldn't be your default course of action. |
Archives