Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update running viewtube in a "crash" loop #2559

Open
ewoks opened this issue Jan 13, 2024 · 8 comments
Open

Update running viewtube in a "crash" loop #2559

ewoks opened this issue Jan 13, 2024 · 8 comments

Comments

@ewoks
Copy link

ewoks commented Jan 13, 2024

Describe the Bug

Setup/selfhosting on linux with portainer via example docker-compose (portainer stack), and after updates viewtube can't connect to redis and goes into crashloop.
Used compose.yaml in portainer stack has the depends_on: section with two dependee containers properly listed.
However when new image for viewtube appear and just that container restarts to use new image but redis and mongodb are still running from previous stack instance, viewtube can't start properly.

Steps to Reproduce the Bug

  1. run it via example docker-compose
  2. let image be updated with watchtower when new viewtube image is available
  3. although two support containers (redis, mongodb) still run viewtube container can't start properly

Expected Behaviour

after image update of viewtube, container can properly start and connect to already running support containers

Device Info

Linux with docker, portainer and watchtower

Additional Context

Observed this after every viewtube image update.

cc: @moisout

@moisout
Copy link
Member

moisout commented Jan 13, 2024

Hi, thank you for opening this issue. Would you be able to post your current docker conpose file?

@moisout
Copy link
Member

moisout commented Jan 13, 2024

And maybe you have the log messages of the ViewTube container? I am running watchtower as well for the production setup (https://viewtube.io) and it has worked for me, so I am curious to see what could be causing this issue.

@ewoks
Copy link
Author

ewoks commented Jan 13, 2024

Thanks for the fast acknowlegdement. Unfortunatelly, I restarted whole stack again to make FE go up, without saving logs, my bad sorry :( I'll save it on next update and add it...
Here is the compose (portainer "viewtube" stack), two db containers removed for brevity

version: '3'
services:
  viewtube:
    restart: unless-stopped
    image: mauriceo/viewtube:latest
    depends_on:
      - viewtube-mongodb
      - viewtube-redis
    networks:
      - viewtube
    volumes:
      - /viewtube/data:/data:rw
    environment:
      - VIEWTUBE_DATABASE_HOST=viewtube-mongodb
      - VIEWTUBE_REDIS_HOST=viewtube-redis
      - VIEWTUBE_CLUSTERED=false
      - YTDL_NO_UPDATE=true
    ports:
      - 8066:8066

  ...
  #other two containers, i.e. mongodb and redis...

@moisout
Copy link
Member

moisout commented Feb 1, 2024

I can't seem to reproduce it :( I will leave this issue open, and hopefully it will work for the next upgrade, or maybe you get a useful log message.

@ewoks
Copy link
Author

ewoks commented Feb 2, 2024

let's do so, I will save logs next time

@ewoks
Copy link
Author

ewoks commented Feb 24, 2024

Ok seems I got it again:
viewtube image digest sha256:11ed11c1ed0168aa07c912c2227f613d449e310de9cba8b00351b74203184e42 was detected yesterday, just that container of the whole stack (compose) was restarted and there was crash loop again.

ViewTube logs:

[ViewTube] Info	2/24/2024, 8:01:18 AM Checking Redis connection
/home/app/server/dist/main.cjs:18878
    throw new Error('Redis connection failed');
          ^

Error: Redis connection failed
    at checkRedisConnection (/home/app/server/dist/main.cjs:18878:11)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

Node.js v18.19.1
[ViewTube] Info	2/24/2024, 8:01:32 AM Starting with single node
[ViewTube] Info	2/24/2024, 8:01:32 AM Loaded configuration from /data/config.json
[ViewTube] Info	2/24/2024, 8:01:33 AM Running in production mode
[ViewTube] Info	2/24/2024, 8:01:33 AM Registration is enabled
[ViewTube] Info	2/24/2024, 8:01:33 AM Login is required everywhere: false
[ViewTube] Info	2/24/2024, 8:01:33 AM Checking Redis connection
/home/app/server/dist/main.cjs:18878
    throw new Error('Redis connection failed');
          ^

Although Redis didn't update (fixed to image: redis:7), there were errors in a Redis container:

* 1 changes in 3600 seconds. Saving...
* Background saving started by pid 25078
# Failed opening the temp RDB file temp-25078.rdb (in server root dir /data) for saving: Permission denied
# Background saving error
* 1 changes in 3600 seconds. Saving...
* Background saving started by pid 25079
# Failed opening the temp RDB file temp-25079.rdb (in server root dir /data) for saving: Permission denied
# Background saving error

etc..

Can it be that previous viewtube went down "dirty" which brought Redis above visible error loop and didn't allow it to accept connections from new instance?

Stopping whole stack and starting it again, resolved the issue (like previous times).
At this moment redis volume has just dump.rdb file.

Let me know if you need more info.

@moisout
Copy link
Member

moisout commented Feb 24, 2024

Could you send the docker compose part for redis and mongodb?

@ewoks
Copy link
Author

ewoks commented May 5, 2024

Missed this until now somehow, sorry for that.. here follows the important part of compose.yaml

version: '3.9'
services:
  viewtube:
    restart: unless-stopped
    image: mauriceo/viewtube:latest 
    depends_on: 
      - viewtube-mongodb
      - viewtube-redis
    networks:
      - viewtube
  ...

of course viewtube-mongodb & viewtube-redis sections are below in the same file.

In all honesty, I didn't notice previously described issue since my last comment. I will observe this again, and close if nothing similar occurs for the next update or two. Cheers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants