years ago when i first setup my unraid server, I was having issues with the log share size, so I found this discussion which uses a few lines in the go file to increase the log size:

 

https://lime-technology.com/forum/index.php?topic=38564.msg410062#ms

 

Specifically the lines are:

 

mount -o remount,size=256m /var/log
logger -tgo "Increased space for logs to 256MB"

 

I'm wondering if this is still necessary in 2022? Has something changed in unraid making this unnecessary after 6 years or is this still on a case by case basis?

I'm surprised this hasn't been answered as it comes pretty high on search engines. Anyways.

 

The important thing is to understand what we are dealing with here. For instance, here is what my /var/log looks like currently:

 

root@server:~# df -h /var/log
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           128M  105M   24M  83% /var/log

root@server:~# du -ahx /var/log | sort -hr | head
105M    /var/log
50M     /var/log/syslog.2
38M     /var/log/nginx/error.log.1
38M     /var/log/nginx
8.3M    /var/log/samba
7.3M    /var/log/syslog
5.6M    /var/log/samba/log.rpcd_lsad
2.7M    /var/log/samba/log.samba-dcerpcd
1.4M    /var/log/syslog.1
704K    /var/log/pkgtools

 

So, what is going on here? Long uptime, mover logging enabled, and... a bunch of nginx errors. Unsure why but nginx crashed (the webUI became weirdly unresponsive), it took me a while to notice as I wasn't specifically monitoring the content of that log file and didn't visit the webUI in a while as well. Anyways, of course here cleaning things up would be good enough, at the same time 128M is a very small amount of space. You don't want your /var/log to fill up your memory, but you don't want to lose your syslog in the event of an issue similar to the nginx issue I had. Basically, as long as you have plenty of memory available, it's safe to expand it to say 512M or even 1G, by 2023's standards keeping 1G of logs isn't that bad. Using a proper syslog server would definitely offer better solutions in terms of long-time logging and archiving.

14 hours ago, dnLL said:

I'm surprised this hasn't been answered as it comes pretty high on search engines. Anyways.

 

The important thing is to understand what we are dealing with here. For instance, here is what my /var/log looks like currently:

 

root@server:~# df -h /var/log
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           128M  105M   24M  83% /var/log

root@server:~# du -ahx /var/log | sort -hr | head
105M    /var/log
50M     /var/log/syslog.2
38M     /var/log/nginx/error.log.1
38M     /var/log/nginx
8.3M    /var/log/samba
7.3M    /var/log/syslog
5.6M    /var/log/samba/log.rpcd_lsad
2.7M    /var/log/samba/log.samba-dcerpcd
1.4M    /var/log/syslog.1
704K    /var/log/pkgtools

 

So, what is going on here? Long uptime, mover logging enabled, and... a bunch of nginx errors. Unsure why but nginx crashed (the webUI became weirdly unresponsive), it took me a while to notice as I wasn't specifically monitoring the content of that log file and didn't visit the webUI in a while as well. Anyways, of course here cleaning things up would be good enough, at the same time 128M is a very small amount of space. You don't want your /var/log to fill up your memory, but you don't want to lose your syslog in the event of an issue similar to the nginx issue I had. Basically, as long as you have plenty of memory available, it's safe to expand it to say 512M or even 1G, by 2023's standards keeping 1G of logs isn't that bad. Using a proper syslog server would definitely offer better solutions in terms of long-time logging and archiving.

Thanks. I came to this conclusion after posting my original post.  Appreciate you chiming in to reaffirm!

Since I have 64 gigs of ram, I felt safe to increase mine to 512Mb

Just saw that this is an old thread, but it still comes up on google search.