On 9.7.2014 22:00, 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.... My limited understanding you are actually describing problem which systemd should be answer. It should take care of these things for you. Now you wait minute or two which is wrong way of doing it. Right way would be script that actually checks that nothing of the stuff is left around. It's same kind of hack solution that restarting dying service is. Sometimes hack solutions are needed and sometimes not. In my again limited experience with systemd as running Fedora as "hobby"-server I have gathered that you can decide case by case basis should the process be restarted or not. -vpk