killing soffice.bin from oosplash

[Stephan Bergmann]

On 04/19/2012 03:11 PM, Michael Stahl wrote:
> On 19/04/12 13:35, Stephan Bergmann wrote:
>> On 04/17/2012 03:15 PM, Michael Stahl wrote:
>>> have oosplash forward SIGTERM to soffice.bin:
>>>
>>> http://cgit.freedesktop.org/libreoffice/core/commit/?id=946e7180be96178937e7be1b0bd7132902709a87
>>
>> The above is not a good idea.  At least with POSIX, there is no reliable
>> way for a parent process to forward to a child process a signal that the
>> parent receives.  There is always a window of time after fork(2) where
>> the forwarding will not yet happen, and there is always a window of time
>> after wait(2) where the forwarding will potentially send the signal to
>> an unrelated process.  (Yes, I know, the soffice script tries to do the
>> same, see
>> <http://compgroups.net/comp.unix.shell/sh-terminating-children-upon-sigterm/501864>
>> "sh: Terminating children upon SIGTERM" for a fruitless discussion.)
>>
>> The two processes need to communicate shutdown requests with a more
>> sophisticated protocol than trying to send a SIGTERM received by the
>> parent on to the child.
>
> the soffice.bin really should be dead by the time the JUnit test process
> exits, because otherwise the next time you try to run the test it won't
> run (and even worse will hang forever currently...), because the old
> soffice.bin is still listening on the pipe, so the new soffice.bin
> cannot listen.

That's why I prefer the test to hang when it cannot guarantee that all 
processes it (indirectly) spawned have terminated.

> the returning was intentional, so the oosplash could forward the exit
> status of soffice.bin, but considering the race condition you mentioned
> i guess hard-coding the exit status that soffice.bin would return is better.

The canonic(?) way of doing this is by resetting the signal's action to 
default and re-raising the signal from within the handler, so that the 
parent can observe that the process terminated due to a signal, but 
_exit should probably be just as fine.

>>> these increase reliability of JUnit based test infrastructure:
>>>
>>> http://cgit.freedesktop.org/libreoffice/core/commit/?id=90f7a3ada68f309a9d3201183ef552e59f9558fb
>>> http://cgit.freedesktop.org/libreoffice/core/commit/?id=228515e7783aecdb992258765554a530d6c831f3
>>
>> Not yet sure what to make of these two.  This is tricky territory, and a
>> number of potential deadlocks had deliberately been left in, on the
>> ground that (a) programmatically forcing termination of non-terminating
>> processes does not guarantee resource clean up (i.e., spawned
>> sub-processes can remain, see above), and (b) forcing termination
>> prevents debugging of the underlying deadlock.
>
> these are not about deadlocks but to kill the office process in
> situations where soffice.bin was not killed properly.

My words were not very clear.  What I meant was to try producing a 
deadlock if the test cannot guarantee that the spawned soffice has 
terminated.

> the first one was about a case where Desktop.terminate returned but
> didn't terminate (because there was some unsaved document still open).

...causing OfficeConnection.tearDown to hang?  Yes, that was 
intentional, as explained above.

> the second one was encountered when somebody removed an IDL type, and
> the unoil.jar still contained the corresponding class file, which made
> the Junit process' UNO runtime request the corresponding type over the
> UNO bridge, but the other side didn't have it in its RDB so the Java UNO
> bridge disposed itself, leading to an uncaught DisposedException here
> and a still running soffice.bin process.

...and again, a hanging OfficeConnection.tearDown, right?

Stephan