Nextcloud AIO taking extemely long to start - debugging options?

DrakeHamString · March 20, 2024, 2:21pm

Hi there,
I’m having the problem that the nextcloud container of the AIO package takes really long to start (about 30 minutes)

I know this problem was already covered here or here.

But this is not the problem of my ISP or the hoster.

A month ago I created a VM for testing purposes, installed Nextcloud AIO and everything is fine! Now I created a second VM in the same network, same OS, same settings (I assume) and this one takes 30 minutes to start the containers!

Is there any way to debug this, to find out what is causing it to be slow? Where timeouts are and such?

I’m already checking docker logs nextcloud-aio-nextcloud -f where every output-line takes about a minute…

Even a simple command like sudo docker exec --user www-data nextcloud-aio-nextcloud php occ config:system:set default_phone_region --value="DE" takes about 10-20 seconds to execute (normally its about one second)

I want to find out what the problem is and solve it

jtr · March 22, 2024, 5:48pm

Can you share the Compose files used on the working and non-working installation?

What VM platform? Can you confirm it happens in a third test VM?

DrakeHamString · April 9, 2024, 9:02am

Okay, after some fiddling and trial and error, I found the issue

I have two independent internet connections for failsave operation. (handled by the router via NATing)

And and the Nextcloud AIO was external reachable through ISP 1 but “dials out” through ISP 2
(The DNS record points to ISP 1)

It looks like NC AIO has some self checks for ingoing and outgoing traffic. And the slow start of the containers was caused by the fact, that the outgoing connection doesnt match the ingoing connection.

Letting every traffic going through one ISP and also setting the DNS to this connection did solve the issue.

Funny thing I also noticed:
At the moments when the DNS record still was not propagated and the NC AIO didnt know the IP address behind the DNS name, the containers did start fast. But right at this moment the DNS record was present, the containers became slow again.

For future opteration it would be nice to be able to disable those particular checks. Or at least let the logs tell you whats wrong. Here was NOTHING telling me about what was wrong. It was just slow, there were no error or info messages.

Edit:
Opened an issue on GitHub now

github.com/nextcloud/all-in-one

Startup slow when using different Internet Connections for IN and OUT

opened 09:27AM - 09 Apr 24 UTC

DrakeHamString

0. Needs triage bug

### Steps to reproduce 1. Having two Internet Connections (ISPs) for failsave operation, managed by a router (who does NATing) 2. DNS record points to IPS 1, outgoing traffic goes trough IPS 2 3. Setting up AIO ### Expected behavior Normal AIO Operation, fast start of containers. Snappy operation. ### Actual behavior Starting of ''nextcloud-aio-nextcloud'' takes about 30 minutes. The normal setup works fine, the slow start appears when doing the "normal" start of the container after setup is done. When the container is started, the web interface is very slow and laggy. There are minutes of wait time until the website loads. But its reachable. ### Host OS Linux #### Nextcloud AIO version v7.13.1 (current behaviour expected in latest vesion too) #### Current channel latest #### Other valuable info It seems that there are internal checks or timeouts which are causing the slow start. Where it checks if ingoing and outgoing traffic ways are matching. It would be nice to be able to disable those checks or at least let the logs tell you whats wrong. Here was nothing telling me about any issue. It was just slow, there were no error or info messages. I already posted this in the forum before opening the issue on GitHub: https://help.nextcloud.com/t/nextcloud-aio-taking-extemely-long-to-start-debugging-options/185956 After setting all traffic through one ISP did solve the issue for me. But the problem still remains when there is an actual need to run it though two ISPs. I also switched the IPS's roles to reproduce the issue the other way arround - yes, the issue was there again.