(BTW, we should get rid of webservice2 and merge it into webservice (with symlink from webservice2). Having two scripts with nearly identical names, but different abilities is no fun.)

I don't like the idea of having programs do something unexpected. We have a separation of concerns: webservice starts or stops a webservice, bigbrother ensures that webservices or jobs are restarted if they stop for whatever reason. Having one interfere with the other, especially changing a user-specified configuration file without the user's acknowledgment (or consent), is one of those moments where I as a user at the console don't understand what's happening.

What I would find more appealing is if we rewire webservice (that doesn't survive OOMs) with an SGE epilogue script, i. e. on webservice start a file ~/.webservice is created and the webserver started, on webservice stop the file ~/.webservice is removed and the job deleted, in the epilogue script that is called on job termination it is checked whether ~/.webservice exists, if yes, the termination was unwanted and the script returns 99 to reschedule the job, if no, the termination was wanted and the script returns 0 to delete the job (needs to be tested first). That would have a similar outcome (a webservice start is a long-term statement) without mixing up the two concepts of webservice and bigbrother.