On Wed, Jul 9, 2014 at 2:00 PM, <m.roth at 5-cent.us> 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 at centos.org > http://lists.centos.org/mailman/listinfo/centos >