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