Date: prev next · Thread: first prev next last
2013 Archives by date, by thread · List index


Hi Stephan,

Il 18/03/2013 22:18, Stephan Bergmann ha scritto:
On 03/16/2013 07:55 PM, Riccardo Magliocchetti wrote:
attached a patch to add a switch to have libreoffice store its pid in a
file. I need that so that when libo runs in headless mode i can have a
supervisor process checking if libo is running and in case just restart
it. The error handling is a bit lame, do we have an helper to create a
file with its content with one function call somewhere? that could help
cleaning the pidfile creation code a bit i think.

I'm not sure how exactly you would want to use this (e.g., given that 
there's only code to create the pid file, but none to clear it again), 
but have a few points:

* If you have a supervisor process, why not let it keep track of the pid 
of any started LO process?


Because it can track only one pid :)
My plan is to use uwsgi [1] to manage libo instances by a feature called
smart-attach-daemon [2] (not so robust atm btw) so i need to export the
pid of the process i want to manage. The advantage of this is i can have the
same stack running my python app (presumably a wrapper for unoconv [3])
keeping libreoffice running. I'm no root here so i can't exploit a modern
init system.

[uwsgi]
master = true
socket = :3031
#smart-attach-daemon = libo.pid /usr/local/lib/libreoffice/program/soffice 
'--accept=socket,host=localhost,port=2002;urp;' --pidfile=libo.pid
attach-daemon = /usr/local/lib/libreoffice/program/soffice 
'--accept=socket,host=localhost,port=2002;urp;'

The difference between the two is that with the smart one i can reload my
app without restarting libreoffice. 

* The client-facing executable in LO is soffice (which on Linux is a 
shell script that execs into oosplash), which internally spawns 
soffice.bin processes. It would thus look more natural to be interested 
in pid files from the client-facing process rather than from soffice.bin 
processes (which your patch would implement).

soffice.bin is the one i see in netstat so it looked the right one to me,
but handling this from soffice would be lot more easier.

* I would prefer if we could get away without exposing that 
OSL_DETAIL_GETPID hack in the stable URE interface. For example, its 
underspecified type is not a problem for the sole use case in 
sal/osl/all/log.cxx, but would not fit well into a well-crafted API.

ok

thanks,
riccardo

[1] http://projects.unbit.it/uwsgi/
[2] http://uwsgi.readthedocs.org/en/latest/AttachingDaemons.html
[3] https://github.com/dagwieers/unoconv

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.