Latest docker fails to start rTorrent
lyz-code opened this issue ยท 30 comments
Hi, I'm encountering errors starting rTorrent with the latest docker (digest 4df0a91a3320
).
When I switch back to the previous version (digest 5a9ee3635850
) it starts working again.
I've done a diff in the docker logs
of both docker run
s and the only relevant lines I've found are:
2021-11-18 DEBG 'watchdog-script' stdout output:
no suitable socket path
2021-11-18 DEBG 'watchdog-script' stdout output:
[warn] Wait for rTorrent process to start aborted, too many retries
2021-11-18 DEBG 'watchdog-script' stdout output:
[warn] Failed to start rTorrent, skipping initialisation of ruTorrent Plugins...
Thanks for maintaining this awesome Docker :)
I have been dealing with this same behavior for a while. Any time I update any of the values for the container, it fails to start with the same logging behavior as above, and doesn't work unless I delete most of the appdata or change PGID and PUID to 0. Same issue as #167
Hi, I'm encountering errors starting rTorrent with the latest docker (digest
4df0a91a3320
).When I switch back to the previous version (digest
5a9ee3635850
) it starts working again.I've done a diff in the
docker logs
of bothdocker run
s and the only relevant lines I've found are:2021-11-18 DEBG 'watchdog-script' stdout output: no suitable socket path 2021-11-18 DEBG 'watchdog-script' stdout output: [warn] Wait for rTorrent process to start aborted, too many retries 2021-11-18 DEBG 'watchdog-script' stdout output: [warn] Failed to start rTorrent, skipping initialisation of ruTorrent Plugins...
Thanks for maintaining this awesome Docker :)
Any way you can get me the full tag, digest, etc for the version that does work?
Hello, we encounter the same problem here. We resolve it with a chown -R USER: /path/to/folder/rtorrentvpn.
The env variable PUID / PGID seem to not effect...
Any idea ?
I'm having this issue too. It was working a couple weeks ago, but not anymore. Out of the blue. Tried to change folder perms, changed PUID/GUID, etc. Started a new container completely fresh and still no dice.
Same issue here. Any fix for this?
I resolved this issue by going into the container docker exec -it <container-name> /bin/bash
and then navigating to the config directory /config
and removing three files that were owned by root, perms.txt
, supervisor.log
, and supervisor.log.1
. After restarting everything worked correctly. Best guess is that the perms.txt
file getting deleted is what really did the trick there.
Didn't work out...
@binhex Any major change to rtorrent lately? Everything after binhex/arch-rtorrentvpn:rtorrent-ps-1.1.r54.ga787dd9-1-35
isn't working.
It's an issue due to an execute function :
rtorrent.rc line 61 & 68
execute = {/bin/bash,-c,mkdir -p /data/incomplete}
execute = {/bin/bash,-c,mkdir -p /config/rtorrent/session}
It's work with root uid/guid
It's work with root uid/guid
Yes, but that doesn't feel very good. ๐
It's work with root uid/guid
And it doesn't resolve any issues for me either; still won't work with root UID and GID.
Switched to https://hotio.dev/containers/qflood/ after several years with this container.
It's been a good run, but now it's over.
@enoch85 I also switched to a hotio container. Not excited to have to use Wireguard instead OpenVPN.
Not excited to have to use Wireguard instead OpenVPN.
Well, it's faster and not that hard to setup. It's the new thing I've heard... ๐
hi all, so i believe the issue is due to the removal of /data as a volume in the dockerfile that has caused the issue, which in turn is highlighting a user misconfiguration problem where execute = {/bin/bash,-c,mkdir -p /data/incomplete}
has been defined in the rtorrent.rc file, but the user has renamed/removed the /data volume mapping from the container configuration thus causing an issue when atempting to mkdir -p/ data/*
so the fix is simply to either comment out anything that references /data in your rtorrent.rc file or change the path to match the volume mapping (/downloads most probably).
Hi @binhex, thanks for looking into the problem. I've looked at my rtorrent.rc
and I've found no reference to /data
, still the latest
docker fails to start. The tracelog shown is:
2022-01-19 20:04:30,701 DEBG 'watchdog-script' stdout output:
[info] rTorrent listening interface IP 0.0.0.0 and VPN provider IP XXXXXXXXXX different, marking for reconfigure
2022-01-19 20:04:30,705 DEBG 'watchdog-script' stdout output:
[info] irssi not running
2022-01-19 20:04:30,709 DEBG 'watchdog-script' stdout output:
[info] rTorrent not running
2022-01-19 20:04:30,715 DEBG 'watchdog-script' stdout output:
[info] Attempting to start irssi...
2022-01-19 20:04:30,716 DEBG 'watchdog-script' stdout output:
Script started, output log file is '/home/nobody/typescript'.
2022-01-19 20:04:30,721 DEBG 'watchdog-script' stdout output:
no suitable socket path
2022-01-19 20:04:30,732 DEBG 'watchdog-script' stdout output:
Script done.
2022-01-19 20:04:30,732 DEBG 'watchdog-script' stdout output:
[info] irssi process started, updating trackers...
2022-01-19 20:04:30,734 DEBG 'watchdog-script' stderr output:
no suitable socket path
2022-01-19 20:04:30,735 DEBG 'watchdog-script' stdout output:
[info] irssi trackers updated
[info] Removing any rTorrent session lock files left over from the previous run...
2022-01-19 20:04:30,737 DEBG 'watchdog-script' stdout output:
[info] Attempting to start rTorrent...
2022-01-19 20:04:30,738 DEBG 'watchdog-script' stdout output:
Script started, output log file is '/home/nobody/typescript'.
2022-01-19 20:04:30,743 DEBG 'watchdog-script' stdout output:
no suitable socket path
2022-01-19 20:04:30,754 DEBG 'watchdog-script' stdout output:
Script done.
2022-01-19 20:04:41,816 DEBG 'watchdog-script' stdout output:
[warn] Wait for rTorrent process to start aborted, too many retries
2022-01-19 20:04:41,817 DEBG 'watchdog-script' stdout output:
[warn] Failed to start rTorrent, skipping initialisation of ruTorrent Plugins...
so the fix is simply to either comment out anything that references /data in your rtorrent.rc file or change the path to match the volume mapping (/downloads most probably).
Even though my volume mapping hadn't changed, changing /data in rtorrent.rc to match the volume mapping did fix it for me.
@lyz-code The default rtorrent.rc had /data/incomplete on about line 60 for me. Worth a double check?
Hey @KTheMan, I've double checked and no /data
appears on my
config/rtorrent/rtorrent.rc
, and the only execute
lines I was able to find
were:
execute = {/bin/bash,-c,/usr/bin/sleep 10s && /usr/bin/php /usr/share/webapps/rutorrent/php/initplugins.php admin &}
execute = {/bin/bash,-c,mkdir -p /downloads}
execute = {/bin/bash,-c,mkdir -p /config/rtorrent/session}
execute = {/bin/bash,-c,mkdir -p /config/rtorrent/logs}
execute = {/bin/bash,-c,mkdir -p /downloads}
try removing or commenting that line out, unless you are running as root then the user will not have permissions to create a root folder.
I've commented out one by one all the execute lines and I still get
2022-01-21 10:28:48,161 DEBG 'watchdog-script' stdout output:
[warn] Wait for rTorrent process to start aborted, too many retries
2022-01-21 10:28:48,162 DEBG 'watchdog-script' stdout output:
[warn] Failed to start rTorrent, skipping initialisation of ruTorrent Plugins...
I'll check the diff between my rtorrent.rc
and the default one
execute = {/bin/bash,-c,mkdir -p /downloads}try removing or commenting that line out, unless you are running as root then the user will not have permissions to create a root folder.
I just wanted to say that this fixed it for me, Ty
try removing or commenting that line out, unless you are running as root then the user will not have permissions to create a root folder.
Hi binhex,
Just stumbled upon the same issue. I have commented out "execute" lines as directories are on place, with proper permissions. No luck. Tried to delete the directories contents, recreating directories, letting script to do so.... nothing. Still ends with rtorrent not starting at all.
Any ideas despite running container as root instead of PUID/PGID of normal user?
Nah, setting PUID/PGID to 0 - no avail. Deleting perms.txt didn't help either....
Container definitely fails on tmux but I can't nail it down....
@tomeq82 Check where you have:
network.port_range.set = 12345
and change to an actual range, e.g.
network.port_range.set = 12345-12345
Single values in this attribute can also cause this issue.
@beauso neither single or single value range does anythning for me :( I have tried both just to check.
I've tried today running the docker with a bare configuration, basically I created a new directory, and copied the openvpn
file. Then I run the command suggested by the README.md
. The result is the same as with my old configuration.
I've dived into the scripts run by the docker and it looks like the problem is raised by the line:
/usr/bin/script /home/nobody/typescript --command "/usr/bin/tmux new-session -d -s rt -n rtorrent /usr/bin/rtorrent -b ${vpn_ip} -o ip=${external_ip}"
When I get an interactive session in the docker and try to run tmux
the error is raised:
[root@9bc0e1819616 tmp]# tmux new-session -s one
no suitable socket path
[root@9bc0e1819616 tmp]# tmux show-environment
no suitable socket path
So the problem is that tmux can't be started, if you try with python you get the same error
>>> import libtmux
>>> server = libtmux.Server()
>>> session = server.find_where({ "session_name": "foo" })
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3.9/site-packages/libtmux/common.py", line 316, in find_where
return self.where(attrs)[0]
File "/usr/lib/python3.9/site-packages/libtmux/common.py", line 347, in where
return list(filter(by, self.children))
File "/usr/lib/python3.9/site-packages/libtmux/server.py", line 185, in sessions
return self.list_sessions()
File "/usr/lib/python3.9/site-packages/libtmux/server.py", line 180, in list_sessions
return [Session(server=self, **s) for s in self._sessions]
File "/usr/lib/python3.9/site-packages/libtmux/server.py", line 170, in _sessions
return self._list_sessions()
File "/usr/lib/python3.9/site-packages/libtmux/server.py", line 150, in _list_sessions
raise exc.LibTmuxException(proc.stderr)
libtmux.exc.LibTmuxException: ['no suitable socket path']
I solved the problem by upgrading my docker
version from Docker version 19.03.13, build 4484c46d9d
to Docker version 20.10.12, build e91ed57
.
If it didn't solve for you, I suggest getting into the docker with docker exec -it docker_name bash
, get into /home/nobody
and open the rtorrent.sh
file add set -x
above the line you think is starting your rtorrent
and set +x
below to fetch the command that is launching your rtorrent instance, for example:
/usr/bin/tmux new-session -d -s rt -n rtorrent /usr/bin/rtorrent -b 12.5.232.12 -o ip=232.234.324.211
If you manually run /usr/bin/rtorrent -b 12.5.232.12 -o ip=232.234.324.211
you'll get more information on why rtorrent
is not starting
/usr/bin/tmux new-session -d -s rt -n rtorrent /usr/bin/rtorrent -b 12.5.232.12 -o ip=232.234.324.211
after a bit of drilling down, tmux seems to complain about terminal type and that it can't create socket. This can be overriden by using -2 and -S options passed to tmux. Tmux launches only when socket is created somewhere in the /home/nobody. It can't create it in /tmp for some reason, despite correct permissions.