Growing /tmp folder

BigFrank

New Member
Joined
Nov 9, 2024
Messages
16
Reaction score
9
Credits
152
Hi there. I am running Pop-OS 22.04 LTS and got a warning about running out of disk space.

I ran disk analyzer and it showed that my /tmp folder was over 8GB in size. Of course if I restart my pc the problem goes away. But my standard process has been to just let it go to sleep (Sorry - I have to look at the settings better) on it's own and just wake it when I need it.

I am running firefox and open office and chromium and not much that I can think of else.

Is there a way to figure out what program is writing these files? Or a setting I should be looking for to change?

Any help is appreciated. Thanks
 


I dont know if it will work in Pop, but you could try
sudo find /tmp -type f -delete
 
Yep - that deletes a lot of the files quickly.

But there are 1000s of locked files named like

systemd-private-7def053b6b694ff1bd120cca6b064259-systemd-logind.service-QjYdCG

that it doesn't delete. A reboot works - but just trying to find out what the underlying issue is.
 
No Issue, the temp files are pre-programmed to delete on power down re-boot, I have seen a script somewhere [sorry cannot remember where at the moment[ to set the temp files to empty on a pre-set cycle [number of days from 2 to 10] for machines that are not shut down on a regular basis
 
I don't use systemd so there is only few files in /tmp and these are small

Fillin up /tmp should not happen (nobody is going to reboot server to clean up /tmp and guess what is safe to delete).
Either your config needs to be reviewed, or Pop-OS is buggy or God forbid systemd.

I would also try to use logrotate instead of blindly delete log files (or whatever tool systemd provides for rotating logs). SystemD probably has a tool that lets you safely rotate/delete files. It (probably) detect what can be deleted.
 
Last edited:
To find out what is creating those files.

Code:
sudo lsof +D /tmp

You will see some output similar to this.

Code:
lsof: WARNING: can't stat() fuse.portal file system /run/user/1000/doc
      Output information may be incomplete.
COMMAND     PID     USER   FD   TYPE             DEVICE SIZE/OFF   NODE NAME
sddm       1989     root   12u  unix 0x000000001ab7d84c      0t0  28462 /tmp/sddm-auth-746ff75f-24bc-4cf6-8228-057b22a759fc type=STREAM (LISTEN)
sddm       1989     root   17u  unix 0x0000000006829862      0t0  36831 /tmp/sddm-auth-746ff75f-24bc-4cf6-8228-057b22a759fc type=STREAM (CONNECTED)
.<snip>
...
This will show the process IDs and the high level processes. Now that you know the process IDs (PID) run this...

Code:
ps -ef  | grep 1989

Just replace the "1989" with whatever your PID is. It sounds like like you may have more than one application
doing this, so you may have to do this for multiple PIDs.

How often do you reboot? /tmp gets cleaned out every few reboots (each distro ahas a little different policy).

I'm not sure about PopOS, but you can probably install auditd somehow.
Then run this.
Code:
sudo auditctl -w /tmp -p war -k tmp_watch

Check the logs you just created.
Code:
sudo ausearch -k tmp_watch
 
Last edited:
Have a read here:


My notes from that time. Pay no attention to the gaps between words....that is just how it transferred.

The notes refer to the link above



How to disable logging to /var/log/syslog and use only systemd logs

GOOD article and dated in 2022

Is it enough to disable the transfer of log messages to syslog by setting the "ForwardToSyslog" key to "no" in "/etc/systemd/journald.conf" and stopping and disabling the rsyslog service ?

I did the above....ForwardToSyslog = no ....and it is like that now 16:00 on august 26 2022.kern log is at 99.8kb at same time////syslog is at 178.6kb at same time

5 minutes and a reboot later they have both doubled in size.

SO....I ran (at 16:30 same day) : sudo systemctl disable --now syslog.socket rsyslog.service
and...
sudo systemctl disable --now systemd-journald.service
Got a warning : Warning: Stopping systemd-journald.service, but it can still be activated by:
systemd-journald.socket
systemd-journald-dev-log.socket
systemd-journald-audit.socket

now I will delete both kern and syslog....and see what happens

August 27....215GB free....(14.9% Full)...appears to be consistent...includes KPatience.etc
 
To find out what is creating those files.

Code:
sudo lsof +D /tmp

Thanks for this. I ran the command and found out it was Surfshark application. Not even connected but open. So far I have uninstalled and reinstalled. We will see if I have to do something more.
 
I haven't got back to this problem since...
But reinstalling Surfshark has not solved the problem.

I'm digging deeper - but until I get it solved - is there an easy way to write a chron job to cleanse /tmp files on a schedule? Oh and - I have never written a chron job ... so beginner steps would be nice. But I know - Search is my friend.

@Condobloke - thanks for the article. I just had flatpak storage issues a while back. But todays /tmp files are not covered - unless I missed something.

Thanks again
 
Sure there is. But that could cause problems. You could be deleting files that are in use, with unforeseeable consequences.

I suggest looking for unnecessary files on your drive. For example, logrotate was archiving the log files. I almost ran out of inodes as a result.

df -i
 
Ah yes, it's SurfShark. Can you live without it? :)

Had to look it up. "Surfshark is a VPN service by a Lithuanian-founded cybersecurity company, now part of Nord Security but operating independently".
 
This is all I could find. ...

Reducing Surfshark's Space Usage:

Surfshark’s GUI may generate large temp files (e.g., in /tmp or ProgramData/Surfshark/Endpoint Protection SDK/temp).

Consider:

1. Using the CLI version instead of the GUI (for distros without GUI support?).

2. Disabling unnecessary features like split tunneling or ad-blocking (via settings).
 
I think I found the culprit.

I uninstalled Surfshark and the problem didn't go away.

I installed a cpu/memory/network monitor and spotted huge net traffic (Gnome extension tweak - simple system monitor). Found out it was Filen sync stuck on some syncs. Uninstalled that and the problem seems to have gone away... So far...

Thanks for the help
 
Filen, like other encryption apps, comes with its own unique dramas

You may ask yourself, is it really necessary?....is it worth the potential trouble?

Balance that against the 'worth' of the encrypted information.
 
I understand and don't disagree at all. But somehow I seem to chase "un-balance". Anything to make life a challenge and more difficult and I sign right up...

Ironically - I added Filen when Megasync was acting up. More for disaster preparedness. An uninstall/reinstall solved my problems and Mega. It has been working ever since. But I never uninstalled Filen - instead I felt doubly protected against disasters ;)... But uninstalled now - and all seems good.

Thanks again,
 


Members online


Latest posts

Top