[GH-ISSUE #303] [BUG] Slow search on Raspberry Pi and incorrect env variables

kerem commented

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

Owner

Originally created by @accountForIssues on GitHub (May 2, 2021).
Original GitHub issue: https://github.com/benbusby/whoogle-search/issues/303

Describe the bug

Whoogle takes a long time to return search results (between 5-15s)
Autocomplete doesn't work.
whoogle.env seems to be ignored.

Deployment Method

Heroku (one-click deploy)
Docker -- buildx/experimental
run executable
pip/pipx
Other: [describe setup]

Version of Whoogle Search

Latest build from [source] (i.e. GitHub, Docker Hub, pip, etc)
Version [0.4.1]
Not sure

Server
Raspberry Pi 4 4GB
Linux alarm 5.11.4-1-ARCH #1 SMP Sun Mar 7 23:46:10 UTC 2021 aarch64 GNU/Linux

Additional context
It started a few days ago and I don't think I've made any drastic changes. I tried recreating containers, restarting system, etc. Nothing has worked so far.

docker-compose.yml

# cant use mem_limit in a 3.x docker-compose file in non swarm mode
# see https://github.com/docker/compose/issues/4513
version: "2.4"

services:
  whoogle-search:
    image: benbusby/whoogle-search:buildx-experimental
    container_name: whoogle
    volumes:
        - /etc/localtime:/etc/localtime:ro
        - ./whoogle.env:/whoogle/whoogle.env:ro
    restart: on-failure:5
    mem_limit: 256mb
    memswap_limit: 256mb
    # user debian-tor from tor package
    user: '102'
    security_opt:
      - no-new-privileges
    cap_drop:
      - ALL
    read_only: true
    tmpfs:
      - /config/:size=10M,uid=102,gid=102,mode=1700
      - /var/lib/tor/:size=10M,uid=102,gid=102,mode=1700
      - /run/tor/:size=1M,uid=102,gid=102,mode=1700
    environment:
      - WHOOGLE_DOTENV=1
    ports:
      - 5000:5000
    restart: unless-stopped

whoogle.env

WHOOGLE_CONFIG_ALTS=1
WHOOGLE_ALT_TW=nitter.42l.fr
WHOOGLE_ALT_YT=invidious.tube
WHOOGLE_ALT_IG=bib.actionsack.com/u
WHOOGLE_ALT_RD=libredd.it

WHOOGLE_CONFIG_LANGUAGE=lang_en
WHOOGLE_CONFIG_DARK=1
WHOOGLE_CONFIG_NEW_TAB=1  # Open results in new tab
# WHOOGLE_CONFIG_COUNTRY=countryGB  # See app/static/settings/
# WHOOGLE_CONFIG_SEARCH_LANGUAGE=lang_en

# WHOOGLE_USER=""
# WHOOGLE_PASS=""
# WHOOGLE_PROXY_USER=""
# WHOOGLE_PROXY_PASS=""
# WHOOGLE_PROXY_TYPE=""
# WHOOGLE_PROXY_LOC=""
# HTTPS_ONLY=1
# 
# WHOOGLE_CONFIG_DISABLE=1   # Disables changing of config from client
# WHOOGLE_CONFIG_SAFE=1  # Safe searches
# WHOOGLE_CONFIG_TOR=1  # Use Tor if available
# WHOOGLE_CONFIG_GET_ONLY=1 # Search using GET requests only
# WHOOGLE_CONFIG_URL=https://<whoogle url>/
# WHOOGLE_CONFIG_STYLE=":root { /* LIGHT THEME COLORS */ --whoogle-background: #d8dee9; --whoogle-accent: #2e3440; --whoogle-text: #3B4252; --whoogle-contrast-text: #eceff4; --whoogle-secondary-text: #70757a; --whoogle-result-bg: #fff; --whoogle-result-title: #4c566a; --whoogle-result-url: #81a1c1; --whoogle-result-visited: #a3be8c; /* DARK THEME COLORS */ --whoogle-dark-background: #222; --whoogle-dark-accent: #685e79; --whoogle-dark-text: #fff; --whoogle-dark-contrast-text: #000; --whoogle-dark-secondary-text: #bbb; --whoogle-dark-result-bg: #000; --whoogle-dark-result-title: #1967d2; --whoogle-dark-result-url: #4b11a8; --whoogle-dark-result-visited: #bbbbff; }"

Logs seem to be normal except for one:

ERROR:app:Exception on /autocomplete [POST]
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/urllib3/connection.py", line 159, in _new_conn
    conn = connection.create_connection(
  File "/usr/local/lib/python3.8/site-packages/urllib3/util/connection.py", line 61, in create_connection
    for res in socket.getaddrinfo(host, port, family, socket.SOCK_STREAM):
  File "/usr/local/lib/python3.8/socket.py", line 918, in getaddrinfo
    for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -3] Temporary failure in name resolution

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py", line 670, in urlopen
    httplib_response = self._make_request(
  File "/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py", line 381, in _make_request
    self._validate_conn(conn)
  File "/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py", line 976, in _validate_conn
    conn.connect()
  File "/usr/local/lib/python3.8/site-packages/urllib3/connection.py", line 308, in connect
    conn = self._new_conn()
  File "/usr/local/lib/python3.8/site-packages/urllib3/connection.py", line 171, in _new_conn
    raise NewConnectionError(
urllib3.exceptions.NewConnectionError: <urllib3.connection.HTTPSConnection object at 0xffff88442550>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/requests/adapters.py", line 439, in send
    resp = conn.urlopen(
  File "/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py", line 724, in urlopen
    retries = retries.increment(
  File "/usr/local/lib/python3.8/site-packages/urllib3/util/retry.py", line 439, in increment
    raise MaxRetryError(_pool, url, error or ResponseError(cause))
urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='suggestqueries.google.com', port=443): Max retries exceeded with url: /complete/search?client=toolbar&hl=&q=i (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0xffff88442550>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution'))

During handling of the above exception, another exception occurred:

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 "/whoogle/app/routes.py", line 182, in autocomplete
    g.user_request.autocomplete(q) if not g.user_config.tor else []
  File "/whoogle/app/request.py", line 187, in autocomplete
    response = self.send(base_url=AUTOCOMPLETE_URL,
  File "/whoogle/app/request.py", line 247, in send
    response = requests.get(
  File "/usr/local/lib/python3.8/site-packages/requests/api.py", line 76, in get
    return request('get', url, params=params, **kwargs)
  File "/usr/local/lib/python3.8/site-packages/requests/api.py", line 61, in request
    return session.request(method=method, url=url, **kwargs)
  File "/usr/local/lib/python3.8/site-packages/requests/sessions.py", line 530, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/local/lib/python3.8/site-packages/requests/sessions.py", line 643, in send
    r = adapter.send(request, **kwargs)
  File "/usr/local/lib/python3.8/site-packages/requests/adapters.py", line 516, in send
    raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPSConnectionPool(host='suggestqueries.google.com', port=443): Max retries exceeded with url: /complete/search?client=toolbar&hl=&q=i (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0xffff88442550>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution'))
ERROR:app:Exception on /autocomplete [POST]
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/urllib3/connection.py", line 159, in _new_conn
    conn = connection.create_connection(
  File "/usr/local/lib/python3.8/site-packages/urllib3/util/connection.py", line 61, in create_connection
    for res in socket.getaddrinfo(host, port, family, socket.SOCK_STREAM):
  File "/usr/local/lib/python3.8/socket.py", line 918, in getaddrinfo
    for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -3] Temporary failure in name resolution

Doing an nslookup suggestqueries.google.com on the host works fine and whoogle has worked fine in the past so I dunno what happened.

Moreover, (maybe I'm doing it wrong), whoogle doesn't seem to pickup whoogle.env values. Doing a echo $WHOOGLE_ALT_TW prints the default value. Doing a cat whoogle.env inside the container reveals the custom settings so I don't know why whoogle is picking the default values.

Originally created by @accountForIssues on GitHub (May 2, 2021). Original GitHub issue: https://github.com/benbusby/whoogle-search/issues/303 **Describe the bug** * Whoogle takes a long time to return search results (between 5-15s) * Autocomplete doesn't work. * whoogle.env seems to be ignored. **Deployment Method** - [ ] Heroku (one-click deploy) - [x] Docker -- buildx/experimental - [ ] `run` executable - [ ] pip/pipx - [ ] Other: [describe setup] **Version of Whoogle Search** - [ ] Latest build from [source] (i.e. GitHub, Docker Hub, pip, etc) - [x] Version [0.4.1] - [ ] Not sure **Server** Raspberry Pi 4 4GB `Linux alarm 5.11.4-1-ARCH #1 SMP Sun Mar 7 23:46:10 UTC 2021 aarch64 GNU/Linux` **Additional context** It started a few days ago and I don't think I've made any drastic changes. I tried recreating containers, restarting system, etc. Nothing has worked so far. docker-compose.yml ``` # cant use mem_limit in a 3.x docker-compose file in non swarm mode # see https://github.com/docker/compose/issues/4513 version: "2.4" services: whoogle-search: image: benbusby/whoogle-search:buildx-experimental container_name: whoogle volumes: - /etc/localtime:/etc/localtime:ro - ./whoogle.env:/whoogle/whoogle.env:ro restart: on-failure:5 mem_limit: 256mb memswap_limit: 256mb # user debian-tor from tor package user: '102' security_opt: - no-new-privileges cap_drop: - ALL read_only: true tmpfs: - /config/:size=10M,uid=102,gid=102,mode=1700 - /var/lib/tor/:size=10M,uid=102,gid=102,mode=1700 - /run/tor/:size=1M,uid=102,gid=102,mode=1700 environment: - WHOOGLE_DOTENV=1 ports: - 5000:5000 restart: unless-stopped ``` whoogle.env ``` WHOOGLE_CONFIG_ALTS=1 WHOOGLE_ALT_TW=nitter.42l.fr WHOOGLE_ALT_YT=invidious.tube WHOOGLE_ALT_IG=bib.actionsack.com/u WHOOGLE_ALT_RD=libredd.it WHOOGLE_CONFIG_LANGUAGE=lang_en WHOOGLE_CONFIG_DARK=1 WHOOGLE_CONFIG_NEW_TAB=1 # Open results in new tab # WHOOGLE_CONFIG_COUNTRY=countryGB # See app/static/settings/ # WHOOGLE_CONFIG_SEARCH_LANGUAGE=lang_en # WHOOGLE_USER="" # WHOOGLE_PASS="" # WHOOGLE_PROXY_USER="" # WHOOGLE_PROXY_PASS="" # WHOOGLE_PROXY_TYPE="" # WHOOGLE_PROXY_LOC="" # HTTPS_ONLY=1 # # WHOOGLE_CONFIG_DISABLE=1 # Disables changing of config from client # WHOOGLE_CONFIG_SAFE=1 # Safe searches # WHOOGLE_CONFIG_TOR=1 # Use Tor if available # WHOOGLE_CONFIG_GET_ONLY=1 # Search using GET requests only # WHOOGLE_CONFIG_URL=https://<whoogle url>/ # WHOOGLE_CONFIG_STYLE=":root { /* LIGHT THEME COLORS */ --whoogle-background: #d8dee9; --whoogle-accent: #2e3440; --whoogle-text: #3B4252; --whoogle-contrast-text: #eceff4; --whoogle-secondary-text: #70757a; --whoogle-result-bg: #fff; --whoogle-result-title: #4c566a; --whoogle-result-url: #81a1c1; --whoogle-result-visited: #a3be8c; /* DARK THEME COLORS */ --whoogle-dark-background: #222; --whoogle-dark-accent: #685e79; --whoogle-dark-text: #fff; --whoogle-dark-contrast-text: #000; --whoogle-dark-secondary-text: #bbb; --whoogle-dark-result-bg: #000; --whoogle-dark-result-title: #1967d2; --whoogle-dark-result-url: #4b11a8; --whoogle-dark-result-visited: #bbbbff; }" ``` Logs seem to be normal except for one: ``` ERROR:app:Exception on /autocomplete [POST] Traceback (most recent call last): File "/usr/local/lib/python3.8/site-packages/urllib3/connection.py", line 159, in _new_conn conn = connection.create_connection( File "/usr/local/lib/python3.8/site-packages/urllib3/util/connection.py", line 61, in create_connection for res in socket.getaddrinfo(host, port, family, socket.SOCK_STREAM): File "/usr/local/lib/python3.8/socket.py", line 918, in getaddrinfo for res in _socket.getaddrinfo(host, port, family, type, proto, flags): socket.gaierror: [Errno -3] Temporary failure in name resolution During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py", line 670, in urlopen httplib_response = self._make_request( File "/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py", line 381, in _make_request self._validate_conn(conn) File "/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py", line 976, in _validate_conn conn.connect() File "/usr/local/lib/python3.8/site-packages/urllib3/connection.py", line 308, in connect conn = self._new_conn() File "/usr/local/lib/python3.8/site-packages/urllib3/connection.py", line 171, in _new_conn raise NewConnectionError( urllib3.exceptions.NewConnectionError: <urllib3.connection.HTTPSConnection object at 0xffff88442550>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/local/lib/python3.8/site-packages/requests/adapters.py", line 439, in send resp = conn.urlopen( File "/usr/local/lib/python3.8/site-packages/urllib3/connectionpool.py", line 724, in urlopen retries = retries.increment( File "/usr/local/lib/python3.8/site-packages/urllib3/util/retry.py", line 439, in increment raise MaxRetryError(_pool, url, error or ResponseError(cause)) urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='suggestqueries.google.com', port=443): Max retries exceeded with url: /complete/search?client=toolbar&hl=&q=i (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0xffff88442550>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution')) During handling of the above exception, another exception occurred: 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 "/whoogle/app/routes.py", line 182, in autocomplete g.user_request.autocomplete(q) if not g.user_config.tor else [] File "/whoogle/app/request.py", line 187, in autocomplete response = self.send(base_url=AUTOCOMPLETE_URL, File "/whoogle/app/request.py", line 247, in send response = requests.get( File "/usr/local/lib/python3.8/site-packages/requests/api.py", line 76, in get return request('get', url, params=params, **kwargs) File "/usr/local/lib/python3.8/site-packages/requests/api.py", line 61, in request return session.request(method=method, url=url, **kwargs) File "/usr/local/lib/python3.8/site-packages/requests/sessions.py", line 530, in request resp = self.send(prep, **send_kwargs) File "/usr/local/lib/python3.8/site-packages/requests/sessions.py", line 643, in send r = adapter.send(request, **kwargs) File "/usr/local/lib/python3.8/site-packages/requests/adapters.py", line 516, in send raise ConnectionError(e, request=request) requests.exceptions.ConnectionError: HTTPSConnectionPool(host='suggestqueries.google.com', port=443): Max retries exceeded with url: /complete/search?client=toolbar&hl=&q=i (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0xffff88442550>: Failed to establish a new connection: [Errno -3] Temporary failure in name resolution')) ERROR:app:Exception on /autocomplete [POST] Traceback (most recent call last): File "/usr/local/lib/python3.8/site-packages/urllib3/connection.py", line 159, in _new_conn conn = connection.create_connection( File "/usr/local/lib/python3.8/site-packages/urllib3/util/connection.py", line 61, in create_connection for res in socket.getaddrinfo(host, port, family, socket.SOCK_STREAM): File "/usr/local/lib/python3.8/socket.py", line 918, in getaddrinfo for res in _socket.getaddrinfo(host, port, family, type, proto, flags): socket.gaierror: [Errno -3] Temporary failure in name resolution ``` Doing an `nslookup suggestqueries.google.com` on the host works fine and whoogle has worked fine in the past so I dunno what happened. Moreover, (maybe I'm doing it wrong), whoogle doesn't seem to pickup whoogle.env values. Doing a `echo $WHOOGLE_ALT_TW` prints the default value. Doing a `cat whoogle.env` inside the container reveals the custom settings so I don't know why whoogle is picking the default values.

kerem

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

closed this issue
added the
bug
label

kerem commented

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

Author

Owner

@benbusby commented on GitHub (May 3, 2021):

The correct way to load an environment variable file when using docker-compose is actually the env_file option -- sorry, I should've documented that better. It should look something like this:

...
  env_file:
    - whoogle.env
...

The only other issue is that some of the variables in your whoogle.env file still have comments after them, which is likely to cause problems (my fault for not arranging the comments better). I'll update docker-compose.yml with the env_file option and fix the comments in the whoogle.env template.

Regarding the slow searches on your Pi, that's been a somewhat known issue for a while. I haven't been able to track down why exactly it's so slow on the Pi, since the project isn't doing anything terribly complex. The requests library seems significantly slower overall on ARM devices (I'm specifically singling out requests since regular curl requests are on par with non-ARM devices from my tests). When you say

whoogle has worked fine in the past

do you mean request speed was fine in the past? Or has it always been slow?

@benbusby commented on GitHub (May 3, 2021): The correct way to load an environment variable file when using docker-compose is actually the [`env_file`](https://docs.docker.com/compose/environment-variables/#the-env_file-configuration-option) option -- sorry, I should've documented that better. It should look something like this: ```yml ... env_file: - whoogle.env ... ``` The only other issue is that some of the variables in your `whoogle.env` file still have comments after them, which is likely to cause problems (my fault for not arranging the comments better). I'll update `docker-compose.yml` with the `env_file` option and fix the comments in the `whoogle.env` template. Regarding the slow searches on your Pi, that's been a somewhat known issue for a while. I haven't been able to track down why exactly it's so slow on the Pi, since the project isn't doing anything terribly complex. The `requests` library seems significantly slower overall on ARM devices (I'm specifically singling out `requests` since regular curl requests are on par with non-ARM devices from my tests). When you say > whoogle has worked fine in the past do you mean request speed was fine in the past? Or has it always been slow?

kerem commented

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

Author

Owner

@benbusby commented on GitHub (May 3, 2021):

Also going to update the issue title to make it easier for others to find in search

@benbusby commented on GitHub (May 3, 2021): Also going to update the issue title to make it easier for others to find in search

kerem commented

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

Author

Owner

@accountForIssues commented on GitHub (May 4, 2021):

The correct way to load an environment variable file when using docker-compose is actually the env_file option -- sorry, I should've documented that better. It should look something like this:
...
  env_file:
    - whoogle.env
...

Damn I feel so stupid now. I know about the env_file usage in docker-compose but never made the connection in this case and didn't even try it. For some reason, I assumed whoogle.env to be a just another config file. Anyways, nice to see it documented though :)

I just updated my compose to include that and now the variables are correctly loaded. Fyi, the comments don't seem to affect anything.

Regarding the slow searches on your Pi, that's been a somewhat known issue for a while....

whoogle has worked fine in the past

do you mean request speed was fine in the past? Or has it always been slow?

Ever since I first started using whoogle (months ago), it has been working fast and fine. I was even surprised at how fast the autofill was but probably a week ago (maybe less), I started seeing that autofill was being slow and then the search started being very slow to just not being usable.

Also, I assume the Tor hearbeat notices in the log are normal even though I am not using Tor ? I always updated the docker images as soon as there was an update. Any change in the experimental tagged image that could have caused something like this ?

@accountForIssues commented on GitHub (May 4, 2021): > The correct way to load an environment variable file when using docker-compose is actually the [`env_file`](https://docs.docker.com/compose/environment-variables/#the-env_file-configuration-option) option -- sorry, I should've documented that better. It should look something like this: > > ```yaml > ... > env_file: > - whoogle.env > ... > ``` Damn I feel so stupid now. I know about the `env_file` usage in docker-compose but never made the connection in this case and didn't even try it. For some reason, I assumed `whoogle.env` to be a just another config file. Anyways, nice to see it documented though :) I just updated my compose to include that and now the variables are correctly loaded. Fyi, the comments don't seem to affect anything. > Regarding the slow searches on your Pi, that's been a somewhat known issue for a while.... > > > whoogle has worked fine in the past > > do you mean request speed was fine in the past? Or has it always been slow? Ever since I first started using whoogle (months ago), it has been working fast and fine. I was even surprised at how fast the autofill was but probably a week ago (maybe less), I started seeing that autofill was being slow and then the search started being very slow to just not being usable. Also, I assume the `Tor hearbeat` notices in the log are normal even though I am not using Tor ? I always updated the docker images as soon as there was an update. Any change in the `experimental` tagged image that could have caused something like this ?

kerem commented

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

Author

Owner

@ghost commented on GitHub (May 5, 2021):

I installed benbusby/whoogle-search 0.4.1 yesterday on 64bit Raspberry Pi 4B and it is not slow. It takes 1 second to get a result.

docker image inspect benbusby/whoogle-search:buildx-experimental
----------------------------------------------------------------
ID: "sha256:b32d36969db2d1843b3f14b85d90068e9d73dac6df794230a29ff51fb263c36d"
"RepoTags": "benbusby/whoogle-search:buildx-experimental"
"RepoDigests": "benbusby/whoogle-search@sha256:82b7e9cb3ace3a11c6dee3c75beda8b0a0d5e9ea5cd42da9453b6ac366689a62
"Created": "2021-05-03T18:41:11.051086901Z"

OS: Debian GNU/Linux 10 (buster) aarch64
Host: Raspberry Pi 4 Model B Rev 1.4
Kernel: 5.10.17-v8+

---
version: "2.1"
services:
  whoogle:
    image: benbusby/whoogle-search:buildx-experimental
    container_name: whoogle_1
    ports:
      - 7002:5000
    environment:
      #- WHOOGLE_CONFIG_COUNTRY	#Filter results by hosting country
      - WHOOGLE_CONFIG_LANGUAGE=lang_de	#Set interface language
      - WHOOGLE_CONFIG_SEARCH_LANGUAGE=lang_de	#Set search result language
      - WHOOGLE_CONFIG_ALTS=1	#Use social media site alternatives (nitter, invidious, etc)
      - WHOOGLE_ALT_TW=nitter.snopyta.org
      - WHOOGLE_ALT_YT=invidious.snopyta.org
      - WHOOGLE_ALT_IG=bibliogram.art/u
      - WHOOGLE_ALT_RD=libredd.it
    restart: unless-stopped

@ghost commented on GitHub (May 5, 2021): I installed `benbusby/whoogle-search` `0.4.1` yesterday on 64bit Raspberry Pi 4B and it is not slow. It takes 1 second to get a result. ```shell docker image inspect benbusby/whoogle-search:buildx-experimental ---------------------------------------------------------------- ID: "sha256:b32d36969db2d1843b3f14b85d90068e9d73dac6df794230a29ff51fb263c36d" "RepoTags": "benbusby/whoogle-search:buildx-experimental" "RepoDigests": "benbusby/whoogle-search@sha256:82b7e9cb3ace3a11c6dee3c75beda8b0a0d5e9ea5cd42da9453b6ac366689a62 "Created": "2021-05-03T18:41:11.051086901Z" ``` ```shell OS: Debian GNU/Linux 10 (buster) aarch64 Host: Raspberry Pi 4 Model B Rev 1.4 Kernel: 5.10.17-v8+ ``` ```docker --- version: "2.1" services: whoogle: image: benbusby/whoogle-search:buildx-experimental container_name: whoogle_1 ports: - 7002:5000 environment: #- WHOOGLE_CONFIG_COUNTRY #Filter results by hosting country - WHOOGLE_CONFIG_LANGUAGE=lang_de #Set interface language - WHOOGLE_CONFIG_SEARCH_LANGUAGE=lang_de #Set search result language - WHOOGLE_CONFIG_ALTS=1 #Use social media site alternatives (nitter, invidious, etc) - WHOOGLE_ALT_TW=nitter.snopyta.org - WHOOGLE_ALT_YT=invidious.snopyta.org - WHOOGLE_ALT_IG=bibliogram.art/u - WHOOGLE_ALT_RD=libredd.it restart: unless-stopped ```

kerem commented

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

Author

Owner

@accountForIssues commented on GitHub (May 5, 2021):

@m4rkv5 My experience was the same as yours until it just slowed down for no apparent reason. Can you check the docker logs and confirm whether you can lines similar to the ones below ? Check the number of circuits.

May 05 15:31:58.000 [notice] New control connection opened from 127.0.0.1.
May 05 15:31:58.000 [notice] Heartbeat: Tor's uptime is 6:34 hours, with 10 circuits open. I've sent 780 kB and received 3.38 MB.

@benbusby
Does the experimental tagged image enable and use tor by default even though it's not enabled in whoogle.env ?

It's possible that the slowdown and name resolution errors are being caused by the tor network. It still doesn't explain why the problems started in the last week or so though (could just be my network).

Using whoogle with pip works with zero issues and I don't see anything related to Tor in the debug logs.

Further, I also have a heroku instance that also works without any issues. The logs there do have the Tor heartbeats but with 0 circuits open.

@accountForIssues commented on GitHub (May 5, 2021): @m4rkv5 My experience was the same as yours until it just slowed down for no apparent reason. Can you check the docker logs and confirm whether you can lines similar to the ones below ? Check the number of circuits. ``` May 05 15:31:58.000 [notice] New control connection opened from 127.0.0.1. May 05 15:31:58.000 [notice] Heartbeat: Tor's uptime is 6:34 hours, with 10 circuits open. I've sent 780 kB and received 3.38 MB. ``` @benbusby Does the `experimental` tagged image enable and use tor by default even though it's not enabled in `whoogle.env` ? It's possible that the slowdown and name resolution errors are being caused by the tor network. It still doesn't explain why the problems started in the last week or so though (could just be my network). Using whoogle with pip works with zero issues and I don't see anything related to Tor in the debug logs. Further, I also have a heroku instance that also works without any issues. The logs there do have the `Tor heartbeats` but with **0 circuits open**.

kerem commented

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

Author

Owner

@benbusby commented on GitHub (May 5, 2021):

@accountForIssues glad the variables are loading correctly for you now!

Ever since I first started using whoogle (months ago), it has been working fast and fine. I was even surprised at how fast the autofill was but probably a week ago (maybe less), I started seeing that autofill was being slow and then the search started being very slow to just not being usable.

That's interesting. There haven't been any changes to the core request functionality in a while -- at least not in the past few weeks. I'll be the first to admit that I'm skeptical of how reliable the buildx-experimental tag is these days. I routinely have to restart that build for random errors (unrelated to the project), but I'm not sure how/if that could be related to the slow request speed you're witnessing.

Also, I assume the Tor hearbeat notices in the log are normal even though I am not using Tor

Yes, those are normal.

@m4rkv5 thanks for commenting with your experience!

I have a few Raspberry Pi 2Bs that I use for testing running the app manually and with the buildx-experimental tag, and the slow request issue seems to pop up for me on rare occasions.

At this point I'm not really sure of the best course of action. I'd rather not close the issue since the problem isn't necessarily resolved, but I'm also not sure how to debug further. I've been considering doing a full app refactor lately which could uncover some issue I haven't noticed, but otherwise I'm not sure what I can do to help.

@benbusby commented on GitHub (May 5, 2021): @accountForIssues glad the variables are loading correctly for you now! > Ever since I first started using whoogle (months ago), it has been working fast and fine. I was even surprised at how fast the autofill was but probably a week ago (maybe less), I started seeing that autofill was being slow and then the search started being very slow to just not being usable. That's interesting. There haven't been any changes to the core request functionality in a while -- at least not in the past few weeks. I'll be the first to admit that I'm skeptical of how reliable the `buildx-experimental` tag is these days. I routinely have to restart that build for random errors (unrelated to the project), but I'm not sure how/if that could be related to the slow request speed you're witnessing. > Also, I assume the Tor hearbeat notices in the log are normal even though I am not using Tor Yes, those are normal. ___ @m4rkv5 thanks for commenting with your experience! I have a few Raspberry Pi 2Bs that I use for testing running the app manually and with the `buildx-experimental` tag, and the slow request issue seems to pop up for me on rare occasions. At this point I'm not really sure of the best course of action. I'd rather not close the issue since the problem isn't necessarily resolved, but I'm also not sure how to debug further. I've been considering doing a full app refactor lately which could uncover some issue I haven't noticed, but otherwise I'm not sure what I can do to help.

kerem commented

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

Author

Owner

@ghost commented on GitHub (May 9, 2021):

Check the number of circuits.

@accountForIssues My whoogle is running without tor. When I enable Tor i get this message Error: "Tor query failed -- max attempts exceeded 10"
I don't know how to setup Tor correctly.

@ghost commented on GitHub (May 9, 2021): > Check the number of circuits. @accountForIssues My whoogle is running without tor. When I enable Tor i get this message `Error: "Tor query failed -- max attempts exceeded 10"` I don't know how to setup Tor correctly.

kerem commented

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

Author

Owner

@benbusby commented on GitHub (May 10, 2021):

@m4rkv5 that error you posted means that Tor is working correctly, but that Google is blocking the query for all of the exit nodes that were used. Whoogle only attempts to manually change exit nodes when a search is rejected, but this doesn't always guarantee a new identity.

@benbusby commented on GitHub (May 10, 2021): @m4rkv5 that error you posted means that Tor is working correctly, but that Google is blocking the query for all of the exit nodes that were used. Whoogle only attempts to manually change exit nodes when a search is rejected, but this doesn't always guarantee a new identity.

kerem commented

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

Author

Owner

@accountForIssues commented on GitHub (May 20, 2021):

@benbusby

I had stopped using whoogle on my pi since this issue but I decided to try it again. This time whoogle refused to even start, exiting at Temporary failure in name resolution errors.

I dug a little deeper and realized that all the docker containers on the pi weren't able to resolve dns but were connected to the internet. As most of my services are limited to the local network and/or use only IP addresses, I didn't notice anything wrong.

I, then, changed the dns the containers use at:

$ cat /etc/docker/daemon.json 
{ "dns": ["9.9.9.9"] }

Now, all the containers can resolve dns and connect to internet fine. Whoogle is back to it's speedy self.

Previously, I had used the default which meant AdGuardHome/unbound installed on the same pi deployed using docker.

It has worked fine for months before I had this issue so most likely something changed either in docker or system packages for the OS (Arch Linux ARM) that caused this issue. I haven't tried to find out more about this but if I do, I'll update my post here. For now, everything is fine.

@accountForIssues commented on GitHub (May 20, 2021): @benbusby I had stopped using whoogle on my pi since this issue but I decided to try it again. This time whoogle refused to even start, exiting at `Temporary failure in name resolution` errors. I dug a little deeper and realized that all the docker containers on the pi weren't able to resolve dns but were connected to the internet. As most of my services are limited to the local network and/or use only IP addresses, I didn't notice anything wrong. I, then, changed the dns the containers use at: ``` $ cat /etc/docker/daemon.json { "dns": ["9.9.9.9"] } ``` Now, all the containers can resolve dns and connect to internet fine. Whoogle is back to it's speedy self. Previously, I had used the default which meant AdGuardHome/unbound installed on the same pi deployed using docker. It has worked fine for months before I had this issue so most likely something changed either in docker or system packages for the OS (Arch Linux ARM) that caused this issue. I haven't tried to find out more about this but if I do, I'll update my post here. For now, everything is fine.

kerem commented

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

Author

Owner

@benbusby commented on GitHub (May 20, 2021):

That's great to hear that things are working again! I hadn't considered that it could be a DNS issue, but looking back it seems pretty clear from the traceback you posted originally.

In any case, thanks for posting the solution. Closing for now, but feel free to keep this post updated with anything you find. If you come across anything that you think warrants adding to the project readme/wiki, let me know and I'll gladly do so.

@benbusby commented on GitHub (May 20, 2021): That's great to hear that things are working again! I hadn't considered that it could be a DNS issue, but looking back it seems pretty clear from the traceback you posted originally. In any case, thanks for posting the solution. Closing for now, but feel free to keep this post updated with anything you find. If you come across anything that you think warrants adding to the project readme/wiki, let me know and I'll gladly do so.

kerem referenced this issue

2026-02-25 20:36:47 +03:00

[PR #210] [MERGED] Use multi-stage container build #810

Rows
Columns

[GH-ISSUE #303] [BUG] Slow search on Raspberry Pi and incorrect env variables #210