Collabora "connecting" delay for 20 seconds

[aventrax]

Not yet. Are you experiencing the same issue?

[wizdude]

@aalaesar

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

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.

[aventrax]

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

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

[aalaesar]

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.

Collabora "connecting" delay for 20 seconds

I just tested this, but it doesn’t change the delay… Is CODE using the /opt/lool/systemplate/etc/resolv.conf file? no - this is the problem. docker ensures that the /etc/resolv.conf is provided via a special mount (so the contents of this file inside the image are not actually used). the --dns-ip option allows you to override the default action which is to simply use the contents of the host /etc/resolv.conf. normally this option isn’t required unless you have a nameserver bound to the loopba…

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 ?

[LEDfan]

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.

[wizdude]

@aventrax

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

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.

@LEDfan

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

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.

@aalaesar

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 ?

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

cheers, wizdude.

[aventrax]

@wizdude

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.

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.

@wizdude

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.

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.

[wizlon]

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:

Does anyone have any suggestions?

Andrew