Bug 37531

Perhaps related to Bug 37411?

Yes, it also happens on 3.4 RC1 / SLED 11 sp1 i586.

cc for Petr/Muthu's review.

Ooops, "(/usr/bin/)libreoffice-writer" is my private wrapper. I meant "/opt/libreoffice/program/swriter -convert-to pdf ...", of course. Sorry for confusion.

Muthu, could you please have a look? Does it have any reasonable solution?

I was hit by this too. In headless mode 'soffice' exits quietly with success without doing anything:

Try:

#!/bin/bash
soffice --headless --convert-to pdf foo.doc &
soffice --headless --convert-to pdf foo.doc && echo "exit status: $?"

*** Bug 41686 has been marked as a duplicate of this bug. ***

Contents from there:
to replicate
1) Open Writer or Calc using gnome menu
2) call this command: libreoffice3.4 --convert-to pdf myfile.doc
3) nothing will happen, as if having the GUI open interrupted the execution of
the command.

I'm seeing the same issue.

When a GUI instance of LO is running, the convert-to CLI command fails to
execute - and usually spawns another GUI window.  This occurs with other CLI
commands as well, such as --print-to-file.

(Ubuntu 11.10 x86_64)

*** Bug 44496 has been marked as a duplicate of this bug. ***

Michael is quite familiar with the startup code. I wonder if he has an idea.

This bug seems to affect all CLI operations, not just convert-to.  When a GUI instance of LO is running, 'libreoffice --help' produces no output, but returns success.  A fix would be greatly appreciated.

Muthu is the best guy here. Then again - getting an:

strace -f -s 4096 ./soffice --headless etc. etc for both the first and second processes would prolly show you what is going on quite easily.

The code is:

http://cgit.freedesktop.org/libreoffice/core/tree/desktop/unx/source/start.c

for the quick-start arg. passer, and hereabouts:

http://cgit.freedesktop.org/libreoffice/core/tree/desktop/source/app/cmdlineargs.cxx

for the 'main' process.

You may find, you have better joy if you run './soffice.bin' instead of './soffice' - though the paths will need setting up.

If you can make ./soffice.bin behave differently to ./soffice then there is a problem in 'ooqstart.bin' I guess, that we'd need to look at.

Failing that, as a hack around removing ooqstart.bin might help you.

I'm not going to have time to look at this just now, but patches much appreciated.

As far as I remember, lo doesn't do the conversion, because the (new) instance wouldn't do anything other than sending the (older) process a signal.

How important is this feature? I guess, people would mostly either use the UI or the batch converter and not both?

If a user is running CONVERT from the command line, I'd guess that such a person would be very likely to be running the UI as well...

May be use two versions of LibreOffice which save profile in different places. So we can then use 2 independent versions of office. Or specify place with user profile in command line?

(In reply to comment #12)
> As far as I remember, lo doesn't do the conversion, because the (new) instance
> wouldn't do anything other than sending the (older) process a signal.
> 
> How important is this feature? I guess, people would mostly either use the UI
> or the batch converter and not both?

imho, all applications, including LO should allow multiple running instances to operate independently of each other.

Suppose for example: A user want to edit a spreadsheet while at the same time wants to perform a batch convert of 100+ odt files to pdf from the command-line.

Hmm, it is possible to open another document from the command line. It just passes the file name to the already running LibreOffice instance. The running instance takes it and opens the document in a new window.

I wonder if something like this would be possible with the document conversions. We just need to pass the right commands to the already running LO.

(In reply to comment #11)
> Muthu is the best guy here. Then again - getting an:
> 
> strace -f -s 4096 ./soffice --headless etc. etc for both the first and second
> processes would prolly show you what is going on quite easily.
> 

Seems both instances of LO try to claim the same named pipe for IPC.

Instance-1 succeeds in creating and communicating using this pipe, but instance-2 seems to time out as shown below:

25304 access("/tmp/OSL_PIPE_1000_SingleOfficeIPC_bcb44c91593d45fbe896d17e4322b1a", F_OK) = 0
25304 connect(7, {sa_family=AF_FILE, path="/tmp/OSL_PIPE_1000_SingleOfficeIPC_bcb44c91593d45fbe896d17e4322b1a"}, 110) = 0
25304 getcwd("/home/user/Build", 4096) = 24
25304 sendto(7, "InternalIPC::Arguments1file:///home/user/Build,--convert-to,pdf,untitled.odt", 76, 0, NULL, 0) = 76
25304 sendto(7, "\0", 1, 0, NULL, 0)    = 1
25304 recvfrom(7,  <unfinished ...>
25308 <... futex resumed> )             = -1 ETIMEDOUT (Connection timed out)

Perhaps it's possible to append an instance number to the pipe name?

Created attachment 58580 [details] [review]
Resolves 37531. Appends PID to named pipe path. Dirty.

This patch appends the current Process ID to the IPC named pipe path in order to provide each instance of LO with a unique pipe.  Admittedly, it's a bit of a hack and may break other stuff.  The original code seems to hint that multiple instances should run "out of the box" sharing the same IPC and backend... But that's not currently the case, so here we are.

Works for me. YMMV.

Feedback appreciated.

jtang: cool! can you forward that patch along with a brief to the mailing list for review, please? A lot of people would sure be interested. Thanks a lot again for the patch.

(In reply to comment #16)
> Hmm, it is possible to open another document from the command line. It just
> passes the file name to the already running LibreOffice instance. The running
> instance takes it and opens the document in a new window.
> 
> I wonder if something like this would be possible with the document
> conversions. We just need to pass the right commands to the already running LO.

This is suboptimal as sometimes you need to use a particular version of LO for batch conversion to be able to quarantee the stability of the conversion (no new bugs etc.)

The best solution would be to just process all "request" that are to be done in the "batch mode" by the called binary.

I had the feeling that the pipe is there to communicate with the primary LO instance. If you call second instance, it could use the pipe to tell the first instance what command is required. I might be wrong, though.

(In reply to comment #21)
> I had the feeling that the pipe is there to communicate with the primary LO
> instance. If you call second instance, it could use the pipe to tell the first
> instance what command is required. I might be wrong, though.

Yes, agreed, it does seem intended to serve this purpose - as I've noted above.  However, its implementation seems to fail at achieving this goal.

Feedback from libreoffice-dev indicates that the above patch may indeed break other aspects of LO - use at own risk.

LO runs with the expectation that there is only ever one instance operating on the ~/.config/libreoffice/3/user directory at any given time. Hence the client/server model, though currently broken, is used to offload requests from additional LO instances to the primary instance.

Two further options immediately come to mind:
1) Fix the IPC layer to allow CLI options to be background-processed by the primary instance.
2) Add a CLI argument to allow LO to use an "alternate-config-dir" (as Sasha suggests)

At first glance, option 2 seems to be the quickest solution that will not break other parts of LO.  However, the 'proper' long-term solution remains option 1. 

I'll take a shot at option 2 since it solves my immediate requirements.  Hopefully by week's end.  I'll leave option 1 to the Jedi Masters.

For changing user profile use this argument:
-env:UserInstallation=${MY_CONF}
Explanations about this argument is here:
Bug 45026 - Command Line invokes empty document if LibreOffice Writer already running

(In reply to comment #24)
> For changing user profile use this argument:
> -env:UserInstallation=${MY_CONF}
> Explanations about this argument is here:
> Bug 45026 - Command Line invokes empty document if LibreOffice Writer already
> running

Excellent!  This undocumented / semi-documented argument does exactly what I'm looking for. The commands below will now run correctly.

soffice --headless --convert-to pdf foo.doc &
soffice -env:UserInstallation=file:///home/user/.libreoffice-alt --headless --convert-to pdf foo.doc &

Cool! Shall we close this as 'wontfix' then? (or as duplicate of bug 40526)

(In reply to comment #25)
> 
> Excellent!  This undocumented / semi-documented argument does exactly what I'm
> looking for. The commands below will now run correctly.
> 
> soffice --headless --convert-to pdf foo.doc &
> soffice -env:UserInstallation=file:///home/user/.libreoffice-alt --headless
> --convert-to pdf foo.doc &

(In reply to comment #26)
> Cool! Shall we close this as 'wontfix' then? (or as duplicate of bug 40526)

That depends. I would still consider it broken since the IPC is not performing it's intended function. Both the pipe renaming and alternate config directory are kludges to get around the broken IPC - they don't fix the core problem.

Comment on attachment 58580 [details] [review]
Resolves 37531. Appends PID to named pipe path. Dirty.

Setting flag on patch to prevent it showing up in searches - I understand that the patch as-is is not intended for integration?

(In reply to comment #26)
> Cool! Shall we close this as 'wontfix' then? (or as duplicate of bug 40526)

I would like to see this fixed.

It seems counter intuitive to have the behavior of libreoffice
batch processing invoked from the command line change depending on
whether an instance of LO is already running or not.
It certainly felt broken to me when I ran into it.

And I do use LO gui and LO command line at the same time.
I edit .odt or .doc scripts in the LO gui and then use a script to convert them to .fdx. This script only understands .fodt, so it first invokes LO batch mode to convert the input to that. It is inconvenient to have to shut down LO whenever I need to do the conversion.

Actually, I was really happy when I found out about the batch conversion mode in LO. It's great, dunno what I'd do without it :)

> I would like to see this fixed.

There is a simple way to get the bug addressed: send a patch ! :-)

There is quite a lot that is possible here; for example - we could encourage the headless mode not to use any user settings / extensions / auto-save, and ignore the home directory completely. That would remove lots of the (locking related) reasons that we have a factory process anyway; it'd be useful for liblibreoffice too.

Might help for multi-process instances as well.

*** Bug 40807 has been marked as a duplicate of this bug. ***

Created attachment 98136 [details]
This affects LyX and other desktop applications that rely on LibreOffice

This behavior affects *other* desktop applications that rely on LibreOffice's headless operation.

For example, LyX relies on "libreoffice --convert-to" to incorporate LibreOffice drawings, spreadsheets, charts, etc. in complex LyX documents. See attached screenshot.  With the current behavior, if an instance of LibreOffice happens to be running, LyX fails to process *all* LibreOffice files.

*** Bug 73405 has been marked as a duplicate of this bug. ***