Pducharme Posted October 20, 2015 Posted October 20, 2015 Hi, a while ago, I tested all version of Unraid 6 beta. I think one plugins did fill all the LOG partition and now, everytime I install a plugin (or update it), I always get lots of error because it is full. Attached is the picture of the dashboard showing the LOG at 100%... I would appreciate if someone can tell me how to clear it. 1 Quote
JonathanM Posted October 21, 2015 Posted October 21, 2015 Hi, a while ago, I tested all version of Unraid 6 beta. I think one plugins did fill all the LOG partition and now, everytime I install a plugin (or update it), I always get lots of error because it is full. Attached is the picture of the dashboard showing the LOG at 100%... I would appreciate if someone can tell me how to clear it. Unless you have changed some fundamental settings in unraid, the log partition is created during the boot process in RAM, and is not kept anywhere on powerdown. You probably have something misconfigured to write to the log partition. You can change the partition size at will, many people expand the stock 128MB to something more reasonable as well. 1 Quote
Pducharme Posted October 21, 2015 Author Posted October 21, 2015 I did nothing special, not changed anything in the Unraid fundamental... I remember that it was a Plugin that did that (I think proftpd, but not sure.) I reboot the Unraid when I upgrade version, so I did reboot it a lot since all beta version. This problem is present since beta2 or beta3. It never emptied itself. If you say it reset itself at powerdown, there is something that fill it, but when I boot the server, it's already at 100%... Quote
JonathanM Posted October 21, 2015 Posted October 21, 2015 Post the output of these commands. df -h /var/log du -sm /var/log/* 1 1 Quote
Pducharme Posted October 21, 2015 Author Posted October 21, 2015 Here it is : root@Unraid:~# df -h /var/log Filesystem Size Used Avail Use% Mounted on tmpfs 128M 128M 0 100% /var/log root@Unraid:~# du -sm /var/log/* 0 /var/log/btmp 0 /var/log/btmp.1 0 /var/log/cron 0 /var/log/debug 1 /var/log/dmesg 1 /var/log/docker.log 0 /var/log/faillog 1 /var/log/lastlog 1 /var/log/libvirt 1 /var/log/maillog 0 /var/log/messages 0 /var/log/nfsd 3 /var/log/packages 0 /var/log/plugins 0 /var/log/removed_packages 0 /var/log/removed_scripts 122 /var/log/sa 1 /var/log/samba 1 /var/log/scripts 0 /var/log/secure 1 /var/log/setup 0 /var/log/spooler 1 /var/log/syslog 2 /var/log/syslog.1 2 /var/log/syslog.2 1 /var/log/unassigned.devices.log 1 /var/log/wtmp root@Unraid:~# 1 Quote
Pducharme Posted October 21, 2015 Author Posted October 21, 2015 seems to be the /var/log/sa folder that contains lots of files and it look like it use 122Mb on the 128Mb total... But I don't know why, and what to do to find out why and to prevent it! Quote
BRiT Posted October 21, 2015 Posted October 21, 2015 Those files are system activities from the dynamix system stats/activities addon. If you're going to run that you need at least 384 meg log filesystem. Theres posts and threads in the forums here that gives instructions on how to make it larger. Typically this is handled in modifying your go file. 2 Quote
Pducharme Posted October 21, 2015 Author Posted October 21, 2015 Ok, I fixed it by upping the size of /var/log to 384m instead of default 128m. Dynamix System Stats needs 186mb, so I put 384mb to have free space. I think that the size of the LOG partition should be configurable in the WebGUI. Anyway, I put the command in my go file. Quote
unevent Posted October 21, 2015 Posted October 21, 2015 Has that part of Dynamics been fixed in 6? Increasing the size to 384 doesn't fix the problem, at least it didn't in v5, as it only delayed the brick wall of running out of space. Usually about 1.5 months between manual having to clear the data and restart the logger or reboot. Inconvenient when I don't reboot often, usually only twice a year to blow the dust out and clean the filters. Quote
schford Posted October 21, 2015 Posted October 21, 2015 I am new to this and just installed the Dynamix plugins, followed the install @ http://lime-technology.com/forum/index.php?topic=36543.0 I couldn't see anything about increasing log file size - is this something I need to do as well? Could you share the command you put in the go file to increase log size cheers? Is there a way to auto clear the logs down? Thanks Stuart Quote
Pducharme Posted October 21, 2015 Author Posted October 21, 2015 Has that part of Dynamics been fixed in 6? Increasing the size to 384 doesn't fix the problem, at least it didn't in v5, as it only delayed the brick wall of running out of space. Usually about 1.5 months between manual having to clear the data and restart the logger or reboot. Inconvenient when I don't reboot often, usually only twice a year to blow the dust out and clean the filters. I guess we will know later when the logs starts to get in every day. I am new to this and just installed the Dynamix plugins, followed the install @ http://lime-technology.com/forum/index.php?topic=36543.0 I couldn't see anything about increasing log file size - is this something I need to do as well? Could you share the command you put in the go file to increase log size cheers? Is there a way to auto clear the logs down? Thanks Stuart I didn't increased it before yesterday, except that my LOG partition was full, I didn't had any issue with it. Also, If it's not speficied in the install instructions, I wonder if it's only on certain hardware that would generate more logs (?)... Here is the command to insert in the go file. You can also run it on a live server without reboot and the LOG part increase right away. # Enlarge the LOG partition (because Dynamix System Stats needs at least 186Mb, default LOG is 128Mb) mount -o remount,size=384m /var/log I don't know if it's safe to delete the /var/log/sa/* (content), if so, we could do a if in the go file that check if the sa30 exist, and delete all sa* if it exist. I think that would make it keep the last 30 days (UNTESTED). 1 5 1 Quote
saarg Posted October 21, 2015 Posted October 21, 2015 It makes no sense to delete the log files in the go script as /var/log would be almost empty after a reboot Quote
Pducharme Posted October 21, 2015 Author Posted October 21, 2015 It makes no sense to delete the log files in the go script as /var/log would be almost empty after a reboot If true, you suggest that it get up to 186Mb in seconds after a reboot? because at each boot, I checked my LOG partition and it was at 100% already so probably not cleared ?? Quote
scottc Posted October 21, 2015 Posted October 21, 2015 seems to be the /var/log/sa folder that contains lots of files and it look like it use 122Mb on the 128Mb total... But I don't know why, and what to do to find out why and to prevent it! Look inside the /var/log/sa folder and see what files are in there. Those files are system activities from the dynamix system stats/activities addon. If you're going to run that you need at least 384 meg log filesystem. Theres posts and threads in the forums here that gives instructions on how to make it larger. Typically this is handled in modifying your go file. I use the system stats addon and have increased my /var/log to 256m in the go file and i am only using 10% Quote
saarg Posted October 21, 2015 Posted October 21, 2015 It makes no sense to delete the log files in the go script as /var/log would be almost empty after a reboot If true, you suggest that it get up to 186Mb in seconds after a reboot? because at each boot, I checked my LOG partition and it was at 100% already so probably not cleared ?? I thought that the log partition was only a ramdisk. It says tmpfs if you run mount in a terminal, so I don't think this have changed. Is there a plugin that saves the log to the usb drive and then loads it back into /var/log on boot? Quote
trurl Posted October 21, 2015 Posted October 21, 2015 It makes no sense to delete the log files in the go script as /var/log would be almost empty after a reboot If true, you suggest that it get up to 186Mb in seconds after a reboot? because at each boot, I checked my LOG partition and it was at 100% already so probably not cleared ?? Nothing to clear, since /var/log is in RAM. Must be something with your configuration filling it up. Maybe boot in SAFE mode and see if it still happens. Quote
Pducharme Posted October 21, 2015 Author Posted October 21, 2015 I don't know of any plugin that does that... Quote
beardedpants Posted October 22, 2015 Posted October 22, 2015 I have the same issue, except mine reaches 100% in a couple of days, not immediately. I know that the log partition is tmpfs on ramdisk and that a reset will clear it, but does having the partition 100% filled negatively affect it, i.e., does logging still work? Quote
scottc Posted October 22, 2015 Posted October 22, 2015 Could someone with the full log issue do the following commands in shell and post the output du -sm /var/log/* du -sm /var/log/sa/* might help track down what in the sa directory is using all the space Quote
beardedpants Posted October 22, 2015 Posted October 22, 2015 I rebooted yesterday to set my tmpfs to 256M, so my log isn't full yet, but: root@TOWER:/# du -sm /var/log/* 0 /var/log/btmp 0 /var/log/cron 0 /var/log/debug 1 /var/log/dmesg 0 /var/log/docker.log 0 /var/log/faillog 1 /var/log/lastlog 0 /var/log/libvirt 0 /var/log/maillog 0 /var/log/messages 0 /var/log/nfsd 3 /var/log/packages 0 /var/log/plugins 0 /var/log/removed_packages 0 /var/log/removed_scripts 14 /var/log/sa 1 /var/log/samba 1 /var/log/scripts 0 /var/log/secure 1 /var/log/setup 0 /var/log/spooler 1 /var/log/syslog 1 /var/log/wtmp root@TOWER:/# du -sm /var/log/sa/* 5 /var/log/sa/sa20 7 /var/log/sa/sa21 3 /var/log/sa/sa22 Quote
Ockingshay Posted December 19, 2015 Posted December 19, 2015 My log fills up pretty quickly as well. total 396 drwxr-xr-x 12 root root 540 Dec 13 04:40 ./ drwxr-xr-x 12 root root 280 Dec 1 23:19 ../ -rw-r--r-- 1 root root 196 Dec 18 16:55 apcupsd.events -rw-r--r-- 1 root root 198 Dec 13 04:40 apcupsd.events.1 -rw------- 1 root root 0 Dec 19 09:22 btmp -rw-r--r-- 1 root root 0 Dec 11 2014 cron -rw-r--r-- 1 root root 0 Dec 11 2014 debug -rw-rw-rw- 1 root root 53312 Dec 7 09:24 dmesg -rw-rw-rw- 1 root root 524 Dec 9 20:30 docker.log -rw-r--r-- 1 root root 0 Feb 14 2014 faillog -rw-r--r-- 1 root root 0 Dec 19 09:22 lastlog drwxr-xr-x 5 root root 120 Dec 7 09:26 libvirt/ -rw-r--r-- 1 root root 6100 Dec 19 00:20 maillog -rw-r--r-- 1 root root 0 Dec 11 2014 messages drwxr-xr-x 2 root root 40 May 16 2001 nfsd/ drwxr-xr-x 2 root root 3240 Dec 19 08:23 packages/ drwxr-xr-x 2 root root 240 Dec 19 08:23 plugins/ drwxr-xr-x 2 root root 60 Dec 19 08:23 removedèpackages/ drwxr-xr-x 2 root root 40 Oct 27 1998 removedèscripts/ drwxrwxrwx 2 root root 300 Dec 19 00:00 sa/ drwxr-xr-x 3 root root 100 Dec 7 09:24 samba/ drwxr-xr-x 2 root root 80 Dec 7 09:24 scripts/ -rw-r--r-- 1 root root 0 Dec 11 2014 secure drwxr-xr-x 3 root root 60 Dec 1 23:19 setup/ -rw-r--r-- 1 root root 0 Dec 11 2014 spooler -rw-r--r-- 1 root root 315484 Dec 19 09:26 syslog -rw-rw-r-- 1 root utmp 8064 Dec 19 09:22 wtmp du -sm /var/log/* 1 /var/log/apcupsd.events 1 /var/log/apcupsd.events.1 0 /var/log/btmp 0 /var/log/cron 0 /var/log/debug 1 /var/log/dmesg 1 /var/log/docker.log 0 /var/log/faillog 0 /var/log/lastlog 0 /var/log/libvirt 1 /var/log/maillog 0 /var/log/messages 0 /var/log/nfsd 2 /var/log/packages 0 /var/log/plugins 1 /var/log/removedèpackages 0 /var/log/removedèscripts 126 /var/log/sa 1 /var/log/samba 1 /var/log/scripts 0 /var/log/secure 0 /var/log/setup 0 /var/log/spooler 1 /var/log/syslog 1 /var/log/wtmp du -sm /var/log/sa/* 4 /var/log/sa/sa07 12 /var/log/sa/sa08 12 /var/log/sa/sa09 12 /var/log/sa/sa10 12 /var/log/sa/sa11 12 /var/log/sa/sa12 12 /var/log/sa/sa13 12 /var/log/sa/sa14 12 /var/log/sa/sa15 12 /var/log/sa/sa16 12 /var/log/sa/sa17 7 /var/log/sa/sa18 1 /var/log/sa/sa19 Quote
JorgeB Posted December 19, 2015 Posted December 19, 2015 My log fills up pretty quickly as well. See reply #6 from this thread: http://lime-technology.com/forum/index.php?topic=43538.msg415645#msg415645 2 Quote
greyday Posted April 1, 2021 Posted April 1, 2021 (edited) Just to hopefully save some other folks some time, because it's not posted here and this is what comes up most often when I search for this problem or how to resize the log (and the next like 10 answers also never state it), the file named "go" that you need to modify is located at: boot/config/ Edited April 1, 2021 by greyday Quote
trurl Posted April 1, 2021 Posted April 1, 2021 This is a pretty old thread, and ultimately, increasing log space is not the solution, it will just make it take longer to fill. Filling log is usually a sign of some other problem that needs to be addressed. Quote
Guill.St-P Posted June 5, 2021 Posted June 5, 2021 (edited) same problem for me; server is up for just 2 months any clue? edit: log file attached edit2: rebooted and log is back to 1% (for now) root@Alligator:~# du -sm /var/log/* 1 /var/log/Xorg.0.log 1 /var/log/Xorg.0.log.old 1 /var/log/apcupsd.events 1 /var/log/apcupsd.events.1 1 /var/log/apcupsd.events.2 1 /var/log/apcupsd.events.3 1 /var/log/apcupsd.events.4 0 /var/log/btmp 0 /var/log/cron 0 /var/log/debug 1 /var/log/diskinfo.log 1 /var/log/dmesg 1 /var/log/docker.log 0 /var/log/faillog 1 /var/log/fluxbox.log 1 /var/log/gitflash 1 /var/log/lastlog 0 /var/log/libvirt 1 /var/log/maillog 0 /var/log/messages 0 /var/log/nfsd 123 /var/log/nginx 0 /var/log/packages 1 /var/log/pkgtools 0 /var/log/plugins 0 /var/log/preclear.disk.log 0 /var/log/pwfail 0 /var/log/removed_packages 0 /var/log/removed_scripts 0 /var/log/removed_uninstall_scripts 1 /var/log/samba 0 /var/log/scripts 0 /var/log/secure 0 /var/log/setup 0 /var/log/spooler 0 /var/log/swtpm 1 /var/log/syslog 2 /var/log/syslog.1 4 /var/log/syslog.2 0 /var/log/vfio-pci 1 /var/log/wtmp root@Alligator:~# du -sm /var/log/sa/* du: cannot access '/var/log/sa/*': No such file or directory alligator-diagnostics-20210605-0952.zip Edited June 5, 2021 by Guill.St-P Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.