/tmp getting full

Dear friends,
Please help me RCA this issue.
My HW is x86(PC-engine APU2); running 19.07.
Its generating many files such as /tmp/logread.1760706483.12096.11.core
Over a week this leads to disk full and basic functions like DHCP stop working.
Thx in advance.

How did you configure your device to send logs to /tmp?

Perhaps undo this setting - OpenWrt doesn't save logs in /tmp like this by default.

This version is EoL.

very EoL ...

and why ?

1 Like

Pretty much.
I have a few others with the same version working fine.
I could upgrade; or write a script to delete or reboot.
Wanted to know if it’s a known issue.

user mistakes aren't openwrt errors, even if it was, no one's going to fix a 6 y.o bug that (most likely) doesn't exist in the recent releases.

you're also running a release from 2019.

1 Like

`/tmp/logread.1760706483.12096.11.core`

Means process logread is crashing, like log forwarding to somewhere else.

Random crashes usually mean unstable RAM chips, run some memtest at least few cycles and remove guilty.

Ahh ohh and upgrade to 24.10……

Wht is that?

2 Likes

Haha, sure ; i might have a config issue.
I checked my configs, I have remote logging disabled.

if @brada4's correct, run a memtest on the box, unfortunately RAM's soldered AFAIK, if it doesn't pass the test, you'll need to buy new hw.

upgrade the BIOS too, while you're at it - https://pcengines.github.io/.

2 Likes

Thank you folks.
RAM corruption as suspect; wasn’t on my radar.
It could be that.

2 Likes

Is it always logread or other processes as well?

Bad RAM typically results in frequent kernel crashes or freezes. Does this happen?

Another type of file I saw is /tmp/pingresult,xxxxx.core
Am not aware which app generates that.
So its not limited to logread.
No freeze observed, ssh is always functioning; so far.

You should check the RAM anyway with e.g. Memtest86+, but in absence of kernel crashes this may be a different issue, such as bad flash or corrupted file.

Or storage wear, APU2s are using SD cards just as APU1s, if I remember correctly.

1 Like

I am gonna first try “no logging” to /tmp; ”ulimit -c 0”
if that doesn’t fix weekly reboot cron.
Followed by upgrade the OS version; until any issue in routing.
Thanks for the tip.

By “bad flash” I meant bad flash storage, possibly because of flash storage wear.

1 Like

We can’t tell you what to do but this is not the right approach. Your device likely has a fundamental issue: either hardware issue or core files corruption, or both. If it’s a hardware issue then software tweaking will just waste your time. So it is in your best interest to diagnose the hardware before trying anything else. Making a thumb drive with a ready-to-use Memtest86+ and testing the memory, and then checking your storage device - takes a fraction of the time you are about to waste trying all the possible combinations of software tweaks.

2 Likes

Sure @antonk
It affects once a week and reboot resolves it.
But I get your point.
If other HW units with same OS version and config are working fine; this issue is possibly HW OR network dependent app hanging.
I intend to juice it out as much as possible…
Good thing, it doesn’t seem a systematic problem.
Thanks for commenting.

There is another topic you keep handwaving away, upgrade the damned device first. Maybe you're not the only one controlling the device, with some of their 'services' running amok, while you're ignoring basic security.

1 Like

OS upgrade is next in my list.
In my limited experience OpenWrt 19.07.8 works flawless on this HW.

1 Like

Flawless crash dumps filling /tmp ?

4 Likes