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

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