Cat: write error: No space left on device

Please follow the below template, it will help us to help you!

Expected Behaviour:

It should be showing the recent activity

Actual Behaviour:

The last logging entry is like 12 hours ago.

Debug Token:

Your debug token is: Use netcat.

I don't know about this ... but I guess the debug token should be other, but I don't know how to get the correct token.

Anyhow...

In the log there is this phrase:

cat: write error: No space left on device

But I have quite enough free space.

I found out that I have enough space in my hard drive, but the var/log was full

Filesystem     1M-blocks    Used Available Use% Mounted on
udev                877M      0M      877M   0% /dev
tmpfs               202M      4M      199M   2% /run
/dev/mmcblk0p1    14588M   2253M    12158M  16% /
tmpfs              1009M      1M     1009M   1% /dev/shm
tmpfs                 5M      1M        5M   1% /run/lock
tmpfs              1009M      0M     1009M   0% /sys/fs/cgroup
tmpfs              1009M      1M     1009M   1% /tmp
/dev/sda1        937872M 146972M   790885M  16% /sharedfolders/OpL1TB
log2ram             50M      50M       50M 100% /var/log
tmpfs               202M      0M      202M   0% /run/user/997
tmpfs               202M      0M      202M   0% /run/user/1000

I just change the value in the config file of log2ram from 50mb to 150mb, but I don't know if this is going to solve the problem in the near future.

Filesystem     1M-blocks    Used Available Use% Mounted on
udev                877M      0M      877M   0% /dev
tmpfs               202M      4M      199M   2% /run
/dev/mmcblk0p1    14588M   2253M    12158M  16% /
tmpfs              1009M      1M     1009M   1% /dev/shm
tmpfs                 5M      1M        5M   1% /run/lock
tmpfs              1009M      0M     1009M   0% /sys/fs/cgroup
tmpfs              1009M      1M     1009M   1% /tmp
/dev/sda1        937872M 146972M   790885M  16% /sharedfolders/OpL1TB
log2ram             200M     51M      150M  26% /var/log
tmpfs               202M      0M      202M   0% /run/user/997
tmpfs               202M      0M      202M   0% /run/user/1000

I've read somewhere about logrotating or something like that, but I don't know if have that set it up. I aso read there about FTL database, but I don't know if it's related or I can setup it in someway I can fix this problem better.

All of this has come because in the same machine I've setup the pi.hole (a cubox-i) I have also a plex server, among other things. Yesterday I added a music library to the plex server and it create too many request in a really short period of time.

Any advice on how to handle this? I have plenty of space in my SD card –it's a 16gb card– but I don't know if resizing /var/log is the correct answer to this problem.

You have the /var/log partition set to use RAM instead of SD Card space, check the distribution source that you got the OS from and see if they have instructions on how to disable log2ram to get space back.

1 Like

Thanks a lot for pointing that out... I'm under Armbian. I can ask in their forum and check the documentation to see if they have any instructions.

On the log2ram repo seems that it has to be copy to somewhere everyday or every hour.

Perhaps the problem was that too much request in one hour and the system got stuck?

Thanks anyway to point that out.

Ah, with Armbian I think you can use sudo systemctl disable --now log2ram, that's what I do with my NanoPi Neo running Pi-hole on Armbian. Great OS and great project, I donate to them frequently.

1 Like

Thanks for the insight!!!!!

However... do you think it's better to disable it? Will /var/log/ be stored on the main partition /dev/mmcblk0p1, then? Isn't than bad for the SD?

Sorry if I'm asking to much. I'm just trying to figure out that is the best solution. :blush:

I have 2GB of RAM in that Cubox, but since I want to run more apps as a server, I guess that I should try to keep efficiency of resource usage at the maximum.

Unless you have a bad power supply or use off-brand SDCards then you're fine logging to the card. The old myth that SDCards die is pretty much debunked. Almost all of the issues can be tied back to using a cell-phone charger and the inexpensive thin, high-resistance USB cables that come with them. Using a decent power supply and a good cable will remove that problem.

The issue with ramlogs is that you will lose the contents of the director when you reboot. And you're limited to a vastly smaller size to store the logs. So you can keep the ramlog if that's what you feel is best, but know the caveats going in to the process. You'll end up with the situation that caused the original post.

1 Like

Thanks a lor for your time again.

No, I don't think I have a lousy power source or SD card :stuck_out_tongue:. I use the power source provided with the Cubox which doesn't even use an usb to connect in the Cubox like the Pi. The SD is a good quality, I believe it's a Kingston.

Great! I'll probably follow your advice and disable the log2ram.

Disconnected... I've also noticed that in raspbian isn't running log2ram. I really don't know why they are running it on Armbian.

Barrel connectors are vastly better power sources than microUSB connectors. DietPi and Armbian both use log2ram, and they both have their reasons to why they use that package. And yes, Raspbian does not use any ram logging systems.

Let us know if you run in to any problems!

Thanks for the insights. They are really appreciated for a newbie like me.

The DietPi project looks really interesting and easier to manage for someone with a few knowledge of linux like me.

Would you recommend it to install Pi-Hole with DietPi? I know that some developers doesn't like the idea of their software being use in those slim distros because they sometimes trim essential functions.

The aim is to have more apps than pi-hole in the same board –the cubox.

DietPi is a great distribution and we have no problems with their inclusion of the Pi-hole with DietPi.

1 Like

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.