linuxserver / docker-speedtest-tracker

GNU General Public License v3.0
87 stars 2 forks source link

[BUG] Error 500 when using this image over dev's image #9

Closed joshoram80 closed 7 months ago

joshoram80 commented 8 months ago

Is there an existing issue for this?

Current Behavior

Trying to access the page, either via reverse proxy, or directly via HostIP:Port results in a 500 error. There is no error show in docker logs. Works fine using image from dev's repository (albeit older version). I have tried switching to sqlite instead of my working mysql setup and nothing changes.

Expected Behavior

Page should load

Steps To Reproduce

  1. Replace working image in docker compose with "drop in replacement" LinuxServer image.
  2. Spin Up docker compose
  3. Pulls latest image.
  4. 500 Error

Environment

- OS: Ubuntu 20.04
- Docker installed via apt

CPU architecture

x86-64

Docker creation

speedtest:
    image: lscr.io/linuxserver/speedtest-tracker:latest
    container_name: speedtest
    restart: unless-stopped
    networks:
      - t2_proxy
      - database
    ports:
      - '8780:80'
      - '8443:443'
    environment:
      - PUID=1000
      - PGID=1000
      - DB_CONNECTION=sqlite
      #- DB_HOST=mariadb
      #- DB_PORT=3306
      #- DB_DATABASE=speedtest
      #- DB_USERNAME=$SPEEDTEST_DB_USERNAME
      #- DB_PASSWORD=$SPEEDTEST_DB_PASSWORD
      - TZ=$TZ
      - APP_KEY=$SPEEDTEST_APP_KEY

Container logs

───────────────────────────────────────
GID/UID
───────────────────────────────────────

User UID:    1000
User GID:    1000
───────────────────────────────────────

using keys found in /config/keys
**** The following active confs have different version dates than the samples that are shipped. ****
**** This may be due to user customization or an update to the samples. ****
**** You should compare the following files to the samples in the same folder and update them. ****
**** Use the link at the top of the file to view the changelog. ****
┌────────────┬────────────┬────────────────────────────────────────────────────────────────────────┐
│  old date  │  new date  │ path                                                                   │
├────────────┼────────────┼────────────────────────────────────────────────────────────────────────┤
│ 2018-08-16 │ 2023-04-13 │ /config/nginx/nginx.conf                                               │
│            │ 2023-04-13 │ /config/nginx/site-confs/default.conf                                  │
└────────────┴────────────┴────────────────────────────────────────────────────────────────────────┘
[custom-init] No custom files found, skipping...
[ls.io-init] done.
github-actions[bot] commented 8 months ago

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

pwatkins30 commented 8 months ago

I am also having this issue.

burnbrigther commented 8 months ago

I am also having this issue - reverting to henrywhitaker3/speedtest-tracker for testing: Yep, reverting fixes everything. Workaround in place.

homerr commented 7 months ago

I've just spun this up to test it, without issue. I'd probably not recommend using ours as a drop in replacement, it could work but there does appear to be a breaking change in versions not too long ago. Closing this out.

burnbrigther commented 7 months ago

Hi - sorry - can you please explain why its not a good idea to use your image as a drop replacement? Are there fundamental differences? I was under the impression your image was maintained, and so switched to using yours. I am happy to assist in helping you troubleshoot this. I really don't have anything too exotic in my set up that would have caused this. Thanks

thespad commented 7 months ago

It was designed as a drop-in replacement but we've only tested like-for-like versions, so if you're still running an older version of the original image we can't guarantee that it will seemlessly switch to ours.

burnbrigther commented 7 months ago

doing an image force-recreate should address that?

thespad commented 7 months ago

Depends entirely on what the issue is. Please set APP_DEBUG=True, recreate the container, replicate the error, and then post the container logs.

Manichee commented 7 months ago

I had the same issue. To get around it for myself I stopped the container, removed the nginx folder in the config directory, and started the container. Once I did this it started working again.