Container XXXXXX didn't respond to HTTP pings on port: 5100, failing site start. See container logs for debugging

[jnhrv]

🐛 Bug Report

Hi,

until now I successfully used the docker image running in Azure Web App Service pglombardo/pwpush-ephemeral:release
Now, it is required to avoid data loss from SQLite3 when the app restarts so I'm implementing MySQL or PostgreSQL database.

The following issue occurs after changing the image to pglombardo/pwpush-postgres:release

2023-04-12T13:37:26.195Z INFO - Logging is not enabled for this container. Please use https://aka.ms/linux-diagnostics to enable logging to see container logs here. 2023-04-12T13:37:28.540Z INFO - Initiating warmup request to container XXXXXXXX for site XXXXXXXX 2023-04-12T13:37:40.440Z ERROR - Container XXXXXXXX for site XXXXXXXX has exited, failing site start 2023-04-12T13:37:40.480Z ERROR - Container XXXXXXXX didn't respond to HTTP pings on port: 5100, failing site start. See container logs for debugging. 2023-04-12T13:37:40.546Z INFO - Stopping site XXXXXXXX because it failed during startup. 2023-04-12T13:40:16.487Z INFO - release Pulling from pglombardo/pwpush-postgres 2023-04-12T13:40:16.566Z INFO - Digest: sha256:9370bd1763816eabbde1a97a381d05e01ec41df32b06f97ccf6fd6a3b7b7a865 2023-04-12T13:40:16.578Z INFO - Status: Image is up to date for pglombardo/pwpush-postgres:release 2023-04-12T13:40:16.586Z INFO - Pull Image successful, Time taken: 0 Minutes and 0 Seconds 2023-04-12T13:40:17.574Z INFO - Starting container for site 2023-04-12T13:40:17.589Z INFO - docker run -d --expose=5100 --name XXXXXXXX -e WEBSITE_AUTH_ENABLED=False -e WEBSITE_SITE_NAME=XXXXXXXX -e PORT=5100 -e WEBSITE_ROLE_INSTANCE_ID=0 -e WEBSITE_HOSTNAME=XXXXXXXX.azurewebsites.net -e WEBSITE_INSTANCE_ID=2c847a802c8040b33d7df73fac3a50614d8069754a88be4922fa1677ca17ce3d -e WEBSITE_USE_DIAGNOSTIC_SERVER=False pglombardo/pwpush-postgres:release

🔬 How To Reproduce

Steps to reproduce the behavior:

1. Followed steps described in How to install on Azure? #277 provided by @jgudmundson-RETSD
   "name": "DATABASE_URL", "value": "postgresql://adminUsername:password@dbServerName.postgres.database.azure.com:5432/postgres", "slotSetting": true
2. Restart the service, then the issue occurs
3. When switching back to ephemeral:release and removing the the "DATABASE_URL" config, it all works again as before.

I also read the #896 from @burak40 and deleted all configs except DATABASE_URL but no joy.

Code sample

Environment

Where are you running/using Password Pusher?

• pwpush.com
• Docker
  • pwpush-ephemeral
  • pwpush-mysql
  • [-] pwpush-postgres
  • custom image
• Heroku
• Digital Ocean
• [-] Microsoft Azure
• Google Cloud
• AWS
• Source Code
• Other (please specify)

If applicable, what version of Password Pusher?

Screenshots

📈 Expected behavior

Successfully run the service with the db connected.

📎 Additional context

[github-actions]

Hello @jnhrv, thanks for contributing to the Password Pusher community! We will respond as soon as possible.

[jgudmundson-RETSD]

I restarted my service to see if there is an issue with the newest release build, but it seems fine.
2 questions.

1. On your PostgreSQL server do you have "Allow public access from any Azure service within Azure to this server" checked under networking?
2. On the Web App, under networking do you have any access restrictions defined under inbound traffic?

[jnhrv]

I restarted my service to see if there is an issue with the newest release build, but it seems fine. 2 questions.

1. On your PostgreSQL server do you have "Allow public access from any Azure service within Azure to this server" checked under networking?
2. On the Web App, under networking do you have any access restrictions defined under inbound traffic?

Hi @jgudmundson-RETSD, thanks for helping out here.

1. yes, first I added there only the outbound IPs of the App Service but then I also tested with the "Allow public access from any Azure service within Azure to this server" checked.
2. No, there are no restrictions on inbound/outbound traffic of App Service. All features are Off.

Don't know what difference it makes if I use the B1 tier for App Service Plan and the Postgres is running on the following cheapest server config "Burstable, B1ms, 1 vCores, 2 GiB RAM, 32 GiB storage".

[jgudmundson-RETSD]

I'm also running on B1, and B1ms.
Did you check if the database is populated? on the DB site click connect, pick table, enter the password, run "\dt+".

[pglombardo]

The database should automatically be migrated on container start.

In that screenshot, the line before states that the container exited which means a startup issue. The most likely culprit to this is a missing DATABASE_URL environment variable that points to your postgres database.

An example would be:

DATABASE_URL=postgresql://user:passwd@host:5432/database-name

Could you verify this?

Last point - if you get the container startup output that will tell us exactly what the problem is.

Logging is not enabled for this container. Please use https://aka.ms/linux-diagnostics to enable logging to see container logs here.

[jnhrv]

@jgudmundson-RETSD
Looks like the database is not populated.
postgres=> \dt+ Did not find any relations.

@pglombardo I attached logs after I changed the App Service to the postgres:release image and set the DATABASE_URL again.
The DATABASE_URL has been always in place when I used the postgres image.

pwpush_azureAppService_logs.txt

[pglombardo]

That helps. The application can't parse or lookup the database connection specified in DATABASE_URL:

URI::InvalidURIError: bad URI(is not URI?)

Could it be that your real username or password have characters that conflict with the URI? Such as , :, @ or others?

If so you may need to quote those strings or replace them with their UUEncode equivalent (@ == %40, == %20).

[jnhrv]

@pglombardo @jgudmundson-RETSD
Thank you both for the help!

Looks like it was truly related to the password that contained special characters.
When I previously tried to quote the password with the "double quotes", that did not work either.
I changed the pw to not contain any special chars and now the database migrated successfully, is populated with tables, the app service is running and data are retained after the app restart too! Lovely 🙂