[RFC] add --pidfile switch to write libo pid to a file

[Riccardo Magliocchetti]

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