jeffreywhunter

I'm seeing a recurring log entry (every 4 minutes) from a Docker (GS-Server). Such a useful docker, love how well it works except for this log issue. I've spoken with the Docker creator who is unable to recreate the error and Goodsync tech support. Goodsync says the problem is a "known issue" with Linux and requires some kind of update to fix (they said google it, but I've not been able to find anything specific and recent). So I'm posting this in hopes that someone is aware of a fix. While everything works fine, my log is filling up with useless data! I've attached a copy just FYI... Thanks in advance! hunternas-syslog-20200210-2052.zip

I'm see the following error in my log, but no reference to any bad files. BLAKE2 hash key mismatch, is corrupted This was the only entry in the log. Is there somewhere else I need to check? Also, if we do see errors, do we need to reformat the file or just recopy the indicated files? I do see errors on a couple of the other disks with file names indicated. Thanks in advance!

Having problems with preclear on 6.6.7. It starts up fine, but a few hours later I come back and its stopped. Screenshot is of the preclear screens/log and the system log. I can't tell what is causing it to stop. Could it just be the disk failing? Seems I'd have a error or something that would tell me... Thanks in advance! hunternas-diagnostics-20190312-0656.zip

UR 6.5.5. I've been using File Integrity for a long time. No real issues. Today, I received an email notice with the following error displayed. Jan 6 14:58:06 HunterNAS bunker: error: BLAKE2 hash key mismatch, /mnt/disk1/My Backups/_gsdata_/a9ebea1d339a02ae40d547cf8068834d.tib is corrupted Jan 6 14:58:08 HunterNAS bunker: error: BLAKE2 hash key mismatch, /mnt/disk1/My Backups/_gsdata_/3bef27d30a51b20186a922805386f65a.tib is corrupted This happened back in Oct with the same files. Oct 21 15:09:53 HunterNAS bunker: error: BLAKE2 hash key mismatch, /mnt/disk1/My Backups/_gsdata_/a9ebea1d339a02ae40d547cf8068834d.tib is corrupted Oct 21 15:09:54 HunterNAS bunker: error: BLAKE2 hash key mismatch, /mnt/disk1/My Backups/_gsdata_/3bef27d30a51b20186a922805386f65a.tib is corrupted These are backups of one of my workstations. Large file size. Anything to worry about? Diagnostics file attached. Thanks in advance! hunternas-diagnostics-20190106-2330.zip

Ok, I'll reinstall and try that. Will keep you posted. In thinking about how a backup job might work. Is there some aspect of backing up via FTP that could cause ProFTPd to have a problem/memory leak over time? On a nightly basis I might backup 1000 files. Mostly documents, sometimes music/video files. If you had an idea, I could build a test case that would push the boundaries...

Ok, I've followed your directions. I've been up for more than 4 days. Far longer than I've ever gone (usually crashes within 24 hours). I think it has to do with FTP file transfers. As I've mentioned I have about 12 goodsync FTP jobs that run nightly to backup various directories on my PC and such. So, evidently, on my system, something about ProFTPd causes my system to crash. What diagnostics can I conduct to isolate the problem? FYI, I've included my latest diagnostics. Thanks in advance! hunternas-diagnostics-20180524-1644.zip

There would be no need for a GUI Goodsync version that runs in the UnRaid WebGui (although that would be cool). What I'm looking for is someone to setup a docker with the Linux version/server for Goodsync as describe here: http://www.goodsync.com/for-linux Once the Goodsync docker is running, you'd use the Windows interface of Goodsync to run the backups. It would interface to the Goodsync Linux server/docker and handle the file management on the Linux side.

@SlrG - So I've built a little log using User Scripts. Works really well. In trying to uncover what's causing my server to crash and trying to eliminate ProFTPd as related to the source. What I'm finding (log attached) is that the problem appears at night, while backups are running. I have about 10 jobs that backup via ProFTPd. They start around midnight and end around 6am. If you look at my log, you see that during the day, memory usage is pretty stable. But at night, when the backup jobs run, memory usage expands until (and this is frustrating, SOMETIMES) it crashes. Perhaps it has to do with how much data movement? No idea how to diagnose that. One other important note. It appears it often crashes on the job that backups my workstation image. It can be anything from a small file (48mb) to a large file (10gb) depending on changes, etc. I have a 512gb cache drive, so that shouldn't be a problem. Perhaps this log will shed some light. Perhaps there are some additional commands I can add to my log to help diagnose the cause? Not saying its ProFTPd, but maybe something related to backups? My log script is pretty simple: #!/bin/bash echo '======Start=======' >> /boot/log_free_memory.log date >> /boot/log_free_memory.log free -h >> /boot/log_free_memory.log echo '======End=======' >> /boot/log_free_memory.log And I run it hourly. In the attached log, the server crashed after the 4:47AM log dump. I was out all day and didn't get the server restarted until 4PM. Thanks in advance for taking a look! log_free_memory.log

@SlrG I only have the Proftpd icon in settings. But in your comment to Meaux you said the Apache plugin wasn't working and you can't edit the file. I edited my config just to test and it looked liked it edited, but then got an error saving. Is that the current behavior? If the Apache Plugin is not working properly, could it be the cause of the problems I'm having? I've deleted the plugin from my system and disabled the reboot cron. I'll let you know if that solves my problem. I see there are a couple other Apache plugins out there. Do you recommend using them? Or is the editor Meaux is using be your new recommendation?

I rebuilt the server from scratch in December. How would I have installed the deprecated shutdown plugin? Perhaps in rebuilding the server, I inadvertently recreated the problem by installing something in error? All of my plugins and nerd tools are fully updated as far as I can tell... Installed Plugins as of 20180512.txt

Perfect, I will give this a try. One other thought. I just realized that I also have the default FTP server running. I've disabled it. Could having both the UR FTP and ProFTPd running simultaneously cause a problem?

Thanks, I will do so...

Sorry, should have been clearer. My script is using And it works, so was wondering if the path was incomplete. Evidently either works?

Is it /sbin/reboot or /usr/local/sbin/reboot?

Good catch @Squid @dlandon. Sorry, that's a typo, I was also working on a daily start/stop process for dockers and just copied it wrong. Proof reading isn't evidently one of my skills...

Did you get this figured out? Is what you have working now? You probably already know that In the scripts sub-directory for the cron you want to run, the script should be in a file simply called script. First time I tried to setup a script, I created the script in the cron directory (i.e. nightly_reboot) and called it nightly_reboot.cron, which was ignored by user scripts and it created a file in the nightly_reboot folder called script, which was empty and thus ran that instead.

I'm wanting a clean reboot on a daily basis and I don't want to cause unclean shutdowns. I run plex, mysql, pydio and other dockers. Will this script work to cleanly shutdown the dockers, then reboot? I'd put this in the User Scripts plugin... /etc/rc.d/rc.docker stop && /etc/rc.d/rc.docker start /usr/local/sbin/powerdown -r Thanks in advance!

@SlrG I've run several backups and noticed no problems with proftpd. I do see that the process is only alive when an actual ftp session is active. i.e. it only shows up as a process when a backup is running. Not seeing anything strange. Is there something else I can monitor? Is it possible that the Docker.img file has some runaway logging going on? How would i investigate that?

I took a look at this, shfs on my system: top - 08:03:26 up 15:15, 3 users, load average: 0.69, 0.66, 0.72 Tasks: 1 total, 0 running, 1 sleeping, 0 stopped, 0 zombie %Cpu(s): 4.0 us, 37.4 sy, 0.3 ni, 58.0 id, 0.0 wa, 0.0 hi, 0.2 si, 0.0 st GiB Mem : 15.369 total, 2.964 free, 3.849 used, 8.557 buff/cache GiB Swap: 0.000 total, 0.000 free, 0.000 used. 10.351 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13276 root 20 0 747644 274744 644 S 0.3 1.7 5:23.63 shfs I've started HTOP and added a memory meter just to see if the memory is growing. So far the max I've seen is 4.44G/15.4G and its steady. root@HunterNAS:~# free -m total used free shared buff/cache available Mem: 15738 3684 3292 606 8761 10855 Swap: 0 0 0 Thoughts?

Argh, sorry, not sure how that happened, here's the correct file: hunternas-diagnostics-20180510-0422.zip I'll take a look at the other points and see what happens...

I took your advice and disabled the transferlog (TransferLog NONE). It ran for about 3 days, then crashed again. I had turned on Fix Common problems troubleshooting mode. I've attached the file. Not sure what to look for. The last couple of problems was: May 10 04:12:50 HunterNAS root: Fix Common Problems Version 2018.04.25 May 10 04:12:51 HunterNAS root: Fix Common Problems: /var/log currently 2 % full May 10 04:12:51 HunterNAS root: Fix Common Problems: rootfs (/) currently 8 % full May 10 04:20:25 HunterNAS kernel: mdcmd (149): set md_write_method 0 May 10 04:20:25 HunterNAS kernel: May 10 04:22:51 HunterNAS root: Fix Common Problems: Capturing diagnostics. When uploading diagnostics to the forum, also upload /logs/FCPsyslog_tail.txt on the flash drive Attached is the Fix Common problems troubleshooting logs. Appreciate any help! hunternas-diagnostics-20180507-1131.zip FCPsyslog_tail.txt Last bit, I had found some posts about OOM issues here, I subsequently changed vm.dirty_background to 1% and vm.dirty_ratio to 2% based on the post, but then still had the problem. Thanks in advance!

I'd be interested, if it can become a supported product. Currently I'm using Goodsync via FTP to my UNRaid server.

Try making the window larger Duh... Got a new larger monitor and stacking browsers with smaller width... 1/2" too small. Thanks!

I'm at UR 6.4.1. Have the latest version of buttons and plugins running. But the buttons have stopped showing up this week after a reboot. I still see Dynamix system Buttons in the Plugins, but don't see anything displaying in the GUI. No buttons, no Log Tail, etc. Any ideas/

I've been dealing with a crazy cycle with my unraid server (latest version). The server is on an ASUS P8-V77Z motherboard, 16gb memory, 11 disks using 2 LSI 9207-8i controllers. I have a number of apps running, one of which is Proftpd which I rely on for backups (because of SMB issues). I have one docker running (Plex) which works fine. The problem I've had (and posted here: https://lime-technology.com/forums/topic/59269-persistent-syslog-or-how-to-save-syslog-in-a-crash/) didn't lead to a permanent answer. The server can run for a couple of days, then just dies. I opened a real-time log window (from the GUI) and just let it run hoping that the last entries might give me an answer. The very last lines in the real-time log tail were ProFTPd's typical complaint about 'world-writable directory'. I know this is a stretch, but I'm grasping at straws. Is it possible that ProFTPd could be having a conflict with something in my system? Is there a way to diagnose that? Log tail attached. Thanks in advance! Hunternas Log Tail.txt