mirror of
https://github.com/fosrl/pangolin.git
synced 2026-05-06 12:55:03 -05:00
[GH-ISSUE #327] dependency failed to start: container pangolin is unhealthy #8155
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/pangolin#8155
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @jayphizzle on GitHub (Mar 11, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/327
Hi!
Tried latest pangolin today on a fresh installed Debian VPS.
Ran the installer, but the pangolin container does not start.
Log of the container:
If you need more information please let me know
@miloschwartz commented on GitHub (Mar 11, 2025):
Hey, looks like based on your screenshot of the logs that the Pangolin container is starting. Can you try to shut everything down and do a fresh restart? Are there anymore errors that show up in the logs potentially?
@jayphizzle commented on GitHub (Mar 12, 2025):
what I noticed during installation:
stuck long time on the last pulls
@miloschwartz commented on GitHub (Mar 12, 2025):
Can you do
sudo docker compose logs -fand look for any errors and send them our way so we can take a look?@jayphizzle commented on GitHub (Mar 12, 2025):
https://notebin.de/?b4d1d500bb15e1e3#BSXqBeTYH6ZAXagvukF4mnxkXxXDt7zwTR28JtiPPwiE
@wedge-kc commented on GitHub (Mar 13, 2025):
I had a similar issue. After first docker compose up and unhealthy dependency try docker compose up again (without docker compose down) and see if it comes up. If so, you may need to increase the number of retries for the health check on the pangolin container. After doing that, a single docker compose up got everything up for me.
@miloschwartz commented on GitHub (Mar 13, 2025):
Yeah I am honestly really confused here because the logs seems to indicate Pangolin is healthy and the API started up where the health check occur.
@oschwartz10612 commented on GitHub (Mar 13, 2025):
Could you maybe post your docker compose file? You could also try to
docker exec -it pangolin curl -f http://localhost:3001/api/v1/and see if that returns an error. Thats all the health check does@jayphizzle commented on GitHub (Mar 13, 2025):
changed retries to 10 - no changes
docker exec -it pangolin curl -f http://localhost:3001/api/v1/->{"message":"Healthy"}i reinstalled my vps (netcup) with latest ubuntu - also same result.
docker-compose.yml https://pastebin.com/7Hp4cJNT (should be default one as I used the installer)
@aszurnasirpal commented on GitHub (Mar 14, 2025):
I have the same problem.
Results of the
docker exec -it pangolin curl -f http://localhost:3001/api/v1/also return to me{"message":"Healthy"}@EliasMasche commented on GitHub (Mar 14, 2025):
I have the same issue too but my Pangolin instance returns this error, I have SMTP and email address for Let's Encrypt
@miloschwartz commented on GitHub (Mar 14, 2025):
@EliasMasche Check your configuration file for the no-reply email and make sure it's valid. Does it have any weird formatting or special characters that might cause this invalid email error?
@EliasMasche commented on GitHub (Mar 14, 2025):
@miloschwartz where is located the configuration file to change or I can run the installer to modify it?
@miloschwartz commented on GitHub (Mar 14, 2025):
@EliasMasche The installer places the config files in the working directly used when you executed it. You would need to find that path, then view the config.yml file to check the no-reply email. No need to run the installer again since it already created the needed files to run everything.
@EliasMasche commented on GitHub (Mar 14, 2025):
Thanks for the detail on my no-reply email had
<>on the field. Now is working@syl779 commented on GitHub (Mar 15, 2025):
Same problem I had a few weeks ago. [https://github.com/fosrl/pangolin/issues/281](https://github.com/fosrl/pangolin/issues/281)
Still happens on most installs (I have installed about a dozen times now) - but only if you say "yes" to crowdsec.
@jayphizzle commented on GitHub (Mar 15, 2025):
Without crowdsec it is working for me too.
@FunDeckHermit commented on GitHub (Mar 15, 2025):
Had the same problem during a couple (re)-installations. Happened after exactly 30 seconds on weak hardware.
@jayphizzle commented on GitHub (Mar 16, 2025):
weak hardware fits also in my scenario: 1 vCore & 1 GB RAM VPS.
@oschwartz10612 commented on GitHub (Mar 16, 2025):
Maybe we need more sensible timeouts and retries for the compose. You could increase the timeout and retries and see if that helps?
@FunDeckHermit commented on GitHub (Mar 16, 2025):
I think that would be the easiest method to fix the issue: increasing the timeout. Maybe add some automated test to measure the "Time to Healthy" in your CI pipeline.
@mrsreenair commented on GitHub (Mar 29, 2025):
I encountered a similar issue, which was resolved by increasing the virtual private server’s CPU and RAM.
@odoncm commented on GitHub (Mar 31, 2025):
Or increase the RAM or CPU. That machine is very weak. It happened to me the other day while testing on an Oracle Free Tier VPS (1 CPU, 1 GB). In the end, I got it up and running like this:
You'd have to adjust the timings, but it should start with that.
I'm also saying that I'm currently testing with another VPS (not Oracle) with 0.5 VCore and 1 GB, and it works without making any changes to the original ./installer.sh configuration.
I'm also more inclined to believe that there may be some slow processing on the machines on those VPSs.
@markmsv7 commented on GitHub (Apr 2, 2025):
Adding my similar experience. I'm a huge newb when it comes to selfhosting, so thank you for making this easy. It's almost as easy as those Tteck (RIP) Proxmox helper scripts.
That said, I started a Digital ocean droplet (1vCPU, 512MB, 10GB SSD w Ubuntu) and had same issue when installing crowdsec. Could not figure it out after installing it about 10 times and the difference was crowdsec vs not. I wanted crowdsec installed since again I'm a selfhosting newbie and this is my first proxy service I've attempted since I've been scared to try caddy, traefik, Nginx, etc for fear of improperly securing it.
Eventually I found through forums/docs that Ubuntu likes 1GB better.
So increasing to 1vCPU, 1GB, 25GB SSD tier fixed it to where crowdsec doesn't break things.
@Maxklos commented on GitHub (Apr 4, 2025):
I had this once after an update,
docker compose downthen purging the whole image from the server and a newdocker compose up -dfixed it for me@Ard3ny commented on GitHub (Apr 7, 2025):
From what I've noticed, the problem only occur when crowdsec is enabled and VPS is somewhat "resource low" like 1vCPU, 1GB Ram etc...
Changing healthcheck timings in docker-compose file according to @odoncm helped.
@oschwartz10612 commented on GitHub (Apr 22, 2025):
Closing for now. Please let us know if this issue continues but the first step to troubleshooting is playing with the retries and timeouts in the docker-compose.yml file as shown:
4d814b3714