Summary: | No way to reliably kill LibreOffice when run in a headless way and accessed solely via the API | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | jim-libreoffice |
Component: | Libreoffice | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | RESOLVED WORKSFORME | QA Contact: | |
Severity: | critical | ||
Priority: | medium | CC: | jmadero.dev, mst.fdo, sbergman |
Version: | 3.5.3 release | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
jim-libreoffice
2012-05-03 08:27:49 UTC
(In reply to comment #0) > With LibO_3.5.1rc2_Linux_x86-64 I was able to start soffice.bin directly and > kill it after something bad had happened. > With LibO_3.5.3rc2_Linux_x86-64 I am unable to start soffice.bin directly (by > design, according to bug 48341), which means I have to start it via the soffice > script. Generally, it has never been supported to start anything but the outermost soffice directly. If starting anything else appeared to work, that always was by coincidence. And nothing changed in this regard between LO 3.5.1 and 3.5.3; in both versions, soffice.bin can exit early with code 81, expecting the wrapping process to restart it. This has been so at least since LO 3.4. > For LibreOffice to be useful in a headless, API only, daemon environment it > needs to be possible to start multiple instances (concurrently) and to kill > them reliably after problems occur. Killing reliably is, by definition, nothing LO itself can cooperate in doing "after problems [in LO] occur" (as LO can be in an undefined state then). (On Unix, you could probably experiment with process groups to reliably send SIGKILL to all processes in a group.) I understand the problem you are facing, but I'm not aware of a good solution for it, short of making LO crash less often. [I'm changing the title from "cleanly shutdown" to "reliably kill." Clean shutdown is possible with XDesktop.terminate, cf. e.g. OfficeConnection::tearDown in unotest/source/cpp/officeconnection.cxx.] The commit http://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-3-5&id=fa15135c278e7f371c7bc22bc85e53198b521ca9 might help a bit. You should be able to kill it using the PID of the soffice script. Anyway, this problem does not affect normal users, so it should not block the release => lowering the severity a bit. ah yes that problem sounds familiar, i had it when some of our unit tests, which also use remote UNO from Java, got wedged somehow and the soffice.bin kept running, which was quite annoying, hence the commit cited in comment #3. so please try out if LO 3.5.3, which includes the commit, fixes your problem. the soffice shell script exec's the oosplash program, which in turn forks soffice.bin, hence sending a SIGTERM to the soffice process spawned from Java UNO ought to work (it does work for the unit tests at least, see unotest/source/java/org/openoffice/test/OfficeConnection.java tearDpwm method for extensive error handling stuff). there are however still race conditions, i.e. it is possible (though extremely unlikely) that the soffice.bin terminates by itself before the SIGTERM is sent to it, and an unrelated process is spawned in the meantime that happens to have the same PID... but there doesn't seem to be a POSIX interface that allows to "kill a process and all its children"; apparently systemd uses Linux specific "cgroups" to get that feature (i wonder if that is something that requires root): http://0pointer.de/blog/projects/systemd-for-admins-4.html can we mark this as NEW? i think there is nothing that can easily be improved here, and as described in comment #4 killing the outer soffice with SIGTERM should work well enough in practice, hence resolving this WORKSFORME. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.