Closed GH0STDATA closed 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 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.
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. :/
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.
Having the same problem. If I can help debug this let me know.
Have the same issue :-(
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.
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).
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
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.
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 .
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.
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 .
@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 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.
Sorry, same problem with :test :-(
PHP 7.4.15 (cli) (built: Feb 2 2021 18:30:22) ( NTS )
@binhex I just tested a magnet link and could not reproduce this crash on my end.
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.
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]#
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.
Uhh, so rm test, up latest, delete file(), rm latest, up test? Why have the file recreated to then delete it?
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.
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.'.
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.
File was recreated but rtorrent still won't start.
Is there a working version i can install while you fix the bugs in latest?
Is there a working version i can install while you fix the bugs in latest?
See the issue description.
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.
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.
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 !
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
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 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
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.
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?
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.
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.
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.
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).
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.