[Updating plugins fail after server runs for a few days]

I found the problem!!  I had a bash script that was scheduled to run every other day that, as part of the script, was incorrectly redirecting the output of a command to /dev/null.  Because it was not doing the redirection of stdout and stderr it was overwriting the character device /dev/null with a regular file called /dev/null.

 

Anytime something was trying to redirect to /dev/null it was failing.

 

I have

• removed the incorrect /dev/null file 
• created a new character device named /dev/null
• and finally corrected the redirection to 

rm -rf *.1 > /dev/null 2>&1

instead of 

rm -rf *.1 2>&1 /dev/null

 

Since making this change to script and running manually the permissions on /dev/null are staying

root@Tower:/dev# ll null
crw-rw-rw- 1 root 1, 3 Nov  2 14:59 null

 

[Updating plugins fail after server runs for a few days]

I haven't tried your suggestion yet, but I don't see how, if it was go file, things would work fine when rebooted and then fail days later.

[Updating plugins fail after server runs for a few days]

I am having trouble updating plug-ins (any plug in) after the server has run for a few days.  I get error such as " Unable to install as gzip is not available on this system."  I can see that gzip is installed and should be in the path

root@Tower:~# which gzip
/usr/bin/gzip

If I reboot the server, plug ins will install fine......until the server has a few days uptime.

 

It is frustrating that everything else seems to be running fine in UnRaid but having to restart fairly regularly to install upgraded plugins is getting old.

 

Any ideas??

tower-diagnostics-20221102-1301.zip

[reiserfsck --rebuild-tree stuck at Syncing..finished]

I recently had 2 drives fail within hours of each other that seems to have corrupted the filesystem on one of the drives.  As expected the rebuild from parity did not fix the file system corruption and left the disk in read-only mode.  I restarted the array in maintenance mode and ran reiserfsck --check /dev/md10 .

 

The results were:

13 found corruptions can be fixed only when running with --rebuild-tree
###########
reiserfsck finished at Wed Jun 23 11:32:32 2021
###########
 

I then ran reiserfsck --rebuild-tree /dev/md10.  As of today ( 2 days later) it is still running and the last update was 

Flushing..finished
Syncing..finished

 

It has been at this state for at least 8 hours now.  I can't get to the web GUI to see if the read/write count on the drive is changing but looking at this for last hour I don't see any change.  With the my servers plugin forcing ssl through unraid.net, starting a resiser check kills the gui for me.

 

root@Tower:/proc/30353# cat io
rchar: 5155039685281
wchar: 11886923136
syscr: 1258554627
syscw: 3286164
read_bytes: 5136389296128
write_bytes: 10541928448
cancelled_write_bytes: 0
 

 

 

Should kill the process and restart the array and see what it looks like or should I continue to wait it out.  This is an 8TB Western Digital but over 2 days for a fsck seems excessive to me.

 

Thanks in advance.  And I know I should convert this to XFS but I need to get things working again before starting that process.

 

Tony

[Unraid Forum 100K Giveaway]

What I like most is the flexibility in adding and changing hardware.

 

What I would like to have in 2020 is multiple unraid servers that are managed through a single gui and presents unified shares.