I have deployed a completely stock helm deployment of erpnext. (version v7.0.77 which is latest as of right now). And it seems like the gunicorn container is crashlooping with no indication as to why. I have added the logs below:
[2024-06-04 13:06:08 +0000] [1] [INFO] Starting gunicorn 22.0.0
[2024-06-04 13:06:08 +0000] [1] [INFO] Listening at: http://0.0.0.0:8000 (1)
[2024-06-04 13:06:08 +0000] [1] [INFO] Using worker: gthread
[2024-06-04 13:06:08 +0000] [7] [INFO] Booting worker with pid: 7
[2024-06-04 13:06:08 +0000] [8] [INFO] Booting worker with pid: 8
[2024-06-04 13:06:33 +0000] [1] [INFO] Handling signal: term
[2024-06-04 13:06:34 +0000] [7] [INFO] Worker exiting (pid: 7)
[2024-06-04 13:06:34 +0000] [8] [INFO] Worker exiting (pid: 8)
[2024-06-04 13:06:34 +0000] [1] [INFO] Shutting down: Master
Is there some way I can increase the logging verbosity, or something?
The nginx container is crashlooping as well, but I assume that’s because the upstream is unhealthy.
All other containers are healthy, however some are logging potential issues:
MariaDB:
2024-06-04 13:10:06 669 [Warning] Aborted connection 669 to db: 'unconnected' user: 'unauthenticated' host: '2602:fe19:4000:3::56b' (This connection closed normally without authentication)
redis-cache-master
1:M 04 Jun 2024 13:08:34.316 # Possible SECURITY ATTACK detected. It looks like somebody is sending POST or Host: commands to Redis. This is likely due to an attacker attempting to use Cross Protocol Scripting to compromise your Redis instance. Connection aborted.
redis-queue-master
1:M 04 Jun 2024 13:04:48.807 # Possible SECURITY ATTACK detected. It looks like somebody is sending POST or Host: commands to Redis. This is likely due to an attacker attempting to use Cross Protocol Scripting to compromise your Redis instance. Connection aborted.