Full Drive, Nothing on it

I made a stupid mistake and let our server get full from a packet capture. I got reports of big problems, especially attempting to use the park module, and I immediately realized my mistake. I couldn’t access the gui, and since I had the logs in the temp folder, I just rebooted the server and it seemed to come up OK. I was able to access the gui fine this time, so I looked in system admin-storage. The boot drive has plenty of space, but the other drive is completely full. Things quickly detiorated again and now I can’t access the gui anymore. But running ls -alh in the root folder doesn’t give me any clue where the storage is going. Also, we have raid on this system, 2 100 gb drives. I’m attaching a screenshot I took from the system admin. Also, asterisk is not working properly now.

Any help would be greatly appreciated.

“Standard procedure” is to log into the console and delete the offending file on purpose. If it’s not in /tmp, it’s possible that it ended up in “lost+found”, which means that all of the space is still allocated even though you can’t do much of anything with it.

While rebooting “should” clear the /tmp directory, the action is not guaranteed. You really need to do it yourself.

Use the ‘df’ command from the console to verify the actual status of the disk. The GUI’s time granularity is not “real-time”.

https://www.tecmint.com/find-top-large-directories-and-files-sizes-in-linux/

In your case, from root execute the following:

du -a / | sort -n -r | head -n 5

It will throw a few errors about /proc files - ignore - Here is what it looks like on a fresh load:

4334848 /
2240040 /usr
1248288 /var
676380 /usr/lib
583628 /var/lib

From there, you should be able to find the culprit.

1 Like

rm -rf /var/log/asterisk/full.[0-9]*

That will free up some log space but he said he was doing a packet capture - that is the file he is looking for.

Strange. I ended up figuring it out on my own. But the culprit was a file named newfirmware in my tmp folder. With the size of about 64gb. I’m pretty sure it wasn’t there earlier when I was looking. Deleting it brought my disk usage to 39%. It doesn’t seem to be filling up again, but I find that file strange. It was so large, with the name newfirmware, in the tmp folder after multiple reboots, and I couldn’t find it after many ls -alh commands. Only when I ran du -s * | sort -n, did I find that the tmp directory actually was full. Contrary to everything else I had been running. Any ideas? Is it possibly an EPM thing? I’m only thinking that because of the name of the file.

The OP said the caps where in /tmp , that WOULD be ephemeral on most Raspi’s

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