Created attachment 72002 [details] python script to demonstrate the problem Problem description: -------------------- LibreOffice 3.6 running in 'headless' mode does not shutdown when the dispose() method is called on the ComponentContext handle returned by the ServiceManager using the PyUNO bridge under Debian Squeeze. This appears to be a regression from 3.5. Steps to reproduce: ------------------- Save the attached Python script. This is cut down example from an application that works under 3.5 without issue. This script is known to work under Debian Squeeze. Pathnames may need tweaking for other Linux distributions. Under Debian Squeeze, the script may be invoked from a command line with: /opt/libreoffice3.5/program/python ./bugHeadless.py or /opt/libreoffice3.6/program/python ./bugHeadless.py The script starts LibreOffice in 'headless' mode and invites the user to verify this using ps(1). On resume, the shutdown LibreOffice down by calling dispose() and invites the user to verify using ps(1). Expected behaviour (3.5): ------------------------- Under LibreOffice 3.5 (currently 3.5.7), LibreOffice is observed to always shutdown with this script. Current behaviour (3.6): ------------------------ Under LibreOffice 3.6 (currently 3.6.4 but the issue was first noted with 3.6.2), LibreOffice has never been observed to shutdown. LibreOffice never shuts down with this script. The script does not manipulate any documents. With the full application, which does manipulate documents, LibreOffice shuts down. Usually. However, on at least two occasions it has not and has slowly eaten all main memory and then all swap until the OOM kills off the desktop itself. LibreOffice continues to eat memory until the system is totally moribund and a power cycle becomes inevitable. Not good. Platform: -------- Debian GNU/Linux 6.0.5 (aka Squeeze, aka Stable) Installation media: LibO_3.6.4_Linux_x86-64_helppack-deb_en-GB.tar.gz LibO_3.6.4_Linux_x86-64_install-deb_en-US.tar.gz LibO_3.6.4_Linux_x86-64_langpack-deb_en-GB.tar.gz LibO-SDK_3.6.4_Linux_x86-64_install-deb_en-US.tar.gz
This issue IS present in LibreOffice 4.0.0.
This issue IS still present in 4.0.3.
@Forester is this issue still present in 4.1.4? by the way I put "headless mode" expert to CC list.
Created attachment 91277 [details] reproducer ported to python3
Created attachment 91286 [details] reproducer ported to python3 This time one that works
First of all for a more authoritative answer you may want to add someone like sberg. Said that i have a few considerations: - I don't see much value on starting and killing libreoffice instances on demand, unless it is a requirement i'd advice to let your init system / a process manager handle libo. - Regarding the issue i've never poked with pyuno directly but always used unoconv, this is the relevant bits it is using for killing a libo instance it started: ### If there is no GUI attached to the instance, terminate instance else: info(3, 'Terminating %s instance.' % product.ooName) try: convertor.desktop.terminate() except DisposedException: info(2, '%s instance unsuccessfully closed, sending TERM signal.' % product.ooName) try: ooproc.terminate() except AttributeError: os.kill(ooproc.pid, 15) info(3, 'Waiting for %s instance to exit.' % product.ooName) ooproc.wait() where convertor.desktop is: ### Do the LibreOffice component dance self.context = uno.getComponentContext() self.svcmgr = self.context.ServiceManager resolver = self.svcmgr.createInstanceWithContext("com.sun.star.bridge.UnoUrlResolver", self.context) unocontext = resolver.resolve("uno:%s" % op.connection) unosvcmgr = unocontext.ServiceManager self.desktop = unosvcmgr.createInstanceWithContext("com.sun.star.frame.Desktop", unocontext) and ooproc is: ooproc = subprocess.Popen([office.binary, "-headless", "-invisible", "-nocrashreport", "-nodefault", "-nofirststartwizard", "-nologo", "-norestore", "-accept=%s" % op.connection], env=os.environ) which brings me to this working patch: --- bugHeadless3.py 2013-12-29 14:17:48.542798672 +0100 +++ bugHeadless3.mod.py 2013-12-29 14:46:29.503332461 +0100 @@ -28,6 +28,7 @@ try: resolver = local.ServiceManager.createInstanceWithContext("com.sun.star.bridge.UnoUrlResolver", local) self._officeContext = resolver.resolve("uno:{0};StarOffice.ComponentContext".format(self.unoUrp())) + self.desktop = self._officeContext.ServiceManager.createInstanceWithContext("com.sun.star.frame.Desktop", self._officeContext) except NoConnectException as e: self.reset() raise Exception("Office not running (?): {0}".format(str(e))) @@ -118,7 +119,7 @@ if not self._officeContext is None: print("shutdownOffice") print(self._officeContext) - self._officeContext.dispose() + self.desktop.terminate() self.reset() time.sleep(1) return self So in conclusion it looks to me like an user error. Feel free to dig into unoconv history to see if that was a libo change done during times or just your script used to work by luck. Nobody here is to blame though since the API is horrible.