Jeffarese

Members
  • Posts

    47
  • Joined

  • Last visited

Everything posted by Jeffarese

  1. I'm still having this problem. I updated again and the problem persists: Ports don't seem to be forwarded or configured in rTorrent correctly: 2021-03-08 11:34:04,443 DEBG 'start-script' stdout output: [info] Successfully assigned and bound incoming port '22390' 2021-03-08 11:49:04,604 DEBG 'start-script' stdout output: [info] Successfully assigned and bound incoming port '22390' 2021-03-08 11:53:23,017 DEBG 'watchdog-script' stdout output: [info] rtorrent incoming port closed, marking for reconfigure 2021-03-08 12:04:04,769 DEBG 'start-script' stdout output: [info] Successfully assigned and bound incoming port '22390' 2021-03-08 12:19:04,932 DEBG 'start-script' stdout output: [info] Successfully assigned and bound incoming port '22390' 2021-03-08 12:23:30,398 DEBG 'watchdog-script' stdout output: [info] rtorrent incoming port closed, marking for reconfigure 2021-03-08 12:34:05,103 DEBG 'start-script' stdout output: [info] Successfully assigned and bound incoming port '22390' 2021-03-08 12:49:05,273 DEBG 'start-script' stdout output: [info] Successfully assigned and bound incoming port '22390' 2021-03-08 12:53:37,361 DEBG 'watchdog-script' stdout output: [info] rtorrent incoming port closed, marking for reconfigure 2021-03-08 13:04:05,445 DEBG 'start-script' stdout output: [info] Successfully assigned and bound incoming port '22390' 2021-03-08 13:19:05,617 DEBG 'start-script' stdout output: [info] Successfully assigned and bound incoming port '22390' Any ideas?
  2. I just updated and port forwarding seems to have some problems. It was working perfectly before the update (in multiple docker containers using different PIA endpoints). Everything seems to be OK in the logs. It retrieves the port from the PIA endpoint: 2021-03-03 09:25:45,174 DEBG 'watchdog-script' stdout output: [info] rTorrent incoming port 49160 and VPN incoming port 36936 different, marking for reconfigure Then, after: 2021-03-03 09:26:04,357 DEBG 'watchdog-script' stdout output: [info] ruTorrent plugins initialised The logs start outputing this: 2021-03-03 09:40:44,618 DEBG 'start-script' stdout output: [info] Successfully assigned and bound incoming port '36936' 2021-03-03 09:55:44,787 DEBG 'start-script' stdout output: [info] Successfully assigned and bound incoming port '36936' 2021-03-03 09:56:24,526 DEBG 'watchdog-script' stdout output: [info] rtorrent incoming port closed, marking for reconfigure 2021-03-03 10:10:44,958 DEBG 'start-script' stdout output: [info] Successfully assigned and bound incoming port '36936' However, the port shows as "Closed" in the UI (red exclamation mark) even after hours. Also, my clients were pretty consistent in the upload per day (around 500GB per day, sometimes some container would upload 1TB) and the last day I only upload between 5 - 30GB (and some of them less than 1GB), so clearly there's something not there yet. I'm using Wireguard with `privileged=true`. All was working before this update. I think the last time I updated was 1-2 months ago, I'm not sure, but I was already using wireguard and everything was working fine.
  3. Is there any recent change regarding auto opening ports with PIA VPN? Since I started using PIA the incoming port used on rTorrent was automatically changed after a while on rTorrent to match the port forwarded provided by PIA api. Since a few days ago I've seen that the red mark is present on all torrent clients and I don't seem to get lots of connections, so it seems that the ports are not being set indeed. Just to clarify: The port used in ruTorrent does not seem to be updated with the forwarded port reported by the rtorrent log when retrieving it from PIA API. Log trailing with:
  4. It's pretty common to isolate cpus to improve performance in VMs, I don't think the user base is that small
  5. So is this problem going to be ignored? It's not listed in "known issues" or something like that. I tested the same hardware with Proxmox and I NEVER got random activity on cpus I had isolated to certain vms.
  6. Ah yes! I already had this setup in the past, I have that sorted out Thanks!
  7. lol sorry, my mind was in another place. Yeah, I meant of your image Each one of the containers are using different PIA servers (endpoints) so each one of them receive a different IP & request a different port, even though all the containers are running in the same server. How would I have host port conflicts? I don't need to forward host ports since the ports are open by the VPN, right?
  8. Correct! it sorted it out after a while and now it shows green! Unrelated question about PIA: Is there any problem if I have multiple instances of your script using different server configs (one container has sweden.ovpn, another one has france.ovpn) so each one of the containers requests a different port? I run multiple containers of your image to organize better my files. It seems to be working OK and all of them show the green icon now and seem to be seeding ok.
  9. Is the auto port assign of PIA working correctly? I see the messages in the logs about retrieving and assigning the port from PIA: [info] Successfully assigned incoming port 55730 [info] Checking we can resolve name 'www.google.com' to address... [info] DNS operational, we can resolve name 'www.google.com' to address [REDACTED] [info] Attempting to get external IP using Name Server 'ns1.google.com'... [info] Successfully retrieved external IP address [REDACTED] [info] rTorrent listening interface IP 0.0.0.0 and VPN provider IP [REDACTED]different, marking for reconfigure [info] rTorrent not running [info] rTorrent incoming port 49160 and VPN incoming port 55730 different, marking for reconfigure However, the port reported in the interface bottom bar is a different one (the one I had previosuly configured) and it shows the red icon saying the port is not open.
  10. I had already seen that post, but there's still no info about how to do what I need
  11. Is there any way to router only specific docker containers through Wireguard while keeping the rest of the traffic normal?
  12. In my case I would have noticed instantly if it worked. I think my server might have more activity than yours and it's super easy to spot if the isolated cores are working. However, I'm not able to test this beta, I need the stability
  13. Yeah, it didn't work at all for me either as I stated in my previous post. Let's see if the 6.9.0 beta with 5.x kernel solves it 🤞
  14. You're a brave man I'm eager to hear your experience on it, hope it fixes it!
  15. I totally understand that and it makes sense, but I don't understand how such an obvious bug has not been reported elsewhere (that I found).
  16. Is this bug going to be fixed? This is pretty much a deal breaker to use Unraid as main server with a Windows gaming VM.
  17. That kind of defeats the purpose... I can't be rebooting my server. I would expect isolcpus to work as expected. Also, my cpu usage kicks in just after reboot
  18. I tested it with: isolcpus=5-11,17-23 nohz_full=5-11,17-23 rcu_nocs=5-11,17-23 But still getting the same activity on CPU-9. Any idea?
  19. I haven't tried, but it seems it would fix my issues since they solved it for Chess with my same CPU. What do those two settings do? Any downside?
  20. I created a post about this bug. I can reproduce too with R9 3900x.
  21. Hey. I isolated the last 14 cores of my 3900x (from 5 to 23). When the VM that uses them is powered off, I see light but constant usage on 2 core s(cores 6 & 9). I've double checked that nothing but that VM is pinned to that CPU core. All dockers are pinned to other cores (non-isolated ones). Any idea where can I start to look to debug this? Thanks.
  22. In my setup, containers using custom networks still go through the vpn 😕
  23. Any aproximation to when is this going to be possible aprox? This would be the killer feature, since routing ALL the traffic seems like a little bit too much. Thanks!
  24. Hey, one question. Given that I'm running in a more or less powerfull machine (R9 3900x, 64GB RAM), with plenty of resources, is there any settings/tweaks that can be done to increase the performance further? I'm currently sitting at 1700 torrents and sometimes I get timeouts, it seems that nginx can't handle it that well (even if rTorrent itself is a beast)