I tried setting up Odoo and Postgres containers in azure using docker-compose, when running them I have an issue with the server closing the connection,
That's what I get from the log at the start of the Postgres container:
The files belonging to this database system will be owned by the user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale "en_US.utf8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".
Data page checksums are disabled.
fixing permissions on existing directory /tmp ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... Etc/UTC
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok
Success. You can now start the database server using:
pg_ctl -D /tmp -l logfile start
initdb: warning: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.
waiting for server to start....2022-10-17 14:27:53.717 UTC [758] LOG: starting PostgreSQL 13.8 (Debian 13.8-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
2022-10-17 14:27:53.735 UTC [758] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2022-10-17 14:27:53.761 UTC [759] LOG: database system was shut down at 2022-10-17 14:27:46 UTC
2022-10-17 14:27:53.774 UTC [758] LOG: database system is ready to accept connections
done
server started
/usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/*
waiting for server to shut down...2022-10-17 14:27:53.985 UTC [758] LOG: received fast shutdown request
.2022-10-17 14:27:53.999 UTC [758] LOG: aborting any active transactions
2022-10-17 14:27:54.006 UTC [758] LOG: background worker "logical replication launcher" (PID 765) exited with exit code 1
2022-10-17 14:27:54.007 UTC [760] LOG: shutting down
2022-10-17 14:27:54.090 UTC [758] LOG: database system is shut down
done
server stopped
PostgreSQL init process complete; ready for start up.
2022-10-17 14:27:54.241 UTC [696] LOG: starting PostgreSQL 13.8 (Debian 13.8-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
2022-10-17 14:27:54.242 UTC [696] LOG: listening on IPv4 address "0.0.0.0", port 5432
2022-10-17 14:27:54.242 UTC [696] LOG: listening on IPv6 address "::", port 5432
2022-10-17 14:27:54.267 UTC [696] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2022-10-17 14:27:54.307 UTC [770] LOG: database system was shut down at 2022-10-17 14:27:54 UTC
2022-10-17 14:27:54.317 UTC [696] LOG: database system is ready to accept connections
Then that is the resulting logs from the Odoo container :
2022-10-17 14:27:02,735 445 INFO ? odoo: Odoo version 15.0-20221012
2022-10-17 14:27:02,735 445 INFO ? odoo: Using configuration file at
/etc/odoo/odoo.conf 2022-10-17 14:27:02,735 445 INFO ? odoo: addons
paths: ['/usr/lib/python3/dist-packages/odoo/addons',
'/var/lib/odoo/addons/15.0', '/mnt/extra-addons'] 2022-10-17
14:27:02,735 445 INFO ? odoo: database: odoo#db:5432 2022-10-17
14:27:02,960 445 INFO ? odoo.addons.base.models.ir_actions_report:
Will use the Wkhtmltopdf binary at /usr/local/bin/wkhtmltopdf
2022-10-17 14:27:03,367 445 INFO ? odoo.service.server: HTTP service
(werkzeug) running on localhost:8069 Exception in thread
odoo.service.cron.cron0: Traceback (most recent call last): File
"/usr/lib/python3/dist-packages/odoo/service/server.py", line 445, in
cron_thread
pg_conn.poll() psycopg2.OperationalError: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
During handling of the above exception, another exception occurred:
Traceback (most recent call last): File
"/usr/lib/python3.9/threading.py", line 954, in _bootstrap_inner
self.run() File "/usr/lib/python3.9/threading.py", line 892, in run
self._target(*self._args, **self._kwargs) File "/usr/lib/python3/dist-packages/odoo/service/server.py", line 473, in
target
self.cron_thread(i) File "/usr/lib/python3/dist-packages/odoo/service/server.py", line 457, in
cron_thread
thread.start_time = None File "/usr/lib/python3/dist-packages/odoo/sql_db.py", line 162, in exit
self.close() File "", line 2, in close File "/usr/lib/python3/dist-packages/odoo/sql_db.py", line 90, in check
return f(self, *args, **kwargs) File "/usr/lib/python3/dist-packages/odoo/sql_db.py", line 379, in close
return self._close(False) File "/usr/lib/python3/dist-packages/odoo/sql_db.py", line 405, in _close
self.rollback() File "", line 2, in rollback File "/usr/lib/python3/dist-packages/odoo/sql_db.py", line 90, in
check
return f(self, *args, **kwargs) File "/usr/lib/python3/dist-packages/odoo/sql_db.py", line 484, in rollback
result = self._cnx.rollback() psycopg2.InterfaceError: connection already closed Exception in thread odoo.service.cron.cron1: Traceback
(most recent call last): File
"/usr/lib/python3/dist-packages/odoo/service/server.py", line 445, in
cron_thread
pg_conn.poll() psycopg2.OperationalError: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
During handling of the above exception, another exception occurred:
Traceback (most recent call last): File
"/usr/lib/python3.9/threading.py", line 954, in _bootstrap_inner
self.run() File "/usr/lib/python3.9/threading.py", line 892, in run
self._target(*self._args, **self._kwargs) File "/usr/lib/python3/dist-packages/odoo/service/server.py", line 473, in
target
self.cron_thread(i) File "/usr/lib/python3/dist-packages/odoo/service/server.py", line 457, in
cron_thread
thread.start_time = None File "/usr/lib/python3/dist-packages/odoo/sql_db.py", line 162, in exit
self.close() File "", line 2, in close File "/usr/lib/python3/dist-packages/odoo/sql_db.py", line 90, in check
return f(self, *args, **kwargs) File "/usr/lib/python3/dist-packages/odoo/sql_db.py", line 379, in close
return self._close(False) File "/usr/lib/python3/dist-packages/odoo/sql_db.py", line 405, in _close
self.rollback() File "", line 2, in rollback File "/usr/lib/python3/dist-packages/odoo/sql_db.py", line 90, in
check
return f(self, *args, **kwargs) File "/usr/lib/python3/dist-packages/odoo/sql_db.py", line 484, in rollback
result = self._cnx.rollback() psycopg2.InterfaceError: connection already closed
When I check the postgres logs again cause the connection was open the
1st time, i get this from it (after restart) :
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale "en_US.utf8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".
Data page checksums are disabled.
fixing permissions on existing directory /tmp ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default time zone ... Etc/UTC
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
My docker-compose.yml :
version: '3.2'
services:
db:
image: registryodoo.azurecr.io/samples/postgres:13
volumes:
- db:/var/lib/postgresql/data/pgdata
deploy:
restart_policy:
condition: always
ports:
- "5432:5432"
environment:
POSTGRES_PASSWORD: odoo
POSTGRES_DB: postgres
POSTGRES_USER: odoo
PGDATA: /tmp
healthcheck:
test: ["CMD-SHELL", "pg_isready -U odoo"]
interval: 5s
timeout: 5s
retries: 5
odoocontainer:
depends_on:
db:
condition: service_healthy
image: registryodoo.azurecr.io/samples/odoo:latest
volumes:
- data:/var/lib/odoo
- extra-addons:/mnt/extra-addons
ports:
- 8069:8069
deploy:
restart_policy:
condition: always
environment:
HOST: db
USER: odoo
PASSWORD: odoo
volumes:
data:
driver: azure_file
driver_opts:
share_name: datafileshare
storage_account_name: odooaccount1
db:
driver: azure_file
driver_opts:
share_name: dbfileshare
storage_account_name: odooaccount1
extra-addons:
driver: azure_file
driver_opts:
share_name: odoofileshare
storage_account_name: odooaccount1
Can't figure what's the origin issue and how to solve it
Related
I am running a Flask app on a Ubuntu Linode Server using Gunicorn to serve the app and nginx as a reverse proxy.
I have one app running successfully, but I have a second app where I'm running in to the following problem.
What does work
when I run FLASK_APP=tester.py python3 -m flask run
This works, tester.py runs the app bound to 0.0.0.0 on port 5100 and I can access it from my browser.
when I run gunicorn --bind 0.0.0.0:5100 wsgi:app
This also works, as my wsgi.py imports my app object making it accessible for wsgi
Useful details
which python gives me /usr/bin/python
which pip gives /usr/bin/pip and which pip3 gives /usr/bin/pip3
which python3 gives me /usr/bin/python3
which gunicorn gives me /usr/bin/gunicorn
I am not using a virtual environment since boths app have near identical dependencies
What's not working
I created a service for forwarding traffic with nginx with:
/etc/systemd/system/testpad.service
[Unit]
# specifies metadata and dependencies
Description=Gunicorn instance to serve myproject
After=network.target
# tells the init system to only start this after the networking target has been reached
# We will give our regular user account ownership of the process since it owns all of the relevant files
[Service]
# Service specify the user and group under which our process will run.
User=www-data
# give group ownership to the www-data group so that Nginx can communicate easily with the Gunicorn processes.
Group=www-data
# We'll then map out the working directory and set the PATH environmental variable so that the init system knows where our the executabl>
WorkingDirectory=/home/xxx/xxx
# We'll then specify the commanded to start the service
ExecStart=/usr/bin/gunicorn --bind unix:testpad.sock --access-logfile /home/xxx/xxx/accesslog --error-logfile /home/xxx/xxx/errorlog -m 007 wsgi:app
# This will tell systemd what to link this service to if we enable it to start at boot. We want this service to start when the regular m>
[Install]
WantedBy=multi-user.target
when I start the service it runs for a second then I get this from sudo systemctl status testpad
testpad.service - Gunicorn instance to serve myproject
Loaded: loaded (/etc/systemd/system/testpad.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Mon 2021-09-06 15:47:59 UTC; 16min ago
Process: 655575 ExecStart=/usr/bin/gunicorn --bind unix:testpad.sock --access-logfile /home/xxx/xxx/acces>
Main PID: 655575 (code=exited, status=1/FAILURE)
Sep 06 15:47:54 microportalbeta systemd[1]: Started Gunicorn instance to serve myproject.
Sep 06 15:47:59 microportalbeta systemd[1]: testpad.service: Main process exited, code=exited, status=1/FAILURE
Sep 06 15:47:59 microportalbeta systemd[1]: testpad.service: Failed with result 'exit-code'.
so when I cat errorlog I get
[2021-09-06 15:21:31 +0000] [655222] [INFO] Worker exiting (pid: 655222)
[2021-09-06 15:21:31 +0000] [655223] [ERROR] Exception in worker process
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/gunicorn/arbiter.py", line 589, in spawn_worker
worker.init_process()
File "/usr/lib/python3/dist-packages/gunicorn/workers/base.py", line 134, in init_process
self.load_wsgi()
File "/usr/lib/python3/dist-packages/gunicorn/workers/base.py", line 146, in load_wsgi
self.wsgi = self.app.wsgi()
File "/usr/lib/python3/dist-packages/gunicorn/app/base.py", line 67, in wsgi
self.callable = self.load()
File "/usr/lib/python3/dist-packages/gunicorn/app/wsgiapp.py", line 58, in load
return self.load_wsgiapp()
File "/usr/lib/python3/dist-packages/gunicorn/app/wsgiapp.py", line 48, in load_wsgiapp
return util.import_app(self.app_uri)
File "/usr/lib/python3/dist-packages/gunicorn/util.py", line 384, in import_app
mod = importlib.import_module(module)
File "/usr/lib/python3.9/importlib/__init__.py", line 127, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
File "<frozen importlib._bootstrap>", line 1030, in _gcd_import
File "<frozen importlib._bootstrap>", line 1007, in _find_and_load
File "<frozen importlib._bootstrap>", line 986, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 680, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 855, in exec_module
File "<frozen importlib._bootstrap>", line 228, in _call_with_frames_removed
File "/home/xxx/xxx/wsgi.py", line 1, in <module>
from run import app
File "/home/xxx/xxx/run.py", line 1, in <module>
from genedflask import create_app, db
File "/home/xxx/xxx/xxx/__init__.py", line 5, in <module>
from flask_login import LoginManager
ModuleNotFoundError: No module named 'flask_login'
[2021-09-06 15:21:31 +0000] [655223] [INFO] Worker exiting (pid: 655223)
[2021-09-06 15:21:32 +0000] [655220] [WARNING] Worker with pid 655223 was terminated due to signal 15
[2021-09-06 15:21:32 +0000] [655220] [WARNING] Worker with pid 655222 was terminated due to signal 15
[2021-09-06 15:21:32 +0000] [655220] [INFO] Shutting down: Master
[2021-09-06 15:21:32 +0000] [655220] [INFO] Reason: Worker failed to boot.
[2021-09-06 15:23:34 +0000] [655249] [INFO] Starting gunicorn 20.1.0
[2021-09-06 15:23:34 +0000] [655249] [ERROR] Retrying in 1 second.
[2021-09-06 15:23:35 +0000] [655249] [ERROR] Retrying in 1 second.
[2021-09-06 15:23:36 +0000] [655249] [ERROR] Retrying in 1 second.
[2021-09-06 15:23:37 +0000] [655249] [ERROR] Retrying in 1 second.
[2021-09-06 15:23:38 +0000] [655249] [ERROR] Retrying in 1 second.
[2021-09-06 15:23:39 +0000] [655249] [ERROR] Can't connect to testpad.sock
[2021-09-06 15:28:44 +0000] [655315] [INFO] Starting gunicorn 20.1.0
[2021-09-06 15:28:44 +0000] [655315] [ERROR] Retrying in 1 second.
[2021-09-06 15:28:45 +0000] [655315] [ERROR] Retrying in 1 second.
[2021-09-06 15:28:46 +0000] [655315] [ERROR] Retrying in 1 second.
[2021-09-06 15:28:47 +0000] [655315] [ERROR] Retrying in 1 second.
[2021-09-06 15:28:48 +0000] [655315] [ERROR] Retrying in 1 second.
[2021-09-06 15:28:49 +0000] [655315] [ERROR] Can't connect to testpad.sock
[2021-09-06 15:31:09 +0000] [655348] [INFO] Starting gunicorn 20.1.0
[2021-09-06 15:31:09 +0000] [655348] [ERROR] Retrying in 1 second.
[2021-09-06 15:31:10 +0000] [655348] [ERROR] Retrying in 1 second.
[2021-09-06 15:31:11 +0000] [655348] [ERROR] Retrying in 1 second.
[2021-09-06 15:31:12 +0000] [655348] [ERROR] Retrying in 1 second.
[2021-09-06 15:31:13 +0000] [655348] [ERROR] Retrying in 1 second.
[2021-09-06 15:31:14 +0000] [655348] [ERROR] Can't connect to testpad.sock
[2021-09-06 15:33:34 +0000] [655387] [INFO] Starting gunicorn 20.1.0
[2021-09-06 15:33:34 +0000] [655387] [ERROR] Retrying in 1 second.
[2021-09-06 15:33:35 +0000] [655387] [ERROR] Retrying in 1 second.
[2021-09-06 15:33:36 +0000] [655387] [ERROR] Retrying in 1 second.
[2021-09-06 15:33:37 +0000] [655387] [ERROR] Retrying in 1 second.
[2021-09-06 15:33:38 +0000] [655387] [ERROR] Retrying in 1 second.
[2021-09-06 15:33:39 +0000] [655387] [ERROR] Can't connect to testpad.sock
[2021-09-06 15:47:54 +0000] [655575] [INFO] Starting gunicorn 20.1.0
[2021-09-06 15:47:54 +0000] [655575] [ERROR] Retrying in 1 second.
[2021-09-06 15:47:55 +0000] [655575] [ERROR] Retrying in 1 second.
[2021-09-06 15:47:56 +0000] [655575] [ERROR] Retrying in 1 second.
[2021-09-06 15:47:57 +0000] [655575] [ERROR] Retrying in 1 second.
[2021-09-06 15:47:58 +0000] [655575] [ERROR] Retrying in 1 second.
[2021-09-06 15:47:59 +0000] [655575] [ERROR] Can't connect to testpad.sock
Not sure why it is not finding flask-login as it is installed under pip and pip3 globally, and is visible when I run pip3 list or pip list.
I assume that once I overcome this hurdle then the testpad.sock file should auto create as it did with my previous app. Most people with this problem I found it was an issue with gunicorn looking at the global environment when people installed dependencies in a virtual environment, which I am not doing in this circumstance.
Any suggestions?
Update
I never did figure out why it could not find the libraries when ran as a service, I even set the PYTHONPATH variable to see if that would help.
What I did do is give up on running as a service and instead just ran the application as a background process on port 8000 and just directed nginx to forward traffic there, and that worked.
I have been struggling for some days now to deploy an Azure App Service with two minimalist Docker containers.
My first image is a basic PostgreSQL image and my second image is built with the following Dockerfile:
FROM python:3.7
RUN pip install streamlit
COPY app.py /streamlit-docker/
WORKDIR /streamlit-docker/
CMD streamlit run app.py
and where app.py is:
import streamlit as st
st.write('Hello world')
The docker-compose.yml file I use for creating my Azure App service is the following:
version: '3.3'
services:
db:
image: atestcr.azurecr.io/postgres:latest
environment:
POSTGRES_PASSWORD: postgres
app:
image: atestcr.azurecr.io/my_app:latest
ports:
- '8501:8501'
I get an 'Application Error' whenever I try to access the webapp URL. However, when I deploy this app with a single docker container, using this docker-compose.yml:
version: '3.3'
services:
app:
image: atestcr.azurecr.io/my_app:latest
ports:
- '8501:8501'
everything works fine.
Here is a GitHub repo to recreate the bug.
These are the Azure logs:
2021-08-09T17:29:34.382Z INFO - Starting multi-container app..
2021-08-09T17:29:35.089Z INFO - Pulling image: atestcr.azurecr.io/postgres:latest
2021-08-09T17:29:35.313Z INFO - latest Pulling from postgres
2021-08-09T17:29:35.315Z INFO - Digest: sha256:b6df1345afa5990ea32866e5c331eefbf2e30a05f2a715c3a9691a6cb18fa253
2021-08-09T17:29:35.317Z INFO - Status: Image is up to date for atestcr.azurecr.io/postgres:latest
2021-08-09T17:29:35.319Z INFO - Pull Image successful, Time taken: 0 Minutes and 0 Seconds
2021-08-09T17:29:35.335Z INFO - Starting container for site
2021-08-09T17:29:35.335Z INFO - docker run -d -p 8477:5432 --name testapp32_db_0_6662435d -e WEBSITES_ENABLE_APP_SERVICE_STORAGE=false -e WEBSITE_SITE_NAME=testapp32 -e WEBSITE_AUTH_ENABLED=False -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_HOSTNAME=testapp32.azurewebsites.net -e WEBSITE_INSTANCE_ID=42c09ff46e6c54cb467d28e88f2ab5b1e8971ee4daf2e883f44401bde67fe89f -e HTTP_LOGGING_ENABLED=1 atestcr.azurecr.io/postgres:latest
2021-08-09T17:29:35.781Z INFO - Pulling image: atestcr.azurecr.io/my_app:latest
2021-08-09T17:29:35.984Z INFO - latest Pulling from my_app
2021-08-09T17:29:35.987Z INFO - Digest: sha256:659937a52a6223b938b3d429901ab8648497870bf8068b5dcc05816050db5eaf
2021-08-09T17:29:35.988Z INFO - Status: Image is up to date for atestcr.azurecr.io/my_app:latest
2021-08-09T17:29:35.993Z INFO - Pull Image successful, Time taken: 0 Minutes and 0 Seconds
2021-08-09T17:29:36.014Z INFO - Starting container for site
2021-08-09T17:29:36.014Z INFO - docker run -d -p 0:8501 --name testapp32_app_0_6662435d -e WEBSITES_ENABLE_APP_SERVICE_STORAGE=false -e WEBSITE_SITE_NAME=testapp32 -e WEBSITE_AUTH_ENABLED=False -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_HOSTNAME=testapp32.azurewebsites.net -e WEBSITE_INSTANCE_ID=42c09ff46e6c54cb467d28e88f2ab5b1e8971ee4daf2e883f44401bde67fe89f -e HTTP_LOGGING_ENABLED=1 atestcr.azurecr.io/my_app:latest
2021-08-09T17:33:26.741Z ERROR - multi-container unit was not started successfully
2021-08-09T17:33:26.846Z INFO - Container logs from testapp32_db_0_6662435d = 2021-08-09T17:29:40.459721366Z The files belonging to this database system will be owned by user "postgres".
2021-08-09T17:29:40.491740899Z This user must also own the server process.
2021-08-09T17:29:40.493019808Z
2021-08-09T17:29:40.497263739Z The database cluster will be initialized with locale "en_US.utf8".
2021-08-09T17:29:40.502456876Z The default database encoding has accordingly been set to "UTF8".
2021-08-09T17:29:40.503203182Z The default text search configuration will be set to "english".
2021-08-09T17:29:40.503218482Z
2021-08-09T17:29:40.503223282Z Data page checksums are disabled.
2021-08-09T17:29:40.506809008Z
2021-08-09T17:29:40.521275113Z fixing permissions on existing directory /var/lib/postgresql/data ... ok
2021-08-09T17:29:40.523912632Z creating subdirectories ... ok
2021-08-09T17:29:40.525237242Z selecting dynamic shared memory implementation ... posix
2021-08-09T17:29:40.642905697Z selecting default max_connections ... 100
2021-08-09T17:29:40.733900958Z selecting default shared_buffers ... 128MB
2021-08-09T17:29:41.039050775Z selecting default time zone ... Etc/UTC
2021-08-09T17:29:41.047757638Z creating configuration files ... ok
2021-08-09T17:29:44.416903507Z running bootstrap script ... ok
2021-08-09T17:29:50.023628737Z performing post-bootstrap initialization ... ok
2021-08-09T17:30:04.217544961Z syncing data to disk ... ok
2021-08-09T17:30:04.218321267Z
2021-08-09T17:30:04.219189873Z initdb: warning: enabling "trust" authentication for local connections
2021-08-09T17:30:04.219206473Z You can change this by editing pg_hba.conf or using the option -A, or
2021-08-09T17:30:04.219223973Z --auth-local and --auth-host, the next time you run initdb.
2021-08-09T17:30:04.219491175Z
2021-08-09T17:30:04.219513275Z Success. You can now start the database server using:
2021-08-09T17:30:04.219519575Z
2021-08-09T17:30:04.219523675Z pg_ctl -D /var/lib/postgresql/data -l logfile start
2021-08-09T17:30:04.219527775Z
2021-08-09T17:30:08.340584036Z waiting for server to start.......2021-08-09 17:30:08.340 UTC [44] LOG: starting PostgreSQL 13.3 (Debian 13.3-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
2021-08-09T17:30:08.478247580Z 2021-08-09 17:30:08.410 UTC [44] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2021-08-09T17:30:08.680599067Z 2021-08-09 17:30:08.680 UTC [45] LOG: database system was shut down at 2021-08-09 17:29:49 UTC
2021-08-09T17:30:08.753589768Z 2021-08-09 17:30:08.753 UTC [44] LOG: database system is ready to accept connections
2021-08-09T17:30:08.755965684Z done
2021-08-09T17:30:08.760382514Z server started
2021-08-09T17:30:09.790821978Z
2021-08-09T17:30:09.799723839Z /usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/*
2021-08-09T17:30:09.802079455Z
2021-08-09T17:30:09.840304817Z 2021-08-09 17:30:09.834 UTC [44] LOG: received fast shutdown request
2021-08-09T17:30:09.862102366Z waiting for server to shut down....2021-08-09 17:30:09.861 UTC [44] LOG: aborting any active transactions
2021-08-09T17:30:09.950488072Z 2021-08-09 17:30:09.950 UTC [44] LOG: background worker "logical replication launcher" (PID 51) exited with exit code 1
2021-08-09T17:30:09.954360498Z 2021-08-09 17:30:09.950 UTC [46] LOG: shutting down
2021-08-09T17:30:13.063848848Z ...2021-08-09 17:30:13.063 UTC [44] LOG: database system is shut down
2021-08-09T17:30:13.138558463Z done
2021-08-09T17:30:13.140082774Z server stopped
2021-08-09T17:30:13.144102302Z
2021-08-09T17:30:13.162430928Z PostgreSQL init process complete; ready for start up.
2021-08-09T17:30:13.165654351Z
2021-08-09T17:30:14.083504086Z 2021-08-09 17:30:13.992 UTC [1] LOG: starting PostgreSQL 13.3 (Debian 13.3-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
2021-08-09T17:30:14.084760295Z 2021-08-09 17:30:14.011 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
2021-08-09T17:30:14.084774095Z 2021-08-09 17:30:14.015 UTC [1] LOG: listening on IPv6 address "::", port 5432
2021-08-09T17:30:14.084779495Z 2021-08-09 17:30:14.082 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2021-08-09T17:30:14.156076187Z 2021-08-09 17:30:14.132 UTC [63] LOG: database system was shut down at 2021-08-09 17:30:12 UTC
2021-08-09T17:30:14.198749982Z 2021-08-09 17:30:14.176 UTC [1] LOG: database system is ready to accept connections
2021-08-09T17:30:15.006882460Z 2021-08-09 17:30:14.998 UTC [70] LOG: invalid length of startup packet
2021-08-09T17:30:16.112919592Z 2021-08-09 17:30:16.112 UTC [71] LOG: invalid length of startup packet
2021-08-09T17:30:17.178350344Z 2021-08-09 17:30:17.174 UTC [72] LOG: invalid length of startup packet
...
2021-08-09T17:33:25.735293291Z 2021-08-09 17:33:25.735 UTC [260] LOG: invalid length of startup packet
2021-08-09T17:33:29.142Z INFO - Container logs from testapp32_app_0_6662435d = 2021-08-09T17:30:24.010212694Z
2021-08-09T17:30:24.011085300Z You can now view your Streamlit app in your browser.
2021-08-09T17:30:24.011101800Z
2021-08-09T17:30:24.012092107Z Network URL: http://172.16.232.3:8501
2021-08-09T17:30:24.012855612Z External URL: http://20.40.148.207:8501
2021-08-09T17:30:24.013407416Z
2021-08-09T17:33:36.002Z INFO - Stopping site testapp32 because it failed during startup.
It's worth noting your shared example doesn't work because your docker-compose.yml is using your own private container registries.
However, tinkering around the edges I have managed to get your dummy example working with changes to the following files:
Your app dockerfile:
FROM python:3.7
RUN pip install streamlit
COPY app.py /streamlit-docker/
WORKDIR /streamlit-docker/
EXPOSE 80
CMD streamlit run app.py --server.port 80
And adjusting your docker-compose.yml
version: '3.3'
services:
db:
image: postgis/postgis:13-master
environment:
- POSTGRES_DB=counterfactualcovid
- POSTGRES_USER=django
- POSTGRES_PASSWORD=django
app:
image: testazurecontainerregistryajc.azurecr.io/mcmegaapp:latest
ports:
- '80:80'
Ignore the fact i've used a generic postgres docker image and my own private container registry for the images and you'll see the key changes are:
in the Dockerfile exposing port 80, and adding --server.port 80 to the streamlit CMD call
in the docker-compose.yml setting the port forwarding to 80:80
I /think/ your issues arise from the preview limitations for the multi-container web apps feature, so setting everything to work via port 80 appears to resolve this.
All was fine until "something". After that "something", I could use docker and docker-compose with sudo but without it the docker would hang indefinitely and the docker-compose would return connection stack traces.
Doesn't work:
Running docker without sudo hangs indefinitely. Temporarily fixed by exporting DOCKER_HOST=tcp://127.0.0.1:2375.
docker-compose without sudo returns with connection refused. It's not about connecting to specific container but for all basic commands such as docker-compose ps.
Proof that user belongs to docker group:
kretyn#junk$ groups kretyn
kretyn : kretyn adm cdrom sudo dip plugdev lpadmin lxd sambashare docker
Solution hints
I had a docker context activated that was pointing at existing but inactive host. Removing that context and unsetting DOCKER_HOST allowed the docker command to work correctly. That's a surprise since I reinstalled (purged everything I could find) the docker before writing this question.
Removing context isn't sufficient. Docker Compose required explicit docker context use default otherwise it wouldn't understand.
The problem with docker-compose ps is still present.
Stack trace on docker-compose
kretyn#junk$ docker-compose ps
Traceback (most recent call last):
File "urllib3/connection.py", line 159, in _new_conn
File "urllib3/util/connection.py", line 84, in create_connection
File "urllib3/util/connection.py", line 74, in create_connection
ConnectionRefusedError: [Errno 111] Connection refused
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "urllib3/connectionpool.py", line 670, in urlopen
File "urllib3/connectionpool.py", line 392, in _make_request
File "http/client.py", line 1255, in request
File "http/client.py", line 1301, in _send_request
File "http/client.py", line 1250, in endheaders
File "http/client.py", line 1010, in _send_output
File "http/client.py", line 950, in send
File "urllib3/connection.py", line 187, in connect
File "urllib3/connection.py", line 171, in _new_conn
urllib3.exceptions.NewConnectionError: <urllib3.connection.HTTPConnection object at 0x7f762c4e3e20>: Failed to establish a new connection: [Errno 111] Connection refused
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "requests/adapters.py", line 439, in send
File "urllib3/connectionpool.py", line 726, in urlopen
File "urllib3/util/retry.py", line 446, in increment
urllib3.exceptions.MaxRetryError: HTTPConnectionPool(host='127.0.0.1', port=2375): Max retries exceeded with url: /version (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f762c4e3e20>: Failed to establish a new connection: [Errno 111] Connection refused'))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "docker/api/client.py", line 214, in _retrieve_server_version
File "docker/api/daemon.py", line 181, in version
File "docker/utils/decorators.py", line 46, in inner
File "docker/api/client.py", line 237, in _get
File "requests/sessions.py", line 543, in get
File "requests/sessions.py", line 530, in request
File "requests/sessions.py", line 643, in send
File "requests/adapters.py", line 516, in send
requests.exceptions.ConnectionError: HTTPConnectionPool(host='127.0.0.1', port=2375): Max retries exceeded with url: /version (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f762c4e3e20>: Failed to establish a new connection: [Errno 111] Connection refused'))
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "docker-compose", line 3, in <module>
File "compose/cli/main.py", line 80, in main
File "compose/cli/main.py", line 189, in perform_command
File "compose/cli/command.py", line 60, in project_from_options
File "compose/cli/command.py", line 152, in get_project
File "compose/cli/docker_client.py", line 41, in get_client
File "compose/cli/docker_client.py", line 170, in docker_client
File "docker/api/client.py", line 197, in __init__
File "docker/api/client.py", line 221, in _retrieve_server_version
docker.errors.DockerException: Error while fetching server API version: HTTPConnectionPool(host='127.0.0.1', port=2375): Max retries exceeded with url: /version (Caused by NewConnectionError('<urllib3.connection.HTTPConnection object at 0x7f762c4e3e20>: Failed to establish a new connection: [Errno 111] Connection refused'))
[46145] Failed to execute script docker-compose
Versions/builds
Linux distro
kretyn#junk$ uname -a
Linux junk 5.8.0-43-generic #49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Docker
kretyn#junk$ sudo docker system info
Client:
Context: default
Debug Mode: false
Plugins:
app: Docker App (Docker Inc., v0.9.1-beta3)
buildx: Build with BuildKit (Docker Inc., v0.5.1-docker)
Server:
Containers: 9
Running: 8
Paused: 0
Stopped: 1
Images: 44
Server Version: 20.10.3
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Native Overlay Diff: true
Logging Driver: json-file
Cgroup Driver: cgroupfs
Cgroup Version: 1
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 269548fa27e0089a8b8278fc4fc781d7f65a939b
runc version: ff819c7e9184c13b7c2607fe6c30ae19403a7aff
init version: de40ad0
Security Options:
apparmor
seccomp
Profile: default
Kernel Version: 5.8.0-43-generic
Operating System: Ubuntu 20.04.2 LTS
OSType: linux
Architecture: x86_64
CPUs: 12
Total Memory: 15.29GiB
Name: meland
ID: 3PE6:4AWU:LGRR:HOBJ:XUCJ:ER4H:ZEF5:MWUJ:COEG:WPK5:YH2U:FKUF
Docker Root Dir: /var/lib/docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Labels:
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
WARNING: No blkio weight support
WARNING: No blkio weight_device support
Docker-compose
kretyn#junk$ sudo docker-compose version
docker-compose version 1.28.0, build d02a7b1a
docker-py version: 4.4.1
CPython version: 3.9.0
OpenSSL version: OpenSSL 1.1.1d 10 Sep 2019
The problem was a dead context entry.
Solution
Removed the dead context named remote using docker context rm remote.
Even though docker context ls was pointing default as default, it was necessary to do docker context use default for the context to be properly updated.
As a partial fix I had previously set DOCKER_HOST to tcp://127.0.0.1:2375. After updating context the env variable had to be unset, i.e. unset DOCKER_HOST.
Lazy commands, assuming context remote:
$ docker context rm remote
$ docker context use default
$ unset DOCKER_HOST
Background
Had a remote context that was based on ssh endpoint. My ssh config was set that the name points at my domain but recently the host behind it was removed.
Interestingly, I've been "fixing" this for a while and one of the steps was to completely purge docker from my local Ubuntu host, including apt, /var/lib/docker, /etc/docker and random scripts in ~/.local/. The context, however, wasn't cleaned.
The solution by Dawid was perfect for me.
I wanna mention that even when your sudo docker context ls only shows default context, your docker context ls might show different (and potentially broken) contexts. You wanna delete them.
But the problem is that your docker ps hangs.
So before you try docker rm, you need to override the context by DOCKER_HOST=tcp://127.0.0.1:2375.
As a result, the full solution is
DOCKER_HOST=tcp://127.0.0.1:2375
docker context ls
docker context rm <broken context name>
docker context use <valid context name(maybe default?)>
unset DOCKER_HOST
and then make sure all docker commands work without sudo.
docker ps
You don't have the necessary rights to use docker or docker-compose without sudo, check the documentation.
sudo usermod -aG docker
sudo chmod +x /usr/local/bin/docker-compose
You have to restart your terminal after that.
I am trying to conecting to Cassandra with cqlsh but no able to connect while the Cassandra service is running. Below is the status of Cassandra service.
(base) kuldeep#kuldeep-OptiPlex-3050:~$ systemctl status cassandra
● cassandra.service - LSB: distributed storage system for structured data
Loaded: loaded (/etc/init.d/cassandra; generated)
Active: active (running) since Mon 2020-12-28 18:13:35 IST; 25min ago
Docs: man:systemd-sysv-generator(8)
Process: 21770 ExecStart=/etc/init.d/cassandra start (code=exited, status=0/SUCCESS)
Tasks: 52 (limit: 4915)
CGroup: /system.slice/cassandra.service
└─21858 java -ea -da:net.openhft... -XX:+UseThreadPriorities -XX:+HeapDumpOnOutOfMemoryError -Xss256k -XX:StringTableSize=1000003 -XX:+AlwaysPreTouch -XX:-Us
Dec 28 18:13:35 kuldeep-OptiPlex-3050 systemd[1]: Starting LSB: distributed storage system for structured data...
Dec 28 18:13:35 kuldeep-OptiPlex-3050 systemd[1]: Started LSB: distributed storage system for structured data.
But when I tried to connect to Cassandra with cqlsh I am getting the following error.
(base) kuldeep#kuldeep-OptiPlex-3050:~$ cqlsh
Traceback (most recent call last):
File "/usr/local/bin/cqlsh", line 115, in <module>
from cqlshlib import cqlhandling, cql3handling, pylexotron
File "/usr/lib/python2.7/dist-packages/cqlshlib/cqlhandling.py", line 22, in <module>
from cassandra.metadata import cql_keywords_reserved
ImportError: No module named cassandra.metadata
After doing some research someone suggests me to install the Cassandra-driver and I follow the same.
(base) kuldeep#kuldeep-OptiPlex-3050:~$ pip install cassandra_driver
Requirement already satisfied: cassandra_driver in ./anaconda3/lib/python3.7/site-packages (2.7.0)
Requirement already satisfied: six>=1.6 in ./anaconda3/lib/python3.7/site-packages (from cassandra_driver) (1.14.0)
Requirement already satisfied: futures in ./anaconda3/lib/python3.7/site-packages (from cassandra_driver) (3.1.1)
But again I am getting the same error.
cqlsh
Traceback (most recent call last):
File "/usr/local/bin/cqlsh", line 115, in <module>
from cqlshlib import cqlhandling, cql3handling, pylexotron
File "/usr/lib/python2.7/dist-packages/cqlshlib/cqlhandling.py", line 22, in <module>
from cassandra.metadata import cql_keywords_reserved
ImportError: No module named cassandra.metadata
can anyone help me to getting out of this. Any help will be greatly apprreciated.
I have got the same problem described in this post, but inside a docker container.
I don't really know where my pgadmin file reside to edit it's default path.How do I go about fixing this issue? Please be as detailed as possible because I don't know how to docker.
Here is an abstract of the verbatim of docker-compose up command:
php-worker_1 | 2020-11-11 05:50:13,700 INFO spawned: 'laravel-worker_03' with pid 67
pgadmin_1 | [2020-11-11 05:50:13 +0000] [223] [INFO] Worker exiting (pid: 223)
pgadmin_1 | WARNING: Failed to set ACL on the directory containing the configuration database:
pgadmin_1 | [Errno 1] Operation not permitted: '/var/lib/pgadmin'
pgadmin_1 | HINT : You may need to manually set the permissions on
pgadmin_1 | /var/lib/pgadmin to allow pgadmin to write to it.
pgadmin_1 | ERROR : Failed to create the directory /var/lib/pgadmin/sessions:
pgadmin_1 | [Errno 13] Permission denied: '/var/lib/pgadmin/sessions'
pgadmin_1 | HINT : Create the directory /var/lib/pgadmin/sessions, ensure it is writeable by
pgadmin_1 | 'pgadmin', and try again, or, create a config_local.py file
pgadmin_1 | and override the SESSION_DB_PATH setting per
pgadmin_1 | https://www.pgadmin.org/docs/pgadmin4/4.27/config_py.html
pgadmin_1 | /usr/local/lib/python3.8/os.py:1023: RuntimeWarning: line buffering (buffering=1) isn't supported in binary mode, the default buffer size will be used
pgadmin_1 | return io.open(fd, *args, **kwargs)
pgadmin_1 | [2020-11-11 05:50:13 +0000] [224] [INFO] Booting worker with pid: 224
my docker-compose.yml:
### pgAdmin ##############################################
pgadmin:
image: dpage/pgadmin4:latest
environment:
- "PGADMIN_DEFAULT_EMAIL=${PGADMIN_DEFAULT_EMAIL}"
- "PGADMIN_DEFAULT_PASSWORD=${PGADMIN_DEFAULT_PASSWORD}"
ports:
- "${PGADMIN_PORT}:80"
volumes:
- ${DATA_PATH_HOST}/pgadmin:/var/lib/pgadmin
depends_on:
- postgres
networks:
- frontend
- backend
Okay. looks like problem appears when you try to run pgadmin service.
This part
### pgAdmin ##############################################
pgadmin:
image: dpage/pgadmin4:latest
environment:
- "PGADMIN_DEFAULT_EMAIL=${PGADMIN_DEFAULT_EMAIL}"
- "PGADMIN_DEFAULT_PASSWORD=${PGADMIN_DEFAULT_PASSWORD}"
ports:
- "${PGADMIN_PORT}:80"
volumes:
- ${DATA_PATH_HOST}/pgadmin:/var/lib/pgadmin
depends_on:
- postgres
networks:
- frontend
- backend
As you can see you trying to mount local directory ${DATA_PATH_HOST}/pgadmin into container's /var/lib/pgadmin
volumes:
- ${DATA_PATH_HOST}/pgadmin:/var/lib/pgadmin
As you can read in this article your local ${DATA_PATH_HOST}/pgadmin directory's UID and GID must be 5050. Is this 5050?
You can check it by running
ls -l ${DATA_PATH_HOST}
Output will be like
drwxrwxr-x 1 5050 5050 12693 Nov 11 14:56 pgadmin
or
drwxrwxr-x 1 SOME_USER SOME_GROUP 12693 Nov 11 14:56 pgadmin
if SOME_USER's and SOME_GROUP's IDs are 5050, it is okay. 5050 as is also okay. If not, try to do as described in article above.
sudo chown -R 5050:5050 ${DATA_PATH_HOST}/pgadmin
Also you need to check is environment variable exists:
# run it as same user as you running docker-compose
echo ${DATA_PATH_HOST}
If output will be empty you need to set ${DATA_PATH_HOST} or allow docker to read variables from file. There are many ways to do it.
If you're on Windows, add this line to your docker-compose.yml. It gives container an access to your local folder
version: "3.9"
services:
postgres:
user: root <- this one
container_name: postgres_container
image: postgres:14.2
When running in kubernetes environment, I had to add these values.
spec:
containers:
- name: pgadmin
image: dpage/pgadmin4:5.4
securityContext:
runAsUser: 0
runAsGroup: 0