Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation

6 Neutral

About plantsandbinary

  • Rank
    Advanced Member


  • Personal Text
    I fucking hate troubleshooting.

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Alright thanks mate, I really appreciate the support. This can be closed then. Looks to be all working now.
  2. I was just about to say. Turning off just ruTorrent makes the mover run immediately. Files copying over at 350MB/s to parity and one of my disks... so it looks like that's working now. The other settings regarding the cache are okay?
  3. That's probably it. So the mover won't move the files if they are seeding? In that case I'll shut down rutorrent before engaging the mover and see if that works. Does everything else in the screenshots above look okay though? appdata cache set to - only and /tank set to cache - yes? What about the rest? I can handle shutting down ruTorrent if the mover fills up and I need to run it manually after having downloaded several large files, but if something else breaks like last time I'm going to spit the dummy.
  4. I ran it 5 more times and it stopped immediately every time. So this one absolutely has to have some explanation in it. I don't know where to look myself. tower-diagnostics-20201121-1258.zip
  5. I hope this has the right information. It should be at the bottom of the log. I rebooted, ran the mover. It ran for a while, moved about 125GB and then stopped halfway. I'm assuming because I didn't turn off Docker and something on one of my docker containers spun up and made it stop. I tried running it again (this time with logging enabled) and it stopped immediately again. I hope this diag tells why. tower-diagnostics-20201121-1255.zip
  6. Mover still hasn't moved anything manually or automatically. It's strangling my server because my cache is totally full. Can someone please tell me why it's not working? EDIT: Seems to be something to do with Docker I think. Restarting and immediately running the mover looks to be okay.
  7. Well I had a stab at this again and fixing my configuration. I literally am starting to question entirely how my device is meant to be setup to avoid this problem happening in the future. I rebuilt my torrents and setup rutorrent again after importing everything. It seems to be okay now but all of this has me wondering if it's set up the right way. The mover is still not moving files to the array when I am trying to run it. Here's the setup Here's the setup pics and diagnostics (attachments) SPECS: Model: HP MicroServer Gen8 M/B: Version - s/n: ?????????? BIOS: HP Version J06. Dated: 04/04/2019 (latest) CPU: Intel® Xeon® CPU E31265L @ 2.40GHz HVM: Enabled IOMMU: Enabled Cache: 128 KiB, 1024 KiB, 8192 KiB Memory: 16 GiB DDR3 Single-bit ECC (max. installable capacity 16 GiB) Network: bond0: fault-tolerance (active-backup), mtu 1500 eth0: 1000 Mbps, full duplex, mtu 1500 eth1: 1000 Mbps, full duplex, mtu 1500 Kernel: Linux 4.19.107-Unraid x86_64 OpenSSL: 1.1.1d Uptime: 2 days, 18:07:08 In short-hand. As I understand for best performance I have it set up like this: appdata for docker containers is on the cache drive always. So appdata is set to cache -> only tank (which is where all my files go spread across the array) is set to cache -> yes so new files etc. are put there. This is really just for quick downloading via rutorrent every other share is set to cache -> no If that's wrong, or I am not understanding this right or I've done something wrong, or there is a better way to do this. Someone please tell me so I don't blow up my device in the future. A short explanation of how/what to do would be greatly appreciated. With this setup. The mover refuses to do anything when trying to invoke it manually. It will just move when it feels like it from what I can see. There's no other way for me to describe when/how it actually makes the decision to move files from the cache to the array. Thanks for the help and sorry for losing my head before but it was one hell of a crippling loss... tower-diagnostics-20201120-1754.zip
  8. Well I'm not sure what just happened but I did what I wrote above and the mover finished, with only 30GB left on the cache. I turned Docker back on, started ruTorrent and every single one of my torrents immediately started redownloading and overwrote my completely written files... I had already downloaded all of those files over a 9-12 month period. But it's now downloading over 3.9TB of data all over again... this is a total fucking catastrophe... and now I have to go through each one and figure out what I want to re-download... I cannot even stress what a catastrophe this is. I lost over 1TB of music... half of those torrents don't even exist any more and I was the only seeder. Now that I don't have the full files they aren't downloading. I have no idea where I will get some of those albums again. They took months to find. Maybe the biggest irony. My fucking cache drive is 95% full again in an instant thanks to ruTorrent allocating space for all the files. Why the hell couldn't the mover just move the damn files off the cache before trying to move appdata back on. Honestly, how tf is that not a simple thing to do. I would never have had to change anything if it had just skipped appdata for a moment and moved the stupid movies onto the fucking array first! I am so pissed. I have to turn this PoS off and think about when I feel like I have the patience to sort this mess out. But I bet I'm going to wind up with a dozen warnings on my private trackers complaining that I've done partial downloads and am not seeding back.
  9. I've set appdata to "only". I want the appdata on the cache drive always, I don't want it on my RAID array. So I guess that's the correct setting? Thanks I did this. Though I didn't have domains on the cache drive. I just checked. I had only some files from the array (those new ones downloaded via rutorrent, waiting to be moved to the array) and appdata. I turned off Docker via the settings tab and ran the mover with app data set to "only" and /tank set to "yes". I don't really understand the difference between "yes" and "prefer" though. I have the mover run every hour (or at least I try to get it to) because I have a gigabit line with 100MB/s download and 50MB/s upload. I cycle through a lot of bluray rips up to 80GB in size. So if I am downloading multiple files at once I need the mover to run asap to move files from the cache to the array so my docker containers don't crash until the mover runs and clears space on my cache drive. Setting it to every day wasn't enough because it will fill up instantly and then not move for the rest of the day. As far as I understood the scheduler, the hourly run means only that it will "check" if files need to be moved, but still decide not to if the cache isn't very full. Whereas if I set it to run every 12 hours, it'll check and decide but if it's not full at that time, it won't run. Meaning any time between the next 12/24 hours nothing will happen if the drive fills up quickly. As I understood, there isn't any kind of downside running the mover that often. It looks like it's set to: 2000000. Would be nice to know if that was bytes/kilobytes etc. I'm guessing that's kilobytes. Seeing as my cache drive won't fill past 1.6GB and 2000000 kilobytes is about 2GB in base 10, I guess that's accurate. I'll add an extra 0 just in case and hopefully it will stop my docker containers crashing when the cache gets really full.
  10. It seems to be working now, but I had to restart the server and then press "move" for it to actually do anything. No idea why. I had even turned off Docker before restarting so there really shouldn't have been any activity whatsoever. Either way, it seems to be okay now but I do wish it would just move things off the cache first regardless of whether or not there are tasks to put things on the cache too.
  11. Thanks for the continued assist. Can I leave the appdata share on cache=only, or do I need to move it back later? I thought I had set it to cache only just to make containers perform better anyway. Setting it to no or only doesn't seem to make the mover do anything still. It just stops immediately. /tank is now the only share that is using the cache btw, which is set to "yes". It would be nice if in an update the mover skipped moving items to the cache if it was full and instead focused on moving items off, instead of outright stopping like it is in this case.
  12. I'm trying to move the files from the cache drive to /tank which is comprised of those other 3 drives you see above. It's a share called /tank which the mover should be moving filed downloaded to the cache off to the main drives every hour. For some reason though it only does this when it feels like it (at least that's how it seems) despite my set hourly schedule. I've attached some files. As you can see from the last screenshot, the cache drive has filled up. All of my docker images have now crashed and when trying to invoke the mover manually, it says it's running but a refresh shows it's stopped immediately and is doing nothing. tower-diagnostics-20201117-1755.zip
  13. Just what it says. Cache is pretty full. It seems to run fine after a few hours (can't say it runs on 1 hour schedule like I set it up because it seems to take longer than 1 hour to actually do anything). Maybe I have set it up wrong? Trying to run it manually now. The button presses, says mover is running. After refreshing the page. It shows it's not running.
  14. Can we please get an option to auto-update docker apps after a few days (like say 7) like we do for plugins please? Was surprised to not find that option.
  15. My entire rTorrent has stopped working for some reason whilst downloading a large 1.6TB torrent. My first drive filled up and most of my docker images crash when that happens. So I turned off all containers and moved files to the next drive. Figured there would be no problems so I restarted the container. Now I get this in the log. 2020-10-30 06:23:05,894 DEBG 'rutorrent-script' stderr output: [NOTICE] [pool www] 'user' directive is ignored when FPM is not running as root [NOTICE] [pool www] 'group' directive is ignored when FPM is not running as root 2020-10-30 06:23:05,903 DEBG 'rutorrent-script' stdout output: [info] starting nginx... 2020-10-30 06:23:16,542 DEBG 'watchdog-script' stdout output: [warn] Wait for rTorrent process to start aborted, too many retries 2020-10-30 06:23:16,543 DEBG 'watchdog-script' stdout output: [warn] Failed to start rTorrent, skipping initialisation of ruTorrent Plugins... 2020-10-30 06:33:23,916 DEBG 'watchdog-script' stdout output: [info] rTorrent listening interface IP and VPN provider IP different, marking for reconfigure 2020-10-30 06:33:24,772 DEBG 'watchdog-script' stdout output: 0 2020-10-30 06:33:25,099 DEBG 'watchdog-script' stderr output: INFO: Bad data packets written to '/tmp/xmlrpc2scgi-99.xml' 2020-10-30 06:33:25,100 DEBG 'watchdog-script' stdout output: ERROR While calling network.local_address.set('', '\n216.239.34.10\n216.239.36.10\n216.239.38.10'): <Fault -503: 'Could not set local address: Name or service not known.'> I've even rebooted my server. It was running for 415 days without issues and I must have updated this container maybe 3 or 4 times during that time because I like to update only after a good period of time.