Shonky
-
Posts
73 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by Shonky
-
-
2 hours ago, Hawkins12 said:
Thanks. I'll mess with it tomorrow. I am using the most updated docker so it's kind of confusing as it seemed an update (in 2020) fixed the issue. I'll check it out. Appreciate your time helping me
Well this docker template is not the same as the one I linked to. If you're having trouble with the other one then this thread is the wrong thread. The thread I linked I believe is the best and most up to date one. There have been a couple and also there have been significant changes to Crashplan over time e.g. the removal of the Home product.
-
59 minutes ago, Hawkins12 said:
It looks like I have issues similar to this but I'll be honest, I don't follow how to fix. From what I read, I need to clear the cache or "grant permissions" via chmod however, I am not necessarily a programming guru and not following how to make this all happen. What commands in the docker did you use to grant the permissions? Any way you could spell it out for a poor newbie like myself?
Thanks in advance. Appreciate you providing the above feedback!
Well firstly have you found the service.log.0 file and checked if it really is the same issue? Just because it's similar symptoms doesn't mean it's thae same problem.
If it's the same problem go to the Docker tab then click the Crashplan then ">_ Console". Then you should be able to just "chmod 777 /usr/local/crashplan" without quotes and restore should just start from memory.
Note that this is essentially a hack to make it work and possibly won't last if the container is restarted. The other container I use ended up getting a permanent fix.
-
14 minutes ago, Hawkins12 said:
So I believe my Crashplan is saving/backing up my data correctly. Seems to be working fine. I am at a point now where I need to recover some data and I am struggling big time. Here's what I am seeing:
I seem to be hard stuck here:
. Been hours with no movement. I logged on via a browser and Crash plan seems to be online. Any ideas what would cause this?
Take a look at this. Could be the same or a similar thing. Check Crashplan's log files. It creates quite a few.
-
Did some more digging and found the code in /usr/local/emhttp/webGui/nchan/update1
#!/usr/bin/php -q <?PHP /* Copyright 2005-2021, Lime Technology * Copyright 2012-2021, Bergware International. * * This program is free software; you can redistribute it and/or * modify it under the terms of the GNU General Public License version 2, * as published by the Free Software Foundation. * * The above copyright notice and this permission notice shall be included in * all copies or substantial portions of the Software. */ ?> <? $docroot = '/usr/local/emhttp'; $varroot = '/var/local/emhttp'; require_once "$docroot/webGui/include/publish.php"; while (true) { unset($memory,$sys,$rpms,$lsof); exec("grep -Po '^Mem(Total|Available):\s+\K\d+' /proc/meminfo",$memory); exec("df /boot /var/log /var/lib/docker|grep -Po '\d+%'",$sys); exec("sensors -uA 2>/dev/null|grep -Po 'fan\d_input: \K\d+'",$rpms); $info = max(round((1-$memory[1]/$memory[0])*100),0)."%\0".implode("\0",$sys); $rpms = count($rpms) ? implode(" RPM\0",$rpms).' RPM' : ''; $names = array_keys((array)parse_ini_file("$varroot/shares.ini")); exec("LANG='en_US.UTF8' lsof -Owl /mnt/disk[0-9]* 2>/dev/null|awk '/^shfs/ && \$0!~/\.AppleD(B|ouble)/ && \$5==\"REG\"'|awk -F/ '{print \$4}'",$lsof); $counts = array_count_values($lsof); $count = []; foreach ($names as $name) $count[] = $counts[$name] ?? 0; $count = implode("\0",$count); publish('update1', "$info\1$rpms\1$count"); sleep(5); } ?>My regex skills aren't the best so perhaps excluding the Apple files and just counting open files? But why does it even do this if there's no WebGui reading it?
-
Did you figure out what "feature" causes this? I see an lsof task running every 5-10 seconds as a process spawned by update1. I have made sure I closed all WebUI interfaces (closed browser completely, made sure no processes still running) but they persist. This is the command that keeps running
sh -c LANG='en_US.UTF8' lsof -Owl /mnt/disk[0-9]* 2>/dev/null|awk '/^shfs/ && $0!~/\.AppleD(B|ouble)/ && $5=="REG"'|awk -F/ '{print $4}'I don't have any Apple devices so whilst mine's not pegging the CPU at 100% for extended periods it's not necessary. Just runs 100% for maybe a second each time. Seems to be look for hidden files left by Macs and then prints them somewhere. Seems kind of pointless to me.
I see a sleep 2, so perhaps running every two seconds:
ps aux | grep ls[o]f -A5 -B5 root 17957 0.0 0.1 88744 29040 ? SL Jul03 24:23 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/wg_poller root 17960 0.0 0.1 88744 29000 ? SL Jul03 6:40 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/update_1 root 17963 0.0 0.1 88944 29716 ? SL Jul03 34:08 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/update_2 root 17966 0.1 0.1 88884 29408 ? SL Jul03 64:21 /usr/bin/php -q /usr/local/emhttp/webGui/nchan/update_3 root 18095 0.0 0.0 0 0 ? I 17:31 0:00 [kworker/2:0] root 18149 0.0 0.0 3936 2984 ? S 17:31 0:00 sh -c LANG='en_US.UTF8' lsof -Owl /mnt/disk[0-9]* 2>/dev/null|awk '/^shfs/ && $0!~/\.AppleD(B|ouble)/ && $5=="REG"'|awk -F/ '{print $4}' root 18150 13.0 0.0 5340 3292 ? S 17:31 0:00 lsof -Owl /mnt/disk1 /mnt/disk2 /mnt/disk3 /mnt/disk4 /mnt/disk5 root 18151 0.0 0.0 8376 2560 ? S 17:31 0:00 awk /^shfs/ && $0!~/\.AppleD(B|ouble)/ && $5=="REG" root 18152 0.0 0.0 8244 2496 ? S 17:31 0:00 awk -F/ {print $4} root 18155 0.0 0.0 2464 732 ? S 17:31 0:00 sleep 2 root 18156 0.0 0.0 4860 2908 pts/27 R+ 17:31 0:00 ps aux root 18157 0.0 0.0 3980 2228 pts/27 S+ 17:31 0:00 grep ls[o]f -A5 -B5 -
Right but the Change time is being updated (see original post) which appears to be what hashbackup is seeing.The dynamix file integrity plugin does not touch any file itself, it purely operates on extended attributes.
The file modification time is never altered by the plugin.
-
It did appear to be the file integrity plugin as updating one of the file date attributes resulting in hashbackup backing them up again. I've stopped the plugin for now.
-
I came across this solution separately, and then found this other thread just now. Seems like it could be a possible solution. My router (pfSense) was complaining about an IP having two different MAC addresses (the real hardware and a virtual interfaces called something like br0-shim but responds to ARP requests I presume resulting in packets to one IP coming in on two different network interfaces)
-
Turn cache off or if doing it on the machine itself, copy direct to /mnt/user0/...
-
Upgrade your crashplan docker. Crashplan tries to upgrade itself but that doesnt work in the unraid docker.Got an email that my machine has not synced in 5 days. When I try to log in to the web ui I get this message that never resolves. [emoji20]
Upgrading to a new version. You can sign in once the upgrade completes.
V8.7.1.32
Should be v8.8.1 from memory. Mine had to be upgraded twice recently although the 8.8.1 I don't think changed. Crashplan was downloading the same ~20MB file hundreds of times into its /tmp directory. -
4 hours ago, JorgeB said:
Well I'll be damned. I definitely tried this before with no luck.
iommu=pthas just worked on my Microserver Gen 8 running v6.9.2. Admittedly I have since upgraded from an E3-1265L to an E3-1265L v2 so not sure if that's made a difference.
Definitely not temperature related.
-
1 minute ago, Ranmacanada said:
Sorry for the necro, but even my Asus x79 Sabertooth which has marvell controllers (9128), loses the drives on it if I update to 6.9.2. It's frustrating as I am now stuck on 6.8.3 because of my motherboard of choice which was fine for the last 3? years. I can either buy a 16 port raid card in IT mode and hope my array doesn't break, or move to another socket where I can find a motherboard with 8 sata ports, where none are marvell, at great cost.
My current "solution" is/was to disable VT-d in the BIOS but that may be an issue if you're running VMs. Fortunately I use dockers for everything. VMs were a bit of a passing interest but dockers cover me for most things.
-
4 hours ago, ChatNoir said:
Then, don't vote ?
The currently available option suit me, so I don't have an opinion on this topic. I clicked on show results because I'm curious but I didn't had to do even that.
Would be much clearer with a simple "none of the above" and likely people would actually vote. It's in no way clear that clicking "view results" counts as abstention.
The current numbers show 135 out of 219 voted, i.e. "no vote" is second choice by a slim margin to ApplePay (89 vs 84)
-
-
Polls don't work in Tapatalk.I don't see any options?
Sent from my ONEPLUS A6003 using Tapatalk -
None of the above also. Google Pay if you're offering Apple Pay. As an Australian, the only option there is a buy now pay later service which requires another account etc and not something I'd wish to bother with.
-
On 10/7/2021 at 11:24 PM, 5252525111 said:
So far it's holding up well. I'm having new issues with NFS but don't think that's related to this at all. Long story short, no more panics.
That was one of the main fixes for me. I used a range outside my DHCP and reserve that for containers on unraid. If I recall correctly since I currently don't have access to my system, 100-223 is my LAN range, 50-99 I used for static and 224-255 (192.168.99.224/27) I reserve for containers on unraid.
Ok well at risk of bursting your bubble, that's how mine is setup anyway and I still had the problem. I have a /24 LAN. 1-99 are static which I just assign manually. Some are dockers some are things like routers/printers. DHCP is 100+. That's the way it's always been and kind of has to be really. If you have static IPs in the middle of a DHCP server's range you're going to have a bad time (tm) at some point. Putting dockers above or below the DHCP range makes no difference.
-
I have recently implemented hashbackup to replace CrashplanPRO but believe that hashbackup has just made the problem more visible. I had seen Crashplan backing up files more than once but never investigated why mainly because the size wasn't affecting me.
Anyway, I'm seeing files that have not been changed in years having their modified/changed times altered. e.g. I do a hashbackup, then run it again a few hours later and something's modified some files e.g. a particularly random one just now:
~# stat "/mnt/user/store/manuals and drivers/A8N-SLI Premium Drivers/15.23_nforce_winxp32_international_whql.exe" File: /mnt/user/store/manuals and drivers/A8N-SLI Premium Drivers/15.23_nforce_winxp32_international_whql.exe Size: 53370976 Blocks: 104248 IO Block: 4096 regular file Device: 2fh/47d Inode: 648799821402998927 Links: 1 Access: (0666/-rw-rw-rw-) Uid: ( 99/ nobody) Gid: ( 100/ users) Access: 2017-04-04 06:21:53.417766486 +1000 Modify: 2008-10-05 09:03:49.000000000 +1000 Change: 2021-10-10 17:53:26.528479637 +1000 Birth: -There's no way I touched it just now. That's about 20 minutes ago. Whole chunks (not every file in a folder though) randomly have their change time altered and the backup program picks it up.
Could the file integrity plugin do anything like this? I've set it up recently but pretty sure the repeated backups were happening long before that.
If a file is not being actually changed how else could this be happening?
All disk file systems are xfs. Not entirely sure what else would be relevant. Nothing in syslog at the change time.
Checking the direct /mnt/diskx/... file shows the same info but with the birth field entered (seems just before the access time)
-
How's your fix holding up? I get this sporadically. certainly not every 3-4 days. 1-3 months perhaps.
I do not have the mentioned switch.
I have a static IP but don't use VLANs within unRAID nor on my network.
I don't really follow the fix though. I do have a br0 setup and some of my dockers connect that way to get a specific LAN IP of their own.
My docker br0 is
IPv4 custom network on interface br0: Subnet: 192.168.99.0/24 Gateway: 192.168.99.1 DHCP pool: not setThat's my LAN too. Is the suggested fix to have docker restricted to a sub range of the full /24 and then for each docker that needs it, only use IPs within that range?
My DHCP range for my LAN is 192.168.99.100-192.168.99.255. Below .100 I reserve for static assigned IPs and that's where my dockers that have their own IP run from.
@corgan if you're still getting the problem does that not mean you didn't really fix it though?
-
Jinxed it. Caught it happening again tonight so none of the above things fixed anything.
I only touched two dockers to bring it back around. Gitea and Photoprism. The latter did seem to be scanning. I'm only playing with it so killed it pretty quickly. Previously it did seem like CrashPlanPRO was a cause, but not always.
Seems like dockers that generate a lot of IO (Plex scanning, Photoprism scanning, CrashPlanPRO indexing/scanning etc ) tend to trigger it off. Stop one or two of them or even others sometimes and it comes back around. Almost like it's disk thrashing on a mechanical disk.
-
Now that you say that, I do also run plex and had some issues with the scheduled scan failing/timing out/something on a couple of random files. I think they were video files and I ended up removing them. If it was those files specifically, it wasn't 100% repeatable because it would have happened every night.
I don't remember if if I was looking at the Plex issue because of the loop2 reads or independently.
Sorry that's not really helpful. If you turn on debug in plex it's pretty easy to find the specific files causing the problem. And you can trigger the full scan manually. The scan runs but is killed after an hour from memory if it's taking too long.
-
On 7/24/2021 at 7:36 PM, DingHo said:
Curious if anyone has made any progress on this issue. I'm still encountering it on a fairly regular basis, even after updating to 6.9.2.
I've not made any definite change that fixed it but I haven't had a re-occurrence for a while now. Running 6.9.2 but I'm pretty certain that I was still getting it with 6.9.2 also. Not that 6.9.2 had changed expected to fix this.
I think the most significant thing I did change was I moved my cache drive SSD SATA connection from the HP Microserver ( Gen 8 ) motherboard and used the PCIe SATA card I had installed. The main reason I did was that it was limited to SATA II speeds. I can't say 100% but at least since then I've not had an issue.
The other thing I had done was that I changed the SSD itself which meant recreating the whole docker.img filesystem. No improvement from that change.
-
buff/cache is RAM allocated to buffers by the OS. It is not allocated RAM and is available if something tries to allocate RAM. I doubt there is any significant difference in the buff/cache handling in unRAID. It's still pretty close to a regular Linux kernel.
If unRAID was filling its ram disk (and you didn't have enough), you'll start seeing OOM errors. My system shows / as 4.8GB total with about 900MB used.
I don't have a netdata docker and haven't tried it either.
-
2 minutes ago, DingHo said:
Curious how to figure out what is causing the loop2 read or if there is a workaround to restart a docker if it's marked as unhealthy?
I don't think it's your unhealthy container, but have nothing to back that.
If I catch mine in the early stages, things like docker ps, docker stop/start etc work ok. Usually by the time I catch it though, it's because something like Plex or Pi-Hole dockers are being blocked from doing anything. It's too late then and docker commands just get blocked until it comes back. So I can't properly shut down a docker and have to kill some processes that docker is running.
I've toyed with just as a work around, something monitoring system load. Any time it gets over say 20 or 30 even on 1 minute and restart a docker perhaps after capturing some logs. Whilst CrashPlanPRO seems to be involved I have had occasions where restarting other very lightweight dockers was enough.
Unfortunately mine does it even less than it used to now.
[Support] manuel-rw Docker Support thread
in Docker Containers
Posted
Live demo link in unRAID apps ( https://dash.mauz.io/ ) goes to possibly dangerous websites vie multiple redirects. Should be https://dash.mauz.dev/