Executed from Linux command line, --convert-to is unexpectedly asynchronous

Linux command-line: libreoffice --convert-to odt:writer8 myfile.txt

The returned status code ($?) is zero. So far, so good. But, when I try to access the newly-created ODT file (E.g. copy it), it doesn’t yet exist.

Adding sync; sync; sync right after the libreoffice batch execution did not help.
Adding --headless as an option did not help.

However, if I sleep for a few seconds immediately after the libreoffice batch execution, then the file finally gets completed before a subsequent command references the ODT file.

Sample script:

cp   /etc/fstab   myfile.txt
libreoffice   --headless   --convert-to   odt:writer8   myfile.txt
RC=$?
if [ $RC -ne 0 ]; then
    echo '*** libreoffice conversion failed for myfile.txt'
    exit 86
fi
#sleep 3
ls *.odt

Result: ls: cannot access ‘*.odt’: No such file or directory

If one changes the above script so that the sleep is actually executed, then the ODT file is available.

Observation: It appears that executing libreoffice in batch mode is somehow kicking off a separate process to finish the ODT file.

Expected result: The exit to the shell and the availability of the ODT file should be synchronized.

Environment: Xubuntu 18.04, x64, up-to-date

Environment: Xubuntu 18.04, x64, up-to-date

… and LibreOffice version is…?

By the way, “writer8” filter specification after “odt” is redundant, since “writer8” is the default for the extension.

Since I cannot confirm on my ubuntu 18.04 (upgrades as of today), LibreOffice 6.0.7 (Distribution packages) my question would be: Are you executing the batch in a directory / filesystem, which is on an USB drive?

Executing in $HOME/Downloads which is on a SATA SSD.

By the way, I just tried this on a Mac and I do not have this issue. The anomaly seems to be something about the Ubuntu/Linux code for libreoffice.

Same bash script modified for Mac:

BASE=/Applications/LibreOffice.app/Contents/MacOS
cp   xx.sh   myfile.txt
$BASE/soffice   --headless   --convert-to   odt:writer8   myfile.txt
RC=$?
if [ $RC -ne 0 ]; then
    echo '*** libreoffice conversion failed for myfile.txt'
    exit 86
fi
#sleep 3
ls *.odt

Observation: It appears that executing libreoffice in batch mode is somehow kicking off a separate process …

yes - since command libreoffice (on Ubuntu 18.04) itself is wrapper to the real binary (see file /usr/lib/libreoffice/program/soffice). Therefore the parent process ID (PPID) won’t match your shell’s process ID (PID). You may try to use the binary directy (/usr/lib/libreoffice/program/soffice.bin --convert-to odt myfile.txt) and check whether you see the same behaviour. If yes, you most probable face a disk / filesystem caching issue.

The file /usr/bin/libreoffice is a soft link to soffice, a Bourne shell script. Inside the script, the soffice.bin executable is invoked.

The source code indicates that soffice.bin is the one starting a background process that does not finish before soffice.bin exits.

See: core/shellexec.cxx at master · LibreOffice/core · GitHub
Go to line 218:

    OString cmd =
#ifdef LINUX
        // avoid blocking (call it in background)
        "( " + aBuffer.makeStringAndClear() +  " ) &";
#else
        aBuffer.makeStringAndClear();
#endif
    FILE *pLaunch = popen(cmd.getStr(), "w");
    if ( pLaunch != nullptr )
    {
        if ( 0 == pclose( pLaunch ) )
            return;
    }

It would be interesting to understand why for only Linux, the request is executed in background. In my opinion, this is undesirable for command line execution in any O/S.

Reopened: https://bugs.documentfoundation.org/show_bug.cgi?id=117731