:: Re: [DNG] OpenRC: was s6-rc, a s6-b…
Page principale
Supprimer ce message
Répondre à ce message
Auteur: Simon Hobson
Date:  
À: dng@lists.dyne.org
Sujet: Re: [DNG] OpenRC: was s6-rc, a s6-based service manager for Unix systems
Timo Buhrmester <fstd.lkml@???> wrote:

> Probably because people don't want this behavior. Auto-respawn only
> makes sense when you're "relying" on buggy software you already expect
> to blow up, *and* are unwilling to debug it. "Try turning it off
> and on again", "A restart will fix it" is the Windows-way...
>
> In all other cases (I can think of), respawning a crashed service
> is exactly *not* what I want to happen (it could have crashed because
> it was exploited, providing the attacker with unlimited attempts).
> Or it could have crashed because there's an environmental problem
> that isn't directly under the program's control, in which case
> restarting it would just be pointless, because it likely can't start
> at all.
> Bonus points if the logs of the initial problem get rotated away due to
> excessive retrying, or the core dump of the initial crash gets
> overwritten...


I think that's one of those "every admin will have their own ideas" things - and it'll vary with the system and what it's doing.

You're right, that in many cases it's best to just leave it dead and let the admin deal with it.
On the other hand, I've known even the best software occasionally quit for some random (and usually transient) reason.
And then there's the point you've raised - what if it's an exploit ? Well on the one hand, you let it stay down until you've determined that and fixed it. On the other hand, it means the attacker only has to hit once to cause a denial of service that lasts until some admin can deal with it - it may be better to have the service pop back up and provide some reduced quality of service than to provide no service at all. That is a question for those who know what the service is, and what all the different factors are.