Collabora "connecting" delay for 20 seconds

Hi @faktori,

I pushed a new collabora/code docker image to docker hub, which has a fix for the “special character” problem. The docker image did not have the locales in it, and lacale set to POSIX. However, in this case LibreOffice can handle only ASCII file names. The solution was to install all locales, and I set en_US.UTF-8 in the environment. Thanks for the bug report.

Best regards,
Andras Timar

2 Likes

Hi @timar,

Is there any chance to have ARM (aarch64) docker images? I guess many of us have those SoC as own/nextcloud server and it would be great to play with CODE.

Best

Hello Timar, thank you for your help on this topic
I have downloaded your last image on docker hub and I am using it.

However I am still having “connecting” delay of almost 30 seconds for my documents.

I tried opening some files on remote and local folders with no differences on the delay.
I tested collabora with various formats, (doc(x), xls(x), ): again no differences
An near empty 9kB odt file still takes 30sec to open.
So I’m pretty confident it is not a lool performance issue

I also tried repatching the docker image (just in case of …) but I didn’t get any improvement.

I there anybody still having a 20sec+ delay with the newest docker image ?

(My server is a dual core vps from OVH, it’s “under-used”, so I’m quite confident this is not a local performance issue)

Regards, Aal.

many thanks @timar for this. it’s working well :slight_smile:

hi @aalaesar i can confirm that the new docker image has this DNS issue resolved and i’m no longer getting the additional 20 second delay when opening documents. i have performed tcpdump testing on the docker0 virtual interface and all requests are being handled correctly.

1 Like

Thanks! For me the problem is solved now :slight_smile:

For reference here is how fast it is for me now:

(It are two separate VPS’es, one with Collabora running in Docker + Apache proy and one with the Nextcloud installation)

@aalaesar are you sure you have stopped and started the docker container after pulling? More information here: Collabora online - Nextcloud (at the bottom of the page before the troubleshooting section)

2 Likes

Hello
thank you for your feed back,
So it confirms something is messed-up with my nextcloud instance. (upgraded to nextcloud 10, could be a cause…)

I did create a new container to test this image.

With further testing, I have weird symptoms on my instance (NC10) like :

  • no collabora section in the admin conf (while the document apps is not activated)
  • on Chrome/Chromium/Firefox: open a first doc instantaneously only once then always fails with “unexpected connection error” after 45 sec while no error appears in the docker logs for any document, Even after cleaning cache and cookies (if related to browser)
    -on EDGE : open any document with a connection delay of 30 seconds.

I’ll make some more testing on my side, but I’m opened for any suggestion.

Regards,
Aal.

The section is under “Additional settings”

Oops :sweat: I was looking to fast.
One mystery solved, Thanks !
I haventt found yet why I have a 30 sec delay on Edge and sort of “timeout” on the other browsers.

Hello.
I have tested 2 brand new instances of nextcloud:
1- v9.0.53 => opening Documents/example.odt : Everything works fine except closing & reopening the file immediately (“connecting” delay, then “unexpected connexion error”)
2- v10.0 => opening Documents/About.odt : “connecting” delay, then “unexpected connexion error”, no errors in logs.
Edge manages to work most of the time but with a “connecting” delay of 30sec.
So I came to the conclusion that this topic’s issue is solved :metal:
but something is broken since nextcloud 10, at least on my side, but without obvious causes to be found in the logs, I’m clueless. Any hint ?
Regards

1 Like

I’d like to invite people who want to try the libreoffice building, to follow this step (in deutch unfortunately):

I’ve builded LO using this guide on a Ubuntu Xenial VM, no 20 seconds delay, everything ok.
I tried the same thing on a debian jessie but here, no luck. I have 40 seconds delay… I don’t know why but this is a different problem… the vm performances are good (I’ve used the same VM of the ubuntu xenial) but the delay is enourmous.
Can anyone guide me through this issue? What can it be to create this long delay?

Thanks!

I solved my issue with the 2x delay!

As my previuos post, after compiling LO+loolwsd I was experiencing a ~40-44 seconds delay.

I’ve compiled LO+loolwsd on a VM located on my LAN, and then I moved the builded LO to my VPS that has only a public IP. Everything was working very good except this delay, it looked as a timeout somewhere so I decided to point out the DNS issues as per @wizdude post. Even if he were using the docker image and I was not, the theory of the DNS timeout made some sense to me, so, on my VPS I logged every packet going to private networks using this script:

#!/bin/bash

IPT=/sbin/iptables

$IPT -F OUTPUT

$IPT -A OUTPUT -d 10.0.0.0/8 -j LOG --log-prefix " LOG:"
$IPT -A OUTPUT -d 10.0.0.0/8 -j REJECT
$IPT -A OUTPUT -d 172.16.0.0/12 -j LOG --log-prefix " LOG:"
$IPT -A OUTPUT -d 172.16.0.0/12 -j REJECT
$IPT -A OUTPUT -d 192.168.0.0/16 -j LOG --log-prefix " LOG:"
$IPT -A OUTPUT -d 192.168.0.0/16 -j REJECT

No more delay and something really disappointing on the firewall logs:

Sep  6 19:39:30 oc kernel: [187734.187350]  LOG:IN= OUT=eth0 SRC=188.x.x.x DST=192.168.10.2 LEN=61 TOS=0x00 PREC=0x00 TTL=64 ID=65021 DF PROTO=UDP SPT=58650 DPT=53 LEN=41 
Sep  6 19:39:30 oc kernel: [187734.187418]  LOG:IN= OUT=eth0 SRC=188.x.x.x DST=192.168.10.3 LEN=61 TOS=0x00 PREC=0x00 TTL=64 ID=26974 DF PROTO=UDP SPT=49437 DPT=53 LEN=41 

Catch! 192.168.10.2 and 192.168.10.3 are my internal DNS listed on /etc/resolv.conf on the VM I used to build LO/loolwsd. The 2x delay is explained by my 2 dns servers: 20 seconds each = 40 seconds…

Anyone has any idea of the library/process that took the DNS from my building system? It may be happened during LO compiling or during the loolwsd compiling, I’d have to recompile loolwsd changing my system DNS and then look again, but not now… :slight_smile:

—update: The issue is on loolwsd only. I put a public DNS on my /etc/resolv.conf and I rebuilded loolwsd. Now the delay is gone, without any iptables workaround :slight_smile:

1 Like

Congratulations aventrax for finding the root of this problem.
Has it been reported to the libreoffice online project ?
Regards.

Not yet. Are you experiencing the same issue?

i discovered the root cause, remediated, reported it to libreoffice online and they have fixed it.

aventrax has a build fault with his own implementation. it’s not even relevant to this thread which I started to discuss a fault/bug in the docker image.

i would kindly suggest that libreoffice building issues be relegated to a separate thread.

we are done here. the fault has been identified and fixed. end of thread.

cheers, wizdude.

Very rude and impolite.
Anyway, sorry for disturbing your thread, you’re the man.

@aalaesar, please congrats with him, otherwise his frustration will increase.

Ok, sorry I may have spoken to fast when i said it was the “root” cause of the 20 sec delay caused by the DNS timeout.
You did find out this was a dns issue and proposed a quick and effective workaround.


Aventrax got a just little deeper. and may have found why the dns problem append in the container (this could be why the faulty resolv.conf changed between your tests)
This also need to be reported to github, doesn’t it ?

I’m just going to ignore the blaming and look at what I know about this issue:

So the issue was that the /opt/lool/systemplate/etc/resolv.conffile was created while building the Docker image on the computer of the creator of the Docker image. (this also indicates why the value inhere was changed with the first update of the Docker image). The issue was reported to the creator of the Docker image. This person then solved the issue for a lot of people. I’m quiet sure the /opt/lool/systemplate/etc/resolv.conffile was symlinked to the /etc/resolv.conf file, which is created by Docker. This can be checked by going into the container (docker exec -it ID /bin/bashand executingreadlink /opt/lool/systemplate/etc/resolv.confwhich will return/etc/resolv.conf. If I add the–ip=208.67.222.222to the docker parameters, both the /etc/resolv.conf and the/opt/lool/systemplate/etc/resolv.conf` contains this nameserver.

Please make sure you are running the latest Docker image. Also if you are going to move files out of the Docker image to run on your own sever, or you compile it yourself, the symlink is lost.

1 Like

i’m sorry if you took offense to my comment, but this thread has become very polluted with all kinds of manual libreoffice build problems. this thread started because the docker image wasn’t working. this has now been fixed. i think it would be a fantastic idea if new threads were started to discuss any new problems to avoid confusion with others that might read this thread in relation to problem they might be experiencing with the docker image as well.

it makes for an improved and nicer support experience for users if each specific issue can be broken out and much quicker for people to search for as well.

+1

i think quite a few people who are reading this thread are striking the same core issue, but in a number of different ways. the build procedure for collabora is important and it appears several people, including the team who built the docker image, all made similar mistakes.

as far as the docker image is concerned, this has already been reported back and resolved. as far as local builds are concerned, this is probably all worked correctly and “by design”. i see this as a config issue rather than a code bug.

the reason this whole fiasco started in the first place is due to the fact that we are using collabora running in a docker container. this means (in simple terms) that you have an operating system with another (sub) operating system inside it and a protected subsystem inside that. the problem was hidden under multiple layers. the docker image was designed to be an easy “install and forget” solution to avoid a complex build procedure.

with a standard build of libreoffice this becomes a much easier “post configuration” step and probably won’t affect many people.

and why anyone would build software on one server and forklift it onto another server is beyond me. this is always fraught with danger and is never a recommended procedure. this is precisely why technology such as docker was created.

anyhow - all is good. the purpose of this thread has been fulfilled and we have all, including myself, learnt a lot in the process of debugging.

keep up the great work everyone. when we all come together to support software like this we can achieve great things and everyone using nextcloud and the related add-ons benefits. i’m loving all of the new development that’s taking place at the moment - it’s a very exciting time for everyone :slight_smile:

cheers, wizdude.

Ok, anyway, we’re all talking about the 20 seconds delay, so I think it is in-topic. Anyway, If this this a mistake I apologize.

Every package maintainer compile something on one system and then distribute it to other systems/people.
In my case I created my own package for libreoffice/loolwsd after compiling it, because surely I won’t install all the dev-libraries and compiler on the web server in production. This is not dangerous, simply you must control what the debian package does, not somebody else. I’m not saying you must do it, but I have different needs then you.

Hi - I have read this (now dated) post. I am having a similar issue with collabora.

I have the server installed in a web accessible lxc container under ubuntu 18.04, and it is taking 20 seconds to “initialize” (very simialr I believe to the problem posted here…) - see screenshot below. After the 20-second delay, it loads files quite quickly (no issue), but the 20-second lag is driving me crazy. I have been unable to fix it:

Screenshot from 2020-07-01 15-09-06

Does anyone have any suggestions?

Andrew