binhex / arch-rtorrentvpn

Docker build script for Arch Linux base with ruTorrent, rTorrent, autodl-irssi, Privoxy and OpenVPN
GNU General Public License v3.0
238 stars 35 forks source link

Plugins not working with latest rtorrentvpn builds #176

Closed GH0STDATA closed 3 years ago

GH0STDATA commented 3 years ago

As of the past two latest rtorrentvpn builds, my plugins will no longer load properly in rutorrent. The logs state that the rtorrent user cannot access external programs, most of which are located in /usr/bin. There are multiple users besides myself experiencing this issue: https://forums.unraid.net/topic/46127-support-binhex-rtorrentvpn/?do=findComment&comment=953905

The current workaround is to roll back to an older release, more specifically rtorrent-ps-1.1.r54.ga787dd9-1-29, which was stated in this comment on the unraid forum. I've done this myself and confirmed that it is working properly again with that build.

MystykRiver commented 3 years ago

I looked into this a little and while I don't know why, it appears that test -x is failing when it tests for executability by the user. I couldn't get test -x to succeed in script or through the command line. So /usr/share/webapps/rutorrent/php/test.sh is failing when testing many of the plugins even though they should pass all the checks and run.

The quick fix was to modify test.sh so that it didn't run the test -x and only ran test -f. If you are running with the stock plugins, shouldn't be an issue. Just edit the file and where you see "test -x" (without the quotes), change to "test -f" (without the quotes).

Ultimately I don't think this is the correct fix, but I unfortunately don't have any more time to spend on this.

sharkymcdongles commented 3 years ago

I am facing the same problem. I checked another thread and they said changing execute to execute2 might help, but it made no difference for me.

sharkymcdongles commented 3 years ago

