theotherp / nzbhydra2

Usenet meta search
Other
1.23k stars 75 forks source link

Unable to Update Hydra2 inside of docker #60

Closed whispy closed 6 years ago

whispy commented 6 years ago

Current version: 1.0.16 (but issue has occurred in previous versions)

When I try to update Hydra2 via the in-app updater, it restarts and is the same version it was prior to running the updater. I am running it via a Docker container (tried updating with both theotherp's image and lsio's image).

I am aware that Docker containers can also be updated by restarting the container, but usually I have no issues updating via in-app updaters.

Here is a snippet from the log file (please let me know if you'd like more log info or debuginfos):

2018-01-13 21:50:59,353  INFO - NZBHydra main process has terminated for updating
2018-01-13 21:50:59,428  INFO - Extracting updated files to /app/hydra2
Traceback (most recent call last):
  File \"nzbhydra2wrapper.py\", line 481, in <module>
    update()
  File \"nzbhydra2wrapper.py\", line 173, in update
    zf.extract(member, basePath)
  File \"/usr/lib/python2.7/zipfile.py\", line 1028, in extract
    return self._extract_member(member, path, pwd)
  File \"/usr/lib/python2.7/zipfile.py\", line 1083, in _extract_member
    file(targetpath, \"wb\") as target:
IOError: [Errno 13] Permission denied: u'/app/hydra2/systemd/nzbhydra2.service'
Logging wrapper output to /config/logs/wrapper.log
"2018-01-13 21:51:01,867  INFO - Starting NZBHydra main process with command line: java -Xmx128M -DfromWrapper -XX:TieredStopAtLevel=1 -noverify -Dspring.output.ansi.enabled=ALWAYS -jar /app/hydra2/lib/core-1.0.16-exec.jar --nobrowser --datafolder /config in folder /app/hydra2

If you want to just file this under "Docker issue, unfixable", fine with me, I guess.

juanchristian commented 6 years ago

Same issue, can't update dockerized hydra2 via in-app. Using linuxserver.io

rubberbandboy commented 6 years ago

The linuxserver.io issue is it's looking for control.id in the wrong place.

Script looks for /app/hydra2/data/control.id but it's located in /config

I created a symlink to the config directory (called data) in /app/hydra2/ and it all works for me.

rubberbandboy commented 6 years ago

Although the shown error appears to be permissions - (did you set PGID and PUID in the docker correct) the control.id is another issue I faced

theotherp commented 6 years ago

The error with the control.id should be updated the next time you pull your container.

The other error I can't help you with. It depends on the container that you use. Mine and that by linuxserver.io should be able to update itself. The one by binhex cannot update itself internally.

I was told that docker containers should be updated by pulling a new version. Sounds like more work to me, but what do I know.

So yeah, sorry, will close this as unsolvable for me. You could ask the docker container maintainer. If that's me, sorry, use another container ;-)

bablat commented 6 years ago

I wouldn't recommend updating the code, updating the container is much safer. My primary concern is usually around forward-compatibility of configuration/database: If a user upgrades from 1.0 to 1.1 (inside container), v1.1 could introduce configuration/schema updates and migrate the configuration to the new format. If the container itself is then recreated, you risk downgrading the code back to v1.0, and if your configuration resides on a mounted volume - you're now running v1.0 with v1.1 configuration schema.

If upgrading the container is difficult, try using something like WatchTower to automate that. I found it to be very useful.

theotherp commented 6 years ago

That's a good point that I hadn't thought about.

Am 17.01.2018 1:51 nachm. schrieb "bablat" notifications@github.com:

I wouldn't recommend updating the code, updating the container is much safer. My primary concern is usually around forward-compatibility of configuration/database: If a user upgrades from 1.0 to 1.1 (inside container), v1.1 could introduce configuration/schema updates and migrate the configuration to the new format. If the container itself is then recreated, you risk downgrading the code back to v1.0, and if your configuration resides on a mounted volume - you're now running v1.0 with v1.1 configuration schema.

If upgrading the container is difficult, try using something like WatchTower https://github.com/v2tec/watchtower to automate that. I found it to be very useful.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/theotherp/nzbhydra2/issues/60#issuecomment-358294742, or mute the thread https://github.com/notifications/unsubscribe-auth/ANtAeUhwl-ovg0ARjyME_RJ9GZoc-fO3ks5tLezNgaJpZM4RdYkK .

whispy commented 6 years ago

Just a follow up — seems like the linuxserver.io container's image now properly works to update outside of the container.