[GH-ISSUE #270] [BUG] Whoogle 0.4.0 shows as "health: starting" in Docker #185

New issue

Closed

opened 2026-02-25 20:35:07 +03:00 by kerem · 2 comments

kerem commented

2026-02-25 20:35:07 +03:00

Owner

Originally created by @s3rverro0m on GitHub (Apr 6, 2021).
Original GitHub issue: https://github.com/benbusby/whoogle-search/issues/270

Prior to version 0.4.0, ie...0.3.2, Whoogle would fully initialize and Traefik would pick it up. Now it seems that the container doesn't "fully" start up, or at least it doesn't tell Docker that it's fully started. I am able to access Whoogle locally.

0.4.0:
c0059fd2182a benbusby/whoogle-search:latest "/bin/sh -c 'misc/to…" About a minute ago Up About a minute (health: starting) 5000/tcp whoogle

vs 0.3.2:
d7b7d330cbf3 benbusby/whoogle-search:0.3.2 "/bin/sh -c 'config/…" 22 seconds ago Up 15 seconds 5000/tcp whoogle

I'm running this on my own server using CentOS 8. Looking at the logs of 0.4.0, I see that bootstrapping fully finishes:

Apr 06 18:39:11.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Apr 06 18:39:11.000 [notice] New control connection opened from 127.0.0.1.
Apr 06 18:39:11.000 [notice] Heartbeat: Tor's uptime is 0:00 hours, with 5 circuits open. I've sent 400 kB and received 2.71 MB.
Serving on http://0.0.0.0:5000
Apr 06 18:39:12.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Apr 06 18:39:13.000 [notice] Bootstrapped 100%: Done

The logs are identical on 0.3.2, but I see that the docker command is different: /bin/sh -c 'misc/to… vs /bin/sh -c 'config/…. Not sure where else to look.

Please let me know if I can share anymore logs, or troubleshoot some more.

Originally created by @s3rverro0m on GitHub (Apr 6, 2021). Original GitHub issue: https://github.com/benbusby/whoogle-search/issues/270 Prior to version 0.4.0, ie...0.3.2, Whoogle would fully initialize and Traefik would pick it up. Now it seems that the container doesn't "fully" start up, or at least it doesn't tell Docker that it's fully started. I am able to access Whoogle locally. 0.4.0: `c0059fd2182a benbusby/whoogle-search:latest "/bin/sh -c 'misc/to…" About a minute ago Up About a minute (health: starting) 5000/tcp whoogle` vs 0.3.2: `d7b7d330cbf3 benbusby/whoogle-search:0.3.2 "/bin/sh -c 'config/…" 22 seconds ago Up 15 seconds 5000/tcp whoogle` I'm running this on my own server using CentOS 8. Looking at the logs of 0.4.0, I see that bootstrapping fully finishes: ``` Apr 06 18:39:11.000 [notice] Bootstrapped 85%: Finishing handshake with first hop Apr 06 18:39:11.000 [notice] New control connection opened from 127.0.0.1. Apr 06 18:39:11.000 [notice] Heartbeat: Tor's uptime is 0:00 hours, with 5 circuits open. I've sent 400 kB and received 2.71 MB. Serving on http://0.0.0.0:5000 Apr 06 18:39:12.000 [notice] Bootstrapped 90%: Establishing a Tor circuit Apr 06 18:39:13.000 [notice] Bootstrapped 100%: Done ``` The logs are identical on 0.3.2, but I see that the docker command is different: `/bin/sh -c 'misc/to…` vs `/bin/sh -c 'config/…`. Not sure where else to look. Please let me know if I can share anymore logs, or troubleshoot some more.

kerem

2026-02-25 20:35:07 +03:00

closed this issue
added the
bug
label

kerem commented

2026-02-25 20:35:07 +03:00

Author

Owner

@inlophe commented on GitHub (Apr 7, 2021):

This happen to me too. Actually this happen too when I use 0.3.2 beta and buildx-experimental last time before 0.3.2 comes out.

I don't know if this is relevant or not, after I looked at whoogle docker hub, I notice that this happen (to me, at least) everytime the image compressed size is under 100MB, around 70ish MB to be exact (0.3.2 beta/buildx-experimental , 0.4.0) . But when the compressed size around 180-190MB it works fine (0.3.1 , 0.3.2).

Is there anything different when building the image that makes the size that different?

@inlophe commented on GitHub (Apr 7, 2021): This happen to me too. Actually this happen too when I use 0.3.2 beta and buildx-experimental last time before 0.3.2 comes out. I don't know if this is relevant or not, after I looked at whoogle docker hub, I notice that this happen (to me, at least) everytime the image compressed size is under 100MB, around 70ish MB to be exact (0.3.2 beta/buildx-experimental , 0.4.0) . But when the compressed size around 180-190MB it works fine (0.3.1 , 0.3.2). Is there anything different when building the image that makes the size that different?

kerem commented

2026-02-25 20:35:07 +03:00

Author

Owner

@benbusby commented on GitHub (Apr 7, 2021):

I noticed something similar actually. The health: starting is due to the healthcheck interval being set to 5 minutes, meaning the image isn't fully "up" until then. I've reduced it now to 30 seconds, and the container should be fully running after the first health check. This seems fixed on my end, but please re-open if you're still having the problem.

Is there anything different when building the image that makes the size that different?

Yes, in the latest release the Dockerfile uses a multi-stage build to optimize the size of the image.

@benbusby commented on GitHub (Apr 7, 2021): I noticed something similar actually. The `health: starting` is due to the healthcheck interval being set to 5 minutes, meaning the image isn't fully "up" until then. I've reduced it now to 30 seconds, and the container should be fully running after the first health check. This seems fixed on my end, but please re-open if you're still having the problem. > Is there anything different when building the image that makes the size that different? Yes, in the latest release the Dockerfile uses a multi-stage build to optimize the size of the image.