So I checked the settings and saw:

    $pathToExternals = array(
            "php"           => '/usr/bin/php',              // Something like /usr/sbin/php. If empty, will be found in PATH.
            "curl"          => '/usr/bin/curl',             // Something like /usr/sbin/curl. If empty, will be found in PATH.
            "gzip"          => '/usr/bin/gzip',             // Something like /usr/sbin/gzip. If empty, will be found in PATH.
            "id"            => '/usr/bin/id',               // Something like /usr/sbin/id. If empty, will be found in PATH.
            "mediainfo"     => '/usr/bin/mediainfo',        // Something like /usr/sbin/id. If empty, will be found in PATH.
            "python"        => '/usr/bin/python',           // Something like /usr/sbin/python. If empty, will be found in PATH.
            "pgrep"         => '/usr/bin/pgrep',            // Something like /usr/sbin/pgrep. If empty, will be found in PATH.
            "sox"           => '/usr/bin/sox',              // Something like /usr/sbin/sox. If empty, will be found in PATH.
            "stat"          => '/usr/bin/stat',             // Something like /usr/sbin/stat. If empty, will be found in PATH.

but within the container path was actually sbin, so I changed it to:

    $pathToExternals = array(
            "php"           => '/usr/sbin/php',              // Something like /usr/sbin/php. If empty, will be found in PATH.
            "curl"          => '/usr/sbin/curl',             // Something like /usr/sbin/curl. If empty, will be found in PATH.
            "gzip"          => '/usr/sbin/gzip',             // Something like /usr/sbin/gzip. If empty, will be found in PATH.
            "id"            => '/usr/sbin/id',               // Something like /usr/sbin/id. If empty, will be found in PATH.
            "mediainfo"     => '/usr/sbin/mediainfo',        // Something like /usr/sbin/id. If empty, will be found in PATH.
            "python"        => '/usr/sbin/python',           // Something like /usr/sbin/python. If empty, will be found in PATH.
            "pgrep"         => '/usr/sbin/pgrep',            // Something like /usr/sbin/pgrep. If empty, will be found in PATH.
            "sox"           => '/usr/sbin/sox',              // Something like /usr/sbin/sox. If empty, will be found in PATH.
            "stat"          => '/usr/sbin/stat',             // Something like /usr/sbin/stat. If empty, will be found in PATH.

Seems it didn't help though. :/

binhex commented 3 years ago

ive seen a few reports of this, but i have yet to be able to replicate it, if i do a fresh install it runs fine for me, no issue, so i dont know yet what the cause is.

theotherp commented 3 years ago

Having the same problem. If I can help debug this let me know.

thiesens commented 3 years ago

Have the same issue :-(

sharkymcdongles commented 3 years ago

Having the same problem. If I can help debug this let me know.

@theotherp I am too lazy to do this right now as I'm on vacation, but if you can run the container fresh without any of your configuration then paste me the configuration for rutorrent here I can probably solve the issue.

/config/rutorrent/conf/plugins.ini and config.php

This approach will only work if plugins work properly when run fresh as @binhex suggests.

theotherp commented 3 years ago

Thanks for the offer but it's a completely fresh install. I created the container and that message is kinda the first thing I saw - so it's not anything related to my config (at least nothing outside my docker compose script).

theotherp commented 3 years ago

FWIW this is the relevant part of my docker-compose:

  rtorrent:
    image: binhex/arch-rtorrentvpn
    hostname: ${DOCKERHOSTNAME}
    cap_add:
    - NET_ADMIN
    ports:
    - 127.0.0.1:9080:9080
    - 127.0.0.1:9443:9443
    - 127.0.0.1:8119:8118
    container_name: rtorrent
    environment:
    - PGID=1000
    - PUID=1000
    - TZ=${TZ}
    - VPN_ENABLED=yes
    - VPN_USER=<user>
    - VPN_PASS=<pass>
    - VPN_PORT=443
    - VPN_PROTOCOL=udp
    - VPN_DEVICE_TYPE=tun
    - VPN_PROV=pia
    - VPN_CLIENT=openvpn
    - STRICT_PORT_FORWARD=yes
    - ENABLE_PRIVOXY=true
    - NAME_SERVERS=8.8.8.8
    - DELUGE_DAEMON_LOG_LEVEL=info
    - DELUGE_WEB_LOG_LEVEL=info
    - LAN_NETWORK=<local>
    - DEBUG=true
    - ENABLE_RPC2=yes
    - ENABLE_RPC2_AUTH=yes
    - ENABLE_WEBUI_AUTH=yes
    - RPC2_USER=<user> 
    - RPC2_PASS=<pass>
    - WEBUI_USER=<user>
    - WEBUI_PASS=<pass>
    logging:
      driver: json-file
      options:
        max-file: ${DOCKERLOGGING_MAXFILE}
        max-size: ${DOCKERLOGGING_MAXSIZE}
    restart: unless-stopped
    volumes:
    - /etc/localtime:/etc/localtime:ro
    - ${DOCKERCONFDIR}/rtorrent:/config
    - ${DOCKERSHAREDDIR}:/shared
    - ${DOWNLOADSDIR}:/downloads
    - ${BASEDIR}:/basedir
    - ${TEMPDIR}:/temp
    - ${LOGSDIR}/rtorrent:/logs
binhex commented 3 years ago

hi guys, whilst i have still not been able to replicate this issue exactly, i have seen some stability issues with the current latest. looking at the version of php i noticed it has been bumped to php8 and i think this may well be the issue, so i have created a 'test' tagged image with php7, if you suffer from the plugin issue then please give it a try:-

docker pull binhex/arch-rtorrentvpn:test

then delete existing container and re-create.

sharkymcdongles commented 3 years ago

This gives me something to work from. I will do a deep dive this evening and see if a soiution can be found. I suspect php ini may need adjustment which explains why it works on new deploys and not existing ones.

On Mon, 15 Mar 2021, 12:43 binhex, @.***> wrote:

hi guys, whilst i have still not been able to replicate this issue exactly, i have seen some stability issues with the current latest. looking at the version of php i noticed it has been bumped to php8 and i think this may well be the issue, so i have created a 'test' tagged image with php7, if you suffer from the plugin issue then please give it a try:-

docker pull binhex/arch-rtorrentvpn:test

then delete existing container and re-create.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/binhex/arch-rtorrentvpn/issues/176#issuecomment-799352912, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG6KEULTLI2REUV5E26WY3TTDXXFDANCNFSM4YV6QWRQ .

binhex commented 3 years ago

This gives me something to work from. I will do a deep dive this evening and see if a soiution can be found. I suspect php ini may need adjustment which explains why it works on new deploys and not existing ones.

you shouldnt need to do anything tbh, just pull down the 'test' tagged image, if it works then it wil get tagged as latest.

sharkymcdongles commented 3 years ago

I'd much rather have it work with php 8 natively than downgrading php if possible. That is why I wanna solve it this way rather than the easier solution. If I can't solve this way then I will go with downgrading to 7 as that may be the only way because it is possible the issue is within the php code rather than the configuration. Thanks so much for the hard work on this and supporting it!

On Mon, 15 Mar 2021, 12:56 binhex, @.***> wrote:

This gives me something to work from. I will do a deep dive this evening and see if a soiution can be found. I suspect php ini may need adjustment which explains why it works on new deploys and not existing ones.

you shouldnt need to do anything tbh, just pull down the 'test' tagged image, if it works then it wil get tagged as latest.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/binhex/arch-rtorrentvpn/issues/176#issuecomment-799360377, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG6KEULOMLWVZK2E6U2XLCLTDXYVVANCNFSM4YV6QWRQ .

sharkymcdongles commented 3 years ago

@binhex You were right about it being PHP version related, thanks for the hint. I solved this by deleting the php.ini I had in my mounted config dir and allowing the container to recreate it fresh. The recreated one allowed it to work without issues, and the errors have now disappeared. I recommend leaving 8 and explaining this breaking change / fix.

It is very strange because I did a diff of the two files and see nothing different between the two to cause this behavior. Perhaps the ownership of the file changes when recreated or something. Either way, easy solution is to delete existing php.ini from host path or volume mount and allow the image to recreate it.

binhex commented 3 years ago

@binhex You were right about it being PHP version related, thanks for the hint. I solved this by deleting the php.ini I had in my mounted config dir and allowing the container to recreate it fresh. The recreated one allowed it to work without issues, and the errors have now disappeared. I recommend leaving 8 and explaining this breaking change / fix.

It is very strange because I did a diff of the two files and see nothing different between the two to cause this behavior. Perhaps the ownership of the file changes when recreated or something. Either way, easy solution is to delete existing php.ini from host path or volume mount and allow the image to recreate it.

whilst this is good news that you have a fix for your particular issue it does concern me that i saw stability issues with rtorrent, i could reproduce a crash of rtorrent by simply adding in a magnet link, switched it back to php7 and no issue so i think this needs further investigation before we can say everything is back to working correctly.

theotherp commented 3 years ago

Sorry, same problem with :test :-( PHP 7.4.15 (cli) (built: Feb 2 2021 18:30:22) ( NTS )

sharkymcdongles commented 3 years ago

@binhex I just tested a magnet link and could not reproduce this crash on my end.

binhex commented 3 years ago

Sorry, same problem with :test :-( PHP 7.4.15 (cli) (built: Feb 2 2021 18:30:22) ( NTS )

try deleting the file /config/rutorrent/php/php.ini and then restart the container.

theotherp commented 3 years ago

try deleting the file /config/rutorrent/php/php.ini and then restart the container.

The folder is empty.

[root@dockerhost php]# pwd
/config/rutorrent/php
[root@dockerhost php]# ls -la
total 8
drwxrwxrwx 2 nobody users 4096 Mar 15 14:17 .
drwxrwxrwx 6 nobody users 4096 Mar 15 14:17 ..
[root@dockerhost php]#
binhex commented 3 years ago

The folder is empty.

ughh sorry thats probably broken in the test image due to my switch to php7, switch the image back to 'latest' and it will re-create the file.

theotherp commented 3 years ago

Uhh, so rm test, up latest, delete file(), rm latest, up test? Why have the file recreated to then delete it?

binhex commented 3 years ago

Uhh, so rm test, up latest, delete file(), rm latest, up test? Why have the file recreated to then delete it?

no, switch back to tagged 'latest', this will auto re-create the php.ini file, see if plugins are operational.

theotherp commented 3 years ago

Now rtorrent won't start at all.

I found this single line in the rtorrent.log: 1615829835 C Caught exception: 'Error in option file: ~/.rtorrent.rc:61: Bad return code.'.

binhex commented 3 years ago

Now rtorrent won't start at all.

I found this single line in the rtorrent.log: 1615829835 C Caught exception: 'Error in option file: ~/.rtorrent.rc:61: Bad return code.'.

hmm odd!, ok rename the file /config/rtorrent/config/rtorrent.rc, this will also get re-created on restart of the container.

theotherp commented 3 years ago

File was recreated but rtorrent still won't start.

thiesens commented 3 years ago

Is there a working version i can install while you fix the bugs in latest?

theotherp commented 3 years ago

Is there a working version i can install while you fix the bugs in latest?

See the issue description.

binhex commented 3 years ago

File was recreated but rtorrent still won't start.

ok please start a new issue, as it is no longer related to the plugins issue and we can debug from there, its porbably a vpn related issue now.

binhex commented 3 years ago

Is there a working version i can install while you fix the bugs in latest?

are you seeing the plugins issue as described in the OP, if not then raise a new issue.

trif666 commented 3 years ago

Hello,

I encounter same PHP issues since the latest tag.

I have tried to switch to "test" tag but after container recreated, PHP errors still present

Here is the docker-compose concerning rutorrent-vpn :

rutorrent-vpn:

image: binhex/arch-rtorrentvpn

image: binhex/arch-rtorrentvpn:test # Temp branch to fix PHP issues (https://github.com/binhex/arch-rtorrentvpn/issues/176) container_name: rutorrent-vpn restart: unless-stopped cap_add:

  • NET_ADMIN environment:
  • VPN_ENABLED=yes
  • VPN_USER=xxxxxxx
  • VPN_PASS=xxxxxxx
  • VPN_PROV=custom
  • STRICT_PORT_FORWARD=no
  • ENABLE_PRIVOXY=no
  • ENABLE_AUTODL_IRSSI=no
  • ENABLE_RPC2=yes
  • ENABLE_RPC2_AUTH=no
  • ENABLE_WEBUI_AUTH=no
  • LAN_NETWORK=0.0.0.0/0
  • VPN_INPUT_PORTS=6881
  • NAME_SERVERS=1.1.1.1,1.0.0.1
  • DEBUG=false
  • PHP_TZ=Europe/Paris
  • UMASK=0022
  • PUID=1000
  • PGID=1000 volumes:
  • ./docker/rutorrent-vpn:/config
  • ./rutorrent-data:/data
  • /etc/localtime:/etc/localtime:ro networks:
  • web

Here is what I tried :

However, PHP version in container is 7 :

[root@22e494034f60 /]# php --version PHP 7.4.15 (cli) (built: Feb 2 2021 18:30:22) ( NTS ) Copyright (c) The PHP Group Zend Engine v3.4.0, Copyright (c) Zend Technologies

I also tried to create fresh container based on "latest" tag unsuccessfully

Is there some other checks/modifications that I could try ?

Thanks for your help and for this great work !

spencerhughes commented 3 years ago

I looked into this a little and while I don't know why, it appears that test -x is failing when it tests for executability by the user. I couldn't get test -x to succeed in script or through the command line. So /usr/share/webapps/rutorrent/php/test.sh is failing when testing many of the plugins even though they should pass all the checks and run.

The quick fix was to modify test.sh so that it didn't run the test -x and only ran test -f. If you are running with the stock plugins, shouldn't be an issue. Just edit the file and where you see "test -x" (without the quotes), change to "test -f" (without the quotes).

Ultimately I don't think this is the correct fix, but I unfortunately don't have any more time to spend on this.

I can confirm that this workaround makes the plugins load again. I also tried manually running test -x /usr/bin/php; echo $? and it returns 1 so for some reason test is failing. When you check the permissions on the files they have the executable bit set so it does seem like it's test's fault.

[root@84d8db107c4c /]# test -x /usr/bin/php; echo $?; test -x /usr/bin/php7; echo $?; ls -l /usr/bin/php; ls -l /usr/bin/php7
1
1
lrwxrwxrwx 1 root root 13 Mar 15 11:32 /usr/bin/php -> /usr/bin/php7
-rwxr-xr-x 1 root root 16793976 Feb  2 18:30 /usr/bin/php7
binhex commented 3 years ago

i have got to the bottom of this issue, its related to glibc package upgrade and incompatibiity with older versions of Docker 'runc', you can upgrade your version of runc by downloading the latest statically built runc version from here:- https://github.com/opencontainers/runc/releases/download/v1.0.0-rc93/runc.amd64

or alternatively grab it from my repo by issuing the following command on your host (not container):- curl -o '/usr/bin/runc' -L 'https://github.com/binhex/arch-packages/raw/master/static/x86-64/runc' && chmod +x '/usr/bin/runc'

sharkymcdongles commented 3 years ago

i have got to the bottom of this issue, its related to glibc package upgrade and incompatibiity with older versions of Docker 'runc', you can upgrade your version of runc by downloading the latest statically built runc version from here:- https://github.com/opencontainers/runc/releases/download/v1.0.0-rc93/runc.amd64

or alternatively grab it from my repo by issuing the following command on your host (not container):- curl -o '/usr/bin/runc' -L 'https://github.com/binhex/arch-packages/raw/master/static/x86-64/runc' && chmod +x '/usr/bin/runc'

I guess that explains why mine works since I upgraded my docker as well. Thanks for the deep investigation! I will throw you some more beer money soon. <3

GH0STDATA commented 3 years ago

i have got to the bottom of this issue, its related to glibc package upgrade and incompatibiity with older versions of Docker 'runc', you can upgrade your version of runc by downloading the latest statically built runc version from here:- https://github.com/opencontainers/runc/releases/download/v1.0.0-rc93/runc.amd64

or alternatively grab it from my repo by issuing the following command on your host (not container):- curl -o '/usr/bin/runc' -L 'https://github.com/binhex/arch-packages/raw/master/static/x86-64/runc' && chmod +x '/usr/bin/runc'

I can also confirm that updating runc has fixed my problem as well. All plugins are loading fine on the latest rtorrentvpn docker build.

Sebiann commented 3 years ago

So i tried updating runc and also deleted the php.ini file, restarted server and everything. Still can't get it too work Any ideas?

genebeck commented 3 years ago

I have the same issue. Using docker on windows 10 with wls2 backend. Tried all the same tricks and none of the plugins will start. PHP version is 8.0.2. Runc was updated to v1.0.0-rc93.

Just changed test.sh from test -x to test -f and magically everything started working.

binhex commented 3 years ago

So i tried updating runc and also deleted the php.ini file, restarted server and everything. Still can't get it too work Any ideas?

please can issue the command docker version and paste the output, i want to ensure that runc is up to date and docker sees it as the latest version.

just a quick note in case you are a unraid user - rebooting will reset runc back to the old version, you need to re-run the upgrade on subsequent reboots, or put it in your 'go' file.

genebeck commented 3 years ago

I edited the test.sh and changed test -x test -f and it did start working.

Meanwhile I have ditched docker and windows on that computer and am looking for a linux distro that matches me and my workflow. Sorry, but further testing will be impossible.

binhex commented 3 years ago

For now i have gone with the hack of removing test -x from the test.sh script, please pull down latest image and let me know if it fixes the plugin issue for you guys (cannot replicate).