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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
