killing soffice.bin from oosplash
sbergman at redhat.com
Thu Apr 19 06:39:53 PDT 2012
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:
>> 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
>> "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:
>> 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
> 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?
More information about the LibreOffice