On Wed, Jul 9, 2014 at 2:00 PM, <m.roth@xxxxxxxxx> wrote:
> Lamar Owen wrote:
> > On 07/09/2014 01:38 PM, Les Mikesell wrote:
> <snip>
> >> and (b) why you think an unpredictable daemon should be resurrected to
> >> continue its unpredictable behavior.
> >
> > I have had services that would reliably crash under certain
> > reproduceable and consistent circumstances that were relatively harmless
> > otherwise. Restarting the process if certain conditions were met was
> > the documented by the vendor solution.
> >
> > One of those processes was a live audio stream encoder program;
> > occasionally the input sound card would hiccup and the encoder would
> > crash. Restarting the encoder process was both harmless and necessary.
> > While the solution was eventually found years later (driver problems) in
> > the meantime the process restart was the correct method.
> <snip>
> On the other hand, restarting can be the *wrong* answer for some things.
> For example, a bunch of our sites use SiteMinder from CA*. I do *not*
> restart httpd; I stop it, and wait half a minute or so to make sure
> sitenanny has shut down correctly and completely, closed all of its
> sockets, and released all of its IPC semaphores and shared memory
> segments, and *then* start it up. Otherwise, no happiness.
>
> mark
>
> * And CA appears to have never heard of selinux, and isn't that great with
> linux in general....
>
>
Automatically restarting services is always a bad idea, especially when
they are customer facing services. There is nothing worse than a problem
that hides behind an automatic restart, especially while it's corrupting
data since it's happily starting right back up after dying in the middle of
a transaction and potentially creating new transactions that will also
terminate when the app crashes again (and it most often will).
The least important aspect of a service dying is the state of the service
itself, the most important is what has happened to the data when it
abended. Restarting the service automatically after failure is a recipe
for disaster.
> _______________________________________________
> CentOS mailing list
> CentOS@xxxxxxxxxx
> http://lists.centos.org/mailman/listinfo/centos
>
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
