Hello all,

 

I am running an Orange Pi 5 board with Armbian on a SD Card and I realized that my /var/log path is constantly full, with it being at /dev/zram1

It gets full at 50Mb with the file /var/log/samba/cores/smbd/core taking up all the space

 

I have not managed to read this file, so I can't tell what kinds of errors are showing up. My OpenMediaVault and samba setup are running perfectly fine, and even though I delete this core file, it shows up again during reboot.

I have tried to set 

enable core files = no

in smb.conf

With no sucess. The file continues to show up during reboot.

 

Any ideas how to solve this?

 

Best regards

Hi,

 

Writing logs to certain types of storage can shorten the lifetime of the media (although it can be difficult to identify the impact of lifetime of writing logs due to commercial sensitivity). To address this, Armbian uses memory (RAM) instead.

 

This can be disabled by editing /etc/default/armbian-zram-config and changing the line

ENABLED=true

 

at the risk of shortening the longevity of your storage. YMMV. You will need to reboot for the change to take effect.

 

If you prefer to alter logging level for samba, perhaps this is what you need (although 50MB is not a lot of logs these days) - https://wiki.samba.org/index.php/Setting_the_Samba_Log_Level

I had the same problem with /var/log filling up.  It was causing Jellyfin playback to fail.  I tried disabling armbian-zram-config service in the config file, but then the /var/log got mounted to an armbian-ramlog device that is the same 50M size.  So I ended up changing the armbian-ramlog size to 500M in it's config file and re-enabling the armbian-zram-config service in it's config file.  Now it's once again mounted to /dev/zram1, but it's now 500M.

Edited March 22, 20251 yr by JohnU

I was looking for a solution to this for a long time before seeing John's post and figuring it out. Here's a more explicit explanation to hopefully help make this info easier to find.

This was tested and does work on both the Orange Pi 5 16GB, and the Orange Pi Zero 3 4GB. I haven't run into this issue on my x86 nodes as it doesn't appear zram exists on them at all on a fresh install.

If you go to the /etc/default directory, there should be a file called <distro>-ramlog. If you're on armbian it will be armbian-ramlog, for me on Debian it's called orangepi-ramlog.

In this file there will be a line reading

"SIZE=50M"

Simply edit this line to whatever value you'd like, and then reboot the device.

If rebooting the system will cause serious problems, you can use the following command on armbian:
 

service armbian-zram-config restart

Again, I'm using the official Orange Pi Debian image, so for me, the command would instead be as follows:
 

service orangepi-zram-config restart 

 

Don't panic if you notice that this command results in the creation of a zram2 and zram3, as these duplicates will automatically remove themselves the next time you reboot the machine

Edited May 10, 20251 yr by killronaldreagan

I came to this topic with the same issue on a pair of Orange Pi 3's (with 1 GB RAM) running PiHole - /var/log would fill up.  Thank you for the help on how to solve this!

 

For now, I've set /dev/zram1 to be 256MB instead of 50, to hopefully allow more time for the logs to properly rotate / clean themselves up.  The larger question I have is, what is the intent of having this configured?  Is it to prevent wear & tear on the SD card with all of the log writing?  (I'd like to disable it if I can so I can use the full storage of my SD card instead of limited RAM, but if it's going to potentially kill my storage, I probably shouldn't.)

3 hours ago, Geoffrey Schaller said:

Is it to prevent wear & tear on the SD card with all of the log writing?

Yes exactly

Tired of this Issue, just published a simple app written in python that keeps /var/log clean moving old files... 

Just give it a chance, works fine on mi two OrantePi boards

https://github.com/mgoreiro/logguard/releases/tag/v1.0.5

On 10/6/2026 at 9:39 PM, mgoreiro said:

Tired of this Issue, just published a simple app written in python that keeps /var/log clean moving old files... 

 

1. If written by AI, it should be disclosed more openly than hidden in the commits IMHO. (this is written by claude)

2. By using this, the storage gets written to 1440 times per day, ie once per minute via the systemd timer. (If storage is on an SD-card the longevity of that storage is significantly shortened, you might as well just disable the ramlog completely)

3. After a very quick glance it looks like logs will be deleted without archiving too. For example, if the rotation fails, the logs are still truncated making it impossible to debug using logs in case of a write failure. It also looks like it will --vacuum-size with JOURNAL_VACUUM_SIZE=20M, that is a very small size imho, so not a lot to look back at after it vacuums. /var/log/journal is excluded? (disclaimer: I only took a very quick glance, so I could be wrong in my analysis)

 

The better option is to do what is described in this thread, increase the size of the ramlog by editing /etc/default/armbian-ramlog and reboot (or reloading configs & restarting the relevant systemd service), or just disable ramlog to write directly to disk.

 

Just my two cents.

Edited Thursday at 03:59 AM3 days by bedna