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

[Stephan Bergmann]

On 03/19/2013 10:06 AM, Riccardo Magliocchetti wrote:
> 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.

OK, I see.

>> * 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.

Then again, soffice.bin is the process that actually listens on the 
--accept arguments, so in your use case it might be more appropriate to 
track the soffice.bin pid after all.

Setting up the listeners for the --accept arguments passed from 
soffice/oosplash to soffice.bin is done in Desktop::RegisterServices 
(desktop/source/app/appinit.cxx), so that might also be a good place to 
write the pid.  (Setting up listeners for additional --accept arguments 
passed from additional soffice/oosplash/soffice.bin processes that pass 
their arguments to the first soffice.bin process and then terminate 
again are handled in desktop/source/app/officeipcthread.cxx.  Arguably, 
you would not want to handle --pidfile arguments passed in that way, and 
at least in theory this situation should not arise anyway with your setup.)

Documentation about command line parameters is in 
desktop/source/app/cmdlinehelp.cxx, btw.

>> * 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

One "cheap" solution could be to duplicate the handful of relevant lines 
from sal/osl/all/log.cxx.

Stephan