delete all that is inside the /tmp folder

Hello

I would like to know if a problem will occur if I delete everything inside the /tmp folder

Thank you so much

It depends on when itis done. When the system is running and people are loged in, files that are in use could be deleted :(.

When you want to keep a clean /tmp, there are a few ways to do this.

=================================
For cleaning /tmp and /var/tmp at boot:

When there is not already a file /etc/tmpfiles.d/tmp.conf create it as a copy

cp /usr/lib/tmpfiles.d/tmp.conf /etc/tmpfiles.d/tmp.conf

Then change the lines

# Clear tmp directories separately, to make them easier to override
# SUSE policy: we don't clean those directories
d /tmp 1777 root root -
d /var/tmp 1777 root root -

into

# Clear tmp directories separately, to make them easier to override
# My policy: empty /tmp en /var/tmp.
D /tmp 1777 root root 1d
D /var/tmp 1777 root root 1d

See

man 5 tmpfiles.d

==================================
Another way to do this is to make /tmp a separate file system of type tmpfs.

tmpfs        /tmp    tmpfs    size=25%,uid=root,gid=root,mode=1777 0 0
 

The file system will be destroyed on shutdown and thus be emptied.
See

man 8 mount

specially the section: Mount options for tmpfs

Normally not.

Unless you use /tmp for storing important files of course… :wink:
There were large outcries from some users when suddenly /tmp was cleaned automatically in some 12.x version, it got disabled by default again because of that.

So maybe check at least if there are important files, some applications may be configured to use /tmp for “important” stuff e.g.

Files that are in use won’t get deleted really.
They will only be removed from the directory, the data will still be kept (as long as applications have the files open at least).

That’s not to say that some applications might not get confused or something (e.g. an application could close the file and then expect to be able to open it again, which would not be the case because it got deleted meanwhile). :wink:

Sometimes a short warning which gives a hint to what might go wrong is better IMHO then explaining until the last bit. And your last remark is covered by my expression “in use”, just an english expression, not to be confused with the technical term “opened file”.

Ok, but I only did this in reply to you.

Still, there should not be problems.
And in any case nothing that a reboot wouldn’t solve. :wink:

PS: your sugested change will have the same theoretical “problem”:

As it may delete the files while the system and applications are running.

I am fully aware on how Unix/Linux keeps count of the proceses that have a file open since about 40 years.

Well, having to reboot a system after a user encounters a failing application is a problem IMO.
Not only would it be reported as a problem, but the root cause would then be nailed down on a blundering system manager.

Ok, fine.
But then you have to admit that your statement was not fully correct… :wink:

Well, having to reboot a system after a user encounters a failing application is a problem IMO.
Not only would it be reported as a problem, but the root cause would then be nailed down on a blundering system manager.

It’s only a theoretical problem, and it would indeed be a bug (in the corresponding application) IMHO.

Also, a restart of the affected application should help anyway, a reboot would just make that implicit.

And as mentioned, your suggested way to automatically delete files has the same problem, but then it may happen randomly and not at the point the user/administrator decides explicitly to delete the files in /tmp.

But whatever.
I see no point in continuing this discussion really.

When I read

man 8 tmpfiles.d

I get the strong impression that this happens at boot and not randomly.

As I see it, it is the way systemd implements the cleaning of /tmp at boot (an old feature of many Unix/Lunux versions). This cleaning of /tmp is part of a wider implementation of “Configuration for creation, deletion and cleaning of volatile and temporary files” (as so many things im systemd try to cover everything).

I somehow doubt that, because it would be useless if you don’t reboot regularly.

The tmpfiles/dirs will be created at boot of course (if they don’t exist), but I don’t see any implication on a quick look that they will only be cleaned up on boot.

The old SUSE cron job (that was used before the switch to systemd and could be configured in /etc/sysconfig/) definitely ran regularly and not just on boot.
This is no longer relevant now of course, just a side-note, but systemd does have a tmpfiles-clean.timer that is active by default (because it is “static”):

wolfi@amiga:~/Desktop> systemctl status systemd-tmpfiles-clean.timer
● systemd-tmpfiles-clean.timer - Daily Cleanup of Temporary Directories
   Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-clean.timer; static; vendor preset: disabled)
   Active: active (waiting) since Wed 2018-01-31 07:48:36 CET; 5h 53min ago
     Docs: man:tmpfiles.d(5)
           man:systemd-tmpfiles(8)

Btw: I actually do remember a bug report about somebody not being able to run new applications in the graphical session anymore after some time/over night because they enabled automatic cleaning of /tmp, and sddm used to store the Xauthority files in /tmp IIRC… (that should be fixed meanwhile though) :wink:

Ir seems that since I visited the man page (and compiled my solution on how to clean /tmp on boot), things have developed further. Adding a ! to the command would make it only run at boot:

d! /tmp 1777 root root -
d! /var/tmp 1777 root root -

So your concern was shared by others and was met by implementing this.

BTW, it would be nice if the OP would not only tell what he wanted to do/know, but also why he wanted to do this. Then we could help him better. The old one: Describe the goal, not the step

On Wed, 31 Jan 2018 10:56:01 +0000, josemanoel wrote:

> Hello
>
> I would like to know if a problem will occur if I delete everything
> inside the /tmp folder
>
> Thank you so much

I use tmpwatch to clean /tmp on occasion - you can tell it how many hours
files need to have been untouched as a qualifier for deletion.

Handy tool.

Jim


Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

That sounds like the venerable

 # find /tmp/ -mtime *n*  -delete && find /var/tmp/ -mtime *n* -delete  

which can also be run as a cron job at boot or any specified time.

Thank you all
Very well answered question

… actually, I regularly delete all the contents of the /tmp and /var/tmp directories manually from a root console, often even when the user is busy on something, once a week when I do my updates and backups. I have never run into any problems doing this in all these years.

I wonder if I have just been “lucky”, or if it is just not a crucial threat to anything.

It depends very much on what the user is doing. When, in one and the same session, the user is creating a file in /tmp, then uses it (e.g. running an application on i), edits it and reuses it again (same application with edited data), and so on, the user would expect the file to be there all the time during the session because there is no reboot during his session (very naturally). And when he handles his “testing” in this way, and root removes it, it will be lost at the first close (ending the editor or the application). Not what the user expects.