Cull2ArcaHeresy

I upgraded from 6.8.3 to 6.9.1 and while at it finally upgrade my flash drive from a OLD 2gig that was from sometime before 2010. VMs and dockers seem to be working fine now and main array and cache normal. I created a new pool "archive_one" with 6 * 4tb sas drives. Now trying to rebalance it to raid6 instead of default raid 1. I started it last night and it ran for over 8 hours displaying this Data, RAID1: total=1.00GiB, used=0.00B System, RAID1: total=32.00MiB, used=16.00KiB Metadata, RAID1: total=2.00GiB, used=128.00KiB GlobalReserve, single: total=3.25MiB, used=16.00KiB btrfs balance status: Balance on '/mnt/archive_one' is running 2 out of about 3 chunks balanced (3 considered), 33% left Since then i tried again a couple times while also watching the log (below). Sometimes it would go right to the above display and then nothing, sometimes UI showed sometimes like above but with 1 of 3 chunks 2 considered 66% left. Both UI displays had the same log output of a quick blurb and then nothing else printed out and main page there are no reads/writes on the drives which confirms that nothing is happening. Apr 6 19:40:13 Raza ool www[15440]: /usr/local/emhttp/plugins/dynamix/scripts/btrfs_balance 'start' '/mnt/archive_one' '' Apr 6 19:40:13 Raza kernel: BTRFS info (device sdak1): balance: start -d -m -s Apr 6 19:40:13 Raza kernel: BTRFS info (device sdak1): relocating block group 9861857280 flags metadata|raid1 Apr 6 19:40:13 Raza kernel: BTRFS info (device sdak1): found 3 extents, stage: move data extents Apr 6 19:40:13 Raza kernel: BTRFS info (device sdak1): relocating block group 9828302848 flags system|raid1 Apr 6 19:40:14 Raza kernel: BTRFS info (device sdak1): found 1 extents, stage: move data extents Apr 6 19:40:14 Raza kernel: BTRFS info (device sdak1): relocating block group 8754561024 flags data|raid1 Apr 6 19:40:14 Raza kernel: BTRFS info (device sdak1): balance: ended with status: 0

that seems to have been the issue (or at least fixed it), thanks

I thought it was part of the core functionality. [25.03.2021 19:02:07] WebUI started. [25.03.2021 19:02:30] _cloudflare: Plugin will not work. rTorrent user can't access external program (python). [25.03.2021 19:02:30] _task: Plugin will not work. rTorrent user can't access external program (php). [25.03.2021 19:02:30] autotools: Plugin will not work. rTorrent user can't access external program (php). [25.03.2021 19:02:30] create: Plugin will not work. rTorrent user can't access external program (php). [25.03.2021 19:02:30] datadir: Plugin will not work. rTorrent user can't access external program (php). [25.03.2021 19:02:30] history: Plugin will not work. rTorrent user can't access external program (php). [25.03.2021 19:02:30] loginmgr: Some functionality will be unavailable. rTorrent user can't access external program (php). [25.03.2021 19:02:30] ratio: Some functionality will be unavailable. rTorrent user can't access external program (php). [25.03.2021 19:02:30] retrackers: Plugin will not work. rTorrent user can't access external program (php). [25.03.2021 19:02:30] rss: Plugin will not work. rTorrent user can't access external program (php). [25.03.2021 19:02:30] rutracker_check: Plugin will not work. rTorrent user can't access external program (php). [25.03.2021 19:02:30] scheduler: Plugin will not work. rTorrent user can't access external program (php). [25.03.2021 19:02:30] trafic: Plugin will not work. rTorrent user can't access external program (php). [25.03.2021 19:02:30] unpack: Plugin will not work. rTorrent user can't access external program (php). [25.03.2021 19:02:30] xmpp: Plugin will not work. rTorrent user can't access external program (php). [25.03.2021 19:02:30] _task: Plugin will not work. rTorrent user can't access external program (pgrep). [25.03.2021 19:02:30] mediainfo: Plugin will not work. rTorrent user can't access external program (mediainfo). [25.03.2021 19:02:30] rss: Some functionality will be unavailable. rTorrent user can't access external program (curl). [25.03.2021 19:02:30] screenshots: Plugin will not work. rTorrent user can't access external program (ffmpeg). [25.03.2021 19:02:30] spectrogram: Plugin will not work. rTorrent user can't access external program (sox). Is this related to it?

Where did "Save to..." go?

so i guess the support from my seedbox a while back was not 100% accurate and that it was more of an issue with whatever hardware they use, missing optimizations, and/or maybe even if they use btrfs. Will dedicate a couple drives for p2p share to be on and disable cache on that share to remove possible problems. Would also love to know what tricks Cat_Seeder recommends

I was having issues with my seedbox over a year ago (closer to 2 probably), and the tldr of the quoted support response from provider is too many active is a problem (currently tend to have around 75 active with no prob on there). Issue on seedbox was move when completed not always working, torrents going into pausing state, and rtorrent crashing. Over the past couple months i remembered the seedbox issue and applied that to binhexrtorrentvpn (was having issues similar to cliff), and container has been working pretty well since. Getting uploads and downloads, but run into issues if there are more than 100 to 150 non-stopped torrents, or if active count is over like 30. I'm running dual e5-2695v2 (2*12 cores, hyperthreaded, 2.4ghz), 128gb ram, with nothing pinned, pia vpn. My plan has been to make a manager to coordinate between multiple containers like a "rtorrent container swarm" thing (multiple containers networked thru 1 running vpn & manager)...but have not gotten around to it yet as it feels like an overengineered solution. Maybe others can weigh in as to how many non-stopped and active torrents they have...or other knowledge of what our problems might be.

anyone else having this issue with the German server (or others)? sh-5.0# ./testvpn.sh 66.115.142.201 CA Canada 66.115.142.201 sh-5.0# sh-5.0# ./testvpn.sh 212.102.49.91 ES Spain 212.102.49.91 sh-5.0# sh-5.0# ./testvpn.sh 195.246.120.122 SE Sweden 195.246.120.122 sh-5.0# sh-5.0# ./testvpn.sh 154.13.1.102 DE United States 154.13.1.102 sh-5.0# for reference sh-5.0# cat testvpn.sh curl ifconfig.io && curl ifconfig.io/country_code && curl ifconfig.co/country && curl ifconfig.co

not having all country codes memorized, was trying to alter my standard get ip&location command to print country name. Currently *.co gets the ip right but my location not the vpn, whereas *.io gets both right. Is there a different site to use to get country name that yall know of that is better? Error on *.co end or some leak in container? sh-5.0# curl ifconfig.co/country United States sh-5.0# curl ifconfig.co 154.13.1.102 sh-5.0# curl ifconfig.io && curl ifconfig.io/country_code 154.13.1.102 DE sh-5.0# ----------------- has has since switched vpn endpoints, new server seems to not be doing that sh-5.0# curl ifconfig.io && curl ifconfig.io/country_code 212.102.37.21 CH sh-5.0# curl ifconfig.co && curl ifconfig.co/country 212.102.37.21 Switzerland sh-5.0#

what else other than user/pass needs to be removed? ive been meaning to make a sanitizer script for a while now.

When i move a completed torrent from my seedbox to local (move files then add .torrent), rtorrent checks before seeding. Great to make sure nothing got corrupted during transfer and all...but it takes forever. Earlier it was checking a 3gb one when i looked (was at like 20 or 40%), now 6 hours later it is at 75% on that same torrent. After it finishes check i move it to correct done folder, it adds it back to queue to be checked, but this check is faster and seems to be on par with force recheck (maybe slower but nowhere near hours per gig). Is this a container thing like i need to give it more resources (top below), or some rtorrent setting...which it seems most the checking hash options have been deprecated. From what have found, there has never been an option for it to check multiple at once, but the biggest (deprecated) flag was hash_check_interval (others too, but smaller impacts). top - 02:40:28 up 33 days, 4:33, 0 users, load average: 15.73, 16.31, 16.44 Tasks: 76 total, 1 running, 75 sleeping, 0 stopped, 0 zombie %Cpu(s): 26.3 us, 1.8 sy, 0.0 ni, 71.4 id, 0.5 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 128952.8 total, 4412.8 free, 46173.8 used, 78366.2 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 79801.2 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 37385 nobody 20 0 3472912 1.1g 140908 S 0.3 0.9 113:22.49 rtorrent main 1 root 20 0 2340 284 204 S 0.0 0.0 0:59.15 tini 6 root 20 0 30816 17412 1612 S 0.0 0.0 9:41.05 supervisord 368 nobody 20 0 7436 2372 1740 S 0.0 0.0 0:55.70 logrotate.sh 370 nobody 20 0 7436 672 4 S 0.0 0.0 0:00.35 rutorrent.sh 371 root 20 0 7728 2720 1780 S 0.0 0.0 0:00.47 start.sh 372 nobody 20 0 7664 2772 1968 S 0.0 0.0 6:35.67 watchdog.sh 1039 nobody 20 0 80496 16500 5948 S 0.0 0.0 0:31.58 php-fpm 1040 nobody 20 0 79060 17432 8852 S 0.0 0.0 0:31.74 php-fpm 1041 nobody 20 0 77012 15364 8780 S 0.0 0.0 0:32.12 php-fpm 4214 root 20 0 7728 2120 1280 S 0.0 0.0 0:37.05 start.sh 5212 nobody 20 0 76068 7852 1556 S 0.0 0.0 1:37.87 php-fpm 5216 nobody 20 0 10348 1592 260 S 0.0 0.0 0:00.05 nginx 5217 nobody 20 0 11156 3400 1292 S 0.0 0.0 5:33.05 nginx ...bunch more nginx update: 3 hours later that torrent finished checking ("posted 3 hours ago"...so might be closer to 4). Checking 100% took like 40 minutes to change to seeding.

see

what next-gen servers are yall having luck with?

yea, just best wrong premises/logical conclusion could figure out (edited post should be more clear)

no luck finding where saw, best guess is misreading/misremembering [the following wrong premises/logical conclusion] 1) nextgen uses (only) wireguard, 2) wireguard prone to hacks (instead of requiring hacks to work), thus 3) nextgen prone to hacks

wasnt there a major vulnerability in something that the nextgen were implementing?

so Next-Gen are good and safe now?

but sadly "Connect to OpenVPN: We are still working on this script.", which makes me assume the back end aint ready yet either

guessing it has to do with max speed tweaks, which i will look into after getting constant consistent connections and activity EDIT: now that i'm finally creating a combined file, the default ones i have start with the following, so maybe its always been udp by default (thought defaults were tcp) client dev tun proto udp remote LOCATION.privateinternetaccess.com 1198

was that built off the default pia files? looking at mine, the gcm and auth are different (quickly compared so probably more differences).

Changing of pia vpn files to get to different endpoints while whatever is going on, what is the best way to measure "quality" for each? There are different tools to measure container stats but also connecting directly to rtorrent could give data. I have enough seeding torrents that that should be constantly at limit (when connection is good), fewer downloads but that would be easy to change. Trying to figure out the best way to keep track of upload and download for each vpn file. Being early on this would be raw totals for each day and later being more of a line graph probably. Raw scaled by how many hours that vpn file was used that day (other options too like hourly average, but that is a later thing). So say your connection is bad right now, you stop the container and run this script that would give you a list of vpn files and their daily quality history (from your runs) and ask you to select which one you want to copy in for the container to use. Then you start the container again and it will connect using the chosen file. While container is running this script is logging the network usage.

compared to a "graceful stop", would this cause any issues like rtorrent corrupting a file or leakage (or other)? Also not a hard threshold, but a count that resets each hour might be much better so a series of reconnects over time wouldn't cause a restart.

i had assumed that it more or less did something like 1-[ established vpn conn ], 2-[ locked down connections (including dns) ], 3-[ started rtorrent/rutorrent ], 4-[ monitored connection and if need be kill *torrent and go back to #1 ] knowing the dns issue (and yea docker env variables are a pain to change), it is a much more closed locked down system Can a container restart itself? Rough idea that is it counts number of fails (connection or pia forward), and at some arbitrary threshold it restarts (or kill itself with the restart flag in docker command)? Could always have it create a file when that threshold is met and a script running on unraid sees the file, deletes it and restarts the container...but idk if it is a big enough problem to do that. just to be clear, all pia with same creds or all other with same creds. Im not against mixing them, but being the same for simplicity.

this method requires restarting the container, any reason to not have the line where an openvpn connection is established to pick a random *.ovpn file? Been meaning to try it, just havent yet. This way whenever it resets the connection it will try a new one (or pick the same again as random).

Only officially supported one left? I deleted my post since you had a factually correct answer, just didnt pop up until after i had made my comment.

does your vpn have port forwarding? i use pia and sometimes pia and rtorrent will pick the same port and it will show open, but most the time it shows closed. If i found the list of pia port ranges again (but was old list so prob bad) i would set my range to match, but be it pia or something else, port open or closed i get the same connection where it will be full speed for a while now and then but most the time it is <1m up/down. i did not buy pia for this, already had it.