[GH-ISSUE #37] [BUG] docker container won't do anything, no logs after branch 27 merge

kerem commented

2026-02-25 20:34:42 +03:00

Owner

Originally created by @edrock200 on GitHub (May 12, 2020).
Original GitHub issue: https://github.com/benbusby/whoogle-search/issues/37

Describe the bug
A clear and concise description of what the bug is.
Just installed it and hour ago, was working fine except results in wrong language. I saw pull request 27, then saw it was merged, so I deleted the container and git clone folder and started over. The new version built but when it starts, nothing happens. Docker logs says "No logs."
To Reproduce
Steps to reproduce the behavior:
Follow docker steps in readme

Expected behavior
Whoogle server listening on 8888 and allowing search

Desktop (please complete the following information):

OS: docker on Ubuntu 18.04
Browser chrome android

Originally created by @edrock200 on GitHub (May 12, 2020). Original GitHub issue: https://github.com/benbusby/whoogle-search/issues/37 **Describe the bug** A clear and concise description of what the bug is. Just installed it and hour ago, was working fine except results in wrong language. I saw pull request 27, then saw it was merged, so I deleted the container and git clone folder and started over. The new version built but when it starts, nothing happens. Docker logs says "No logs." **To Reproduce** Steps to reproduce the behavior: Follow docker steps in readme **Expected behavior** Whoogle server listening on 8888 and allowing search **Desktop (please complete the following information):** - OS: docker on Ubuntu 18.04 - Browser chrome android

kerem

2026-02-25 20:34:42 +03:00

closed this issue
added the
bug
label

kerem commented

2026-02-25 20:34:42 +03:00

Author

Owner

@edrock200 commented on GitHub (May 12, 2020):

I should have noted I kept the version before the merge, built that one in docker again and it runs fine.

@edrock200 commented on GitHub (May 12, 2020): I should have noted I kept the version before the merge, built that one in docker again and it runs fine.

kerem commented

2026-02-25 20:34:42 +03:00

Author

Owner

@benbusby commented on GitHub (May 13, 2020):

I think what you're seeing is a side effect of pull request #32, which changed the default docker port to 5000 unless otherwise specified. The README was updated with this change, and I was planning on announcing the port change once I push the new image to DockerHub, but I realize that existing builds pulling from master will need to change ports.

Could you try accessing the instance through port 5000 and see if that fixes it?

@benbusby commented on GitHub (May 13, 2020): I think what you're seeing is a side effect of pull request #32, which changed the default docker port to 5000 unless otherwise specified. The README was updated with this change, and I was planning on announcing the port change once I push the new image to DockerHub, but I realize that existing builds pulling from master will need to change ports. Could you try accessing the instance through port 5000 and see if that fixes it?

kerem commented

2026-02-25 20:34:42 +03:00

Author

Owner

@edrock200 commented on GitHub (May 13, 2020):

Thank you. I did notice that and tried it but doesn't work. Normally, when creating/starting the container the log at least shows "listening on 0.0.0.0:5000 but the latest build litterally says "No logs." It's odd. I'm about to try and build it on a second docker server to see if it's something with my setup.

@edrock200 commented on GitHub (May 13, 2020): Thank you. I did notice that and tried it but doesn't work. Normally, when creating/starting the container the log at least shows "listening on 0.0.0.0:5000 but the latest build litterally says "No logs." It's odd. I'm about to try and build it on a second docker server to see if it's something with my setup.

kerem commented

2026-02-25 20:34:42 +03:00

Author

Owner

@edrock200 commented on GitHub (May 13, 2020):

Yep same exact issue on second box. No logs and no response on port 5000. confirmed its published to host port 5000.

@edrock200 commented on GitHub (May 13, 2020): Yep same exact issue on second box. No logs and no response on port 5000. confirmed its published to host port 5000.

kerem commented

2026-02-25 20:34:42 +03:00

Author

Owner

@Atticus- commented on GitHub (May 13, 2020):

We don't see logs because python buffers its output. If we add a -u to line 24 of whoogle-search we can see the problem in the logs:

whoogle-search    | Serving on http://localhost:5000

During #32 the --host 0.0.0.0 argument was left out, so the webserver only listens on localhost (despite docker exposing and publishing the port). The fix is to change line 24 in whoogle-search to:

python3 -um app --host "0.0.0.0" --port $PORT

Happy to send a PR if you'd like.

@Atticus- commented on GitHub (May 13, 2020): We don't see logs because python buffers its output. If we add a -u to line 24 of `whoogle-search` we can see the problem in the logs: ``` whoogle-search | Serving on http://localhost:5000 ``` During #32 the `--host 0.0.0.0` argument was left out, so the webserver only listens on localhost (despite docker exposing and publishing the port). The fix is to change line 24 in `whoogle-search` to: ``` python3 -um app --host "0.0.0.0" --port $PORT ``` Happy to send a PR if you'd like.

kerem commented

2026-02-25 20:34:42 +03:00

Author

Owner

@benbusby commented on GitHub (May 13, 2020):

Was just about to comment this, but looks like you beat me to it. A PR would be great, thanks for looking into this as well.

@benbusby commented on GitHub (May 13, 2020): Was just about to comment this, but looks like you beat me to it. A PR would be great, thanks for looking into this as well.

kerem commented

2026-02-25 20:34:42 +03:00

Author

Owner

@benbusby commented on GitHub (May 13, 2020):

Marking this as resolved with the merge of #38.

@benbusby commented on GitHub (May 13, 2020): Marking this as resolved with the merge of #38.

kerem commented

2026-02-25 20:34:42 +03:00

Author

Owner

@edrock200 commented on GitHub (May 13, 2020):

That worked! Thank you! Not sure if it matters but the logs throw this error now, however searches seem to work fine:

Serving on http://0.0.0.0:5000

ERROR:app:Exception on /tmp [GET]

Traceback (most recent call last):

File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 2446, in wsgi_app

response = self.full_dispatch_request()

File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1951, in full_dispatch_request

rv = self.handle_user_exception(e)

File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1820, in handle_user_exception

reraise(exc_type, exc_value, tb)

File "/usr/local/lib/python3.8/site-packages/flask/_compat.py", line 39, in reraise

raise value

File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1949, in full_dispatch_request

rv = self.dispatch_request()

File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1935, in dispatch_request

return self.view_functions[rule.endpoint](**req.view_args)

File "/usr/src/app/app/routes.py", line 127, in tmp

file_data = g.user_request.send(base_url=img_url, return_bytes=True)

File "/usr/src/app/app/request.py", line 87, in send

crl.perform()

pycurl.error: (3, '')

WARNING:waitress.queue:Task queue depth is 1

WARNING:waitress.queue:Task queue depth is 2

WARNING:waitress.queue:Task queue depth is 3

WARNING:waitress.queue:Task queue depth is 4

WARNING:waitress.queue:Task queue depth is 1

@edrock200 commented on GitHub (May 13, 2020): That worked! Thank you! Not sure if it matters but the logs throw this error now, however searches seem to work fine: Serving on http://0.0.0.0:5000 Serving on http://0.0.0.0:5000 ERROR:app:Exception on /tmp [GET] Traceback (most recent call last): File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 2446, in wsgi_app response = self.full_dispatch_request() File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1951, in full_dispatch_request rv = self.handle_user_exception(e) File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1820, in handle_user_exception reraise(exc_type, exc_value, tb) File "/usr/local/lib/python3.8/site-packages/flask/_compat.py", line 39, in reraise raise value File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1949, in full_dispatch_request rv = self.dispatch_request() File "/usr/local/lib/python3.8/site-packages/flask/app.py", line 1935, in dispatch_request return self.view_functions[rule.endpoint](**req.view_args) File "/usr/src/app/app/routes.py", line 127, in tmp file_data = g.user_request.send(base_url=img_url, return_bytes=True) File "/usr/src/app/app/request.py", line 87, in send crl.perform() pycurl.error: (3, '') WARNING:waitress.queue:Task queue depth is 1 WARNING:waitress.queue:Task queue depth is 2 WARNING:waitress.queue:Task queue depth is 3 WARNING:waitress.queue:Task queue depth is 4 WARNING:waitress.queue:Task queue depth is 1 WARNING:waitress.queue:Task queue depth is 1 WARNING:waitress.queue:Task queue depth is 1

kerem commented

2026-02-25 20:34:43 +03:00

Author

Owner

@benbusby commented on GitHub (May 14, 2020):

@edrock200 That error is "normal" and doesn't break anything, but should be dealt with a bit better. It happens whenever the image url decryption fails to resolve as an absolute image path, which usually means that it's a Google specific email that they're using a relative path for. You can safely ignore this, I'll try to remember to add in a catch for this error in the future though.

@benbusby commented on GitHub (May 14, 2020): @edrock200 That error is "normal" and doesn't break anything, but should be dealt with a bit better. It happens whenever the image url decryption fails to resolve as an absolute image path, which usually means that it's a Google specific email that they're using a relative path for. You can safely ignore this, I'll try to remember to add in a catch for this error in the future though.

Rows
Columns

[GH-ISSUE #37] [BUG] docker container won't do anything, no logs after branch 27 merge #24