How to use another (nginx) port than 80?

[Sarmingsteiner]

I am struggling with this part of the FAQ:

13. How to solve listen tcp4 0.0.0.0:80: bind: address already in use?
This is because the port is occupied. You can use the netstat -tunlp | grep 80 command to view the process that occupies the port, and then kill the process. For example, the apache and nginx processes occupy the port, you can use the service apache2 stop and service nginx stop commands to stop the process."

Unfortunately, I cannot un-bind port 80 on my system (Synology NAS). So, is there a possibility to use another port, e.g. 81?
I tried to edit the docker-compose.yaml config file (changed ports to a) 81:80 and b) 81:81 together with editing listening port to 81 in nginx default.conf).
However, only the front end loads on port 3000, and there seems to be no connection to the backend (install screen shows animation forever). Port 81 seems to be unreachable, it results after a few minutes in 504 Gateway Time-out nginx/1.27.0

Btw, all the containers are up and successfully running.

[patryk20120]

Well I can confirm that changing this line https://github.com/langgenius/dify/blob/main/docker/docker-compose.yaml#L477 to e.g. - "8089:80" works fine for me. No other changes required.

[Sarmingsteiner]

Thanks @patryk20120 - so it must be some other issue. Guess it has something to do with Synology NAS and its Docker filesystem.
I had to create the mapped directories (volumes) according to docker-compose.yaml
manually, and they are nested in another directory (not directly below root), e.g. /volume1/docker/volumes/app/storage

[Sarmingsteiner]

Docker version is 20.10.23

[Sarmingsteiner]

So, I checked the logs.

1. In the worker container there seems to be an error relating to redis.
   According to netstat, port 6379 is not bound.

2024/06/04 18:51:50 | stderr |  
2024/06/04 18:51:50 | stderr | Trying again in 4.00 seconds... (2/100)
2024/06/04 18:51:50 | stderr | [2024-06-04 16:51:50,979: ERROR/MainProcess] consumer: Cannot connect to redis://:**@redis:6379/1: Timeout connecting to server.
2024/06/04 18:49:41 | stderr |  
2024/06/04 18:49:41 | stderr | Trying again in 2.00 seconds... (1/100)
2024/06/04 18:49:41 | stderr | [2024-06-04 16:49:41,699: ERROR/MainProcess] consumer: Cannot connect to redis://:**@redis:6379/1: Timeout connecting to server.

2. However, the redis container seems to be fine:

2024/06/04 18:45:35 | stdout | 1:M 04 Jun 2024 16:45:34.888 * Ready to accept connections
-- | -- | --
2024/06/04 18:45:35 | stdout | 1:M 04 Jun 2024 16:45:34.888 * DB loaded from disk: 0.000 seconds
2024/06/04 18:45:35 | stdout | 1:M 04 Jun 2024 16:45:34.888 # Done loading RDB, keys loaded: 0, keys expired: 0.
2024/06/04 18:45:35 | stdout | 1:M 04 Jun 2024 16:45:34.888 * RDB memory usage when created 0.77 Mb
2024/06/04 18:45:35 | stdout | 1:M 04 Jun 2024 16:45:34.888 * RDB age 125 seconds
2024/06/04 18:45:35 | stdout | 1:M 04 Jun 2024 16:45:34.888 * Loading RDB produced by version 6.2.14
2024/06/04 18:45:35 | stdout | 1:M 04 Jun 2024 16:45:34.887 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
2024/06/04 18:45:35 | stdout | 1:M 04 Jun 2024 16:45:34.887 # Server initialized
2024/06/04 18:45:35 | stdout | 1:M 04 Jun 2024 16:45:34.887 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
2024/06/04 18:45:35 | stdout | 1:M 04 Jun 2024 16:45:34.887 * Running mode=standalone, port=6379.
2024/06/04 18:45:35 | stdout | 1:M 04 Jun 2024 16:45:34.887 * monotonic clock: POSIX clock_gettime
2024/06/04 18:45:35 | stdout | 1:C 04 Jun 2024 16:45:34.886 # Configuration loaded
2024/06/04 18:45:35 | stdout | 1:C 04 Jun 2024 16:45:34.886 # Redis version=6.2.14, bits=64, commit=00000000, modified=0, pid=1, just started
2024/06/04 18:45:34 | stdout | 1:C 04 Jun 2024 16:45:34.886 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo

3. In the API container there seems to be an error related to the PostgreSQL database.
   According to netstat, port 5432 is bound.

2024/06/04 20:12:21 | stderr | None of PyTorch, TensorFlow >= 2.0, or Flax have been found. Models won't be available and only tokenizers, configuration and file/data utilities can be used.
-- | -- | --
2024/06/04 20:12:18 | stdout | Running migrations
2024/06/04 20:12:02 | stderr | (Background on this error at: https://sqlalche.me/e/20/e3q8)
2024/06/04 20:12:02 | stderr |  
2024/06/04 20:12:02 | stderr | Is the server running on that host and accepting TCP/IP connections?
2024/06/04 20:12:02 | stderr | sqlalchemy.exc.OperationalError: (psycopg2.OperationalError) connection to server at "db" (172.28.0.3), port 5432 failed: Connection timed out
2024/06/04 20:12:02 | stderr | conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
2024/06/04 20:12:02 | stderr | File "/usr/local/lib/python3.10/site-packages/psycopg2/__init__.py", line 122, in connect
2024/06/04 20:12:02 | stderr | return self.loaded_dbapi.connect(*cargs, **cparams)
2024/06/04 20:12:02 | stderr | File "/usr/local/lib/python3.10/site-packages/sqlalchemy/engine/default.py", line 620, in connect
2024/06/04 20:12:02 | stderr | return dialect.connect(*cargs, **cparams)

4. However, the DB container (PostgreSQL) seems to be in order:

2024/06/04 18:50:37 | stderr | 2024-06-04 16:50:37.951 UTC [34] LOG:  checkpoint complete: wrote 3 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.001 s, sync=0.415 s, total=1.274 s; sync files=2, longest=0.271 s, average=0.208 s; distance=0 kB, estimate=0 kB
2024/06/04 18:50:36 | stderr | 2024-06-04 16:50:36.677 UTC [34] LOG:  checkpoint starting: time
2024/06/04 18:45:37 | stderr | 2024-06-04 16:45:37.323 UTC [1] LOG:  database system is ready to accept connections
2024/06/04 18:45:36 | stderr | 2024-06-04 16:45:36.588 UTC [36] LOG:  database system was shut down at 2024-06-04 16:43:30 UTC
2024/06/04 18:45:35 | stderr | 2024-06-04 16:45:35.653 UTC [1] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2024/06/04 18:45:34 | stderr | 2024-06-04 16:45:34.838 UTC [1] LOG:  listening on IPv6 address "::", port 5432
2024/06/04 18:45:34 | stderr | 2024-06-04 16:45:34.838 UTC [1] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2024/06/04 18:45:34 | stderr | 2024-06-04 16:45:34.838 UTC [1] LOG:  starting PostgreSQL 15.7 on x86_64-pc-linux-musl, compiled by gcc (Alpine 13.2.1_git20240309) 13.2.1 20240309, 64-bit
2024/06/04 18:45:30 | stdout |  
2024/06/04 18:45:30 | stdout | PostgreSQL Database directory appears to contain a database; Skipping initialization
2024/06/04 18:45:30 | stdout

So, does anybody have an idea what could be wrong?

[patryk20120]

Have you changed anything else in docker-compose file?

[Sarmingsteiner]

No, but I encountered another strange issue:

I reinstalled everything on my Windows 10 notebook with Docker Desktop.

• When using WSL2 as the virtualization environment, Dify finally started without any issues.
• However, when I switched to Hyper-V, Dify did not start after a complete new installation and I encountered the well-known error:

Is the server running on that host and accepting TCP/IP connections?
sqlalchemy.exc.OperationalError: (psycopg2.OperationalError) connection to server at "db" (172.28.0.3), port 5432 failed: Connection timed out

[patryk20120]

Well there must have been an network bug or error using Hyper-V