Thanks for the advice. I usually always protect vars with double quotes, this doesn't help avoiding problems?




Or bluray images

Cleanup of /tmp sounds like a good idea, but when someone says to be careful *what* is cleaned from it, how do we know what to clean?

For instance...my /tmp has a SBo directory which has 13GB of directories/files. This is a *LOT* of space being used up. Is it safe to delete the SBo dir?

i think thats the stuff that is made when you use slackbuilds to compile apps, temps files, etc... if you have your pkgs in a safe place it should be ok to delete... not really sure.

I use the following in rc.6


# clean tmp of old and stale files
echo "Cleaning temporary files"
find /tmp -type f -mtime +5 -exec rm -f {} \;
find /var/tmp -type f -mtime +30 -exec rm -f {} \;


Can't remember where it came from but works well and keeps /tmp relatively small

Sure, but why would he not create the images on a disk based file system? Sequential file access will always outperform demand paging which does random I/O and sends your system into thrashing.

/tmp is meant to be used as transient workspace for running tasks. Anything that leaves stuff in /tmp when it ends is 'broken'. /var/tmp is intended to be used for more persistent though still non-permanent data. Unfortunately, very few people seem to be aware of this distinction, let alone disciplined enough to actually comply with this concept and use /var/tmp.

Of course, this doesn't mean that something can't put a huge amount of data in /tmp while still using it correctly (Richard's example of an intermediate .iso image being one example - though anything that is going to use a large amount of disk space like that really should be assigned it's own dedicated space so as not to impact the rest of the system and/or its users), but it's more common that a large amount of data collecting in /tmp is just a sign of abuse of the filesystem.

If the programs using /tmp have been correctly written, then in theory you should be able to remove the files in /tmp at any time - even while the programs are still running and it shouldn't cause a problem (because the program will still have an open file-descriptor for it). However, back in the real world, not everyone understands how /tmp is supposed to be used, and even those that do are often just too idle to make the effort to do it properly, so you roll the dice and take your chances.

3 members found this post helpful.

That something haven't happened to you doesn't mean it cannot happen to you in the future, or happen to other people.

Yes of course, I know tmpfs can be limited of 1GB, but please understand my frustration when I started compiling the very small code base of qemu, went to bed, and only find the next morning that qemu.SlackBuild terminated because /tmp is full. For compiling another of my daily software, 8GB temporary space is not much more than enough. So if you let me limit /tmp to 1GB then I will have to create a /tmp2 elsewhere anyway. Wired.

Actually I am using a 20GB tmpfs on /tmp, together with a 25GB swap partition. My /tmp consumption is almost always less than 1GB, but when it goes up to 10GB my programs will not break. They just slow down.

I can expect the bad thing to not happen, but I cannot be unprepared. I work with a computer, while you play with a computer. Therefore, we have different points of view.

Why not edit the SlackBuild to use your /home/user (or /root) directory instead? SlackBuilds don't have to use /tmp.
Again, why aren't you compiling stuff in your /home directory?
That's just silly.
Absolutely. In fact, I would recommend it. Files generated by sbopkg take a ton of space in /tmp. And none of them are used after it installs the packages it built.

Edit the SlackBuild? That's just silly. Why not export a different TMP environment variable for use by the SlackBuild?

I actually build software on tmpfs to minimize iowait time because in most (but not all!) cases the intermediate files are smaller than my main memory. (vm.swappiness also plays a role in it but that's another story.)

Do you mean $HOME and not /home? I guess you never looked into those SlackBuild scripts, or you wouldn't have suggested me to run them as normal user. On the other hand, if you meant to run SlackBuild as root but put the intermediate files under a normal user's $HOME, that not just silly, that's crazy.

Yes. Why don't you do that?
Hmmm.
Well I did also say /root... But you seem to have ignored that for some reason.

Regardless, I often edit out the 'root only' commands in a SlackBuild to get what I want as a regular user. And you don't have to use SlackBuild scripts for everything, you know...

^ I'm afraid to ask.

The point of xargs is (and has always been IIRC) to launch less processes. So if you have 5000 files and directories in /tmp, that commands launches 5000 rm processes, while with xargs maybe you can pass 256 arguments at a time, for example, or even more.

That said, this reminds me of a recent benchmark I read about in Hacker News which tried to find the fastest way to delete a million files, and find with xargs was actually slower in some cases than find with -delete.

http://linuxnote.net/jianingy/en/lin...-of-files.html

Not really. Let's say I populate a directory with two files named "foo" and "bar\nbaz", that is, "bar<newline>baz", and I have a script with the following contents:

Running the script yields:

I'm not making things up. I just tested this.

Abuse? Criminal offense? Seriously!
We were talking about /tmp usage comparable to the main memory size. As the main memory size is usually 0.1~1% of the disk size, so you mean filling up 0.1~1% of the disk space is just a sign of abuse?

Because I am no mathematician. I don't create a problem just for solving it.

Not really. I just wondered what /home has to do with SlackBuild. Even /usr/src is a better place to compile software than /root because it's bad practice to mount /root on a separate filesystem but it's the contrary for /usr/src.

Good to know you are a mathematician. I admire people with advanced brains.