A small scare: always check your available storage space

sombragris · 08-07-2017, 09:02 AM

Today I got a little scare from my system. I write it here hoping it might be useful to others.

I usually work with LibreOffice, and my documents are in a small external hard drive, since my laptop offers very little storage space.

I needed to open a document because I had to make a quick, but important, change. Upon selecting the file to be opened, LibreOffice tells me that the file is corrupted, and if I wanted to repair it. I selected yes, and then LibreOffice told me that it was unsuccessful in its attempt to repair the file so it could not open it. Upon clicking OK to that message, another message appeared telling me "General Error" (how informative).

Suddenly, more and more files began displaying the same behavior. In my mind, the only explanation for this was a general disk failure; which is very odd, since the hard drive has about 2 years of use in generally good working environments. I began to freak out.

I thought: "Maybe this is because the USB ports were not properly initialized" (I was deceiving myself; meanwhile, my USB keyboard and mouse were working flawlessly). So, I chose to power cycle the computer. And behold, the culprit showed up.

After logging in into Plasma 5, the desktop aborted itself and a message in the ancient Athena toolkit showed telling me: "Plasma cannot run. Insufficient space in /tmp".

There it was! Prior to my attempt to open my document, I was compiling a large package from SBo. And yesterday I compiled another. The compile files were all hoarding space in /tmp/SBo/.

So,

Code:

rm -rf /tmp/SBo/

...and I was able to boot into Plasma. A minute later, my document opened up without a complaint.

Moral of the story: make sure you have free space in /tmp before making any decision! Indeed; low disk space generates all kinds of weird errors, and many application error messages are extremely opaque and noninformative and therefore confusing. I decided to write this up so it might help any fellow Slacker who could be affected by something similar.

upnort · 08-07-2017, 09:52 AM

I add the following to every build script I use:

Code:

# cleanup
rm -rf $TMP/$PRGNAM*
rm -rf $PKG

I wish this was the default in all build scripts.

In case I want to debug the build process I temporarily comment out the cleanup commands. Possibly a nicer way of doing this would be to add the cleanup commands to the build script but pass a CLEANUP=NO environment variable when wanting not to delete the temp files.

Perhaps the SBo maintainers will consider something like this for the next official release. There are lots of threads in this forum about the "problem."

I assign the TEMP/TMP/TMPDIR environment variables to /tmp and I map /tmp to tmpfs.

orbea · 08-07-2017, 10:01 AM

That would be a pretty terrible default. Just yesterday I required /tmp/SBo/$PRGNAM-$VERSION/config.log to potentially help debug a build issue.

sombragris · 08-07-2017, 10:27 AM

Quote:

Originally Posted by upnort

Perhaps the SBo maintainers will consider something like this for the next official release. There are lots of threads in this forum about the "problem."

Maybe, but I'm not really trying to change SBo's behavior. The blame here, if any, lies with any application who throws cryptic error messages and weird behavior upon a problem which is nothing out of the ordinary, such as full disk storage. They really can do better.

montagdude · 08-07-2017, 10:28 AM

sbopkg has an option to clean up /tmp/SBo after running the build script. I use my own script instead of sbopkg, but I set it up to have a similar option. 95% of the time I want those files to be deleted anyway, and in the 5% of the time where I want to look at the config.log or something, I can just build again with that option disabled.

Another option, if you have enough RAM, is to mount /tmp as tmpfs. That way, it at least gets cleared when you reboot. Maybe helpful or not, depending on how often you reboot.

montagdude · 08-07-2017, 10:49 AM

I forgot to mention one more option: change the TMP environment variable (used by the SlackBuild scripts) to point somewhere with plenty of space, like /home/SBo. That way you can avoid filling up /tmp without automatically cleaning up the build area.

Richard Cranium · 08-07-2017, 11:53 AM

If your shell script was named barf.sh, you can do something like...

Code:

#!/bin/bash
TMP=`mktemp -t barf.sh.XXXXXX`
trap "rm $TMP* 2>/dev/null" EXIT

...which will clean up when the script exits. Comment out the trap line if you need to debug.

pan64 · 08-07-2017, 11:58 AM

(If it wasn't Slackware)
I used to create a ramdisk for /tmp and I will automatically lost everything "stored" inside /tmp on every boot.

55020 · 08-07-2017, 01:10 PM

Quote:

Originally Posted by montagdude

sbopkg has an option to clean up /tmp/SBo after running the build script. I use my own script instead of sbopkg, but I set it up to have a similar option.

And that's the right answer

If you're building with an automated tool, set it up how you like.

If you're not building with an automated tool, you're probably the kind of person who appreciates the minimalist aesthetic of the SBo templates.

coralfang · 08-07-2017, 03:51 PM

If you have plenty of ram, mount /tmp as tmpfs as a workaround. Although if you are building a large program you could end up swapping to disk in the event you run out of ram.

/etc/fstab

Code:

tmpfs            /tmp             tmpfs size=4G,nodev,nosuid    0	   0

55020 · 08-07-2017, 04:41 PM

Quote:

Originally Posted by upnort

I add the following to every build script I use:

Code:

# cleanup
rm -rf $TMP/$PRGNAM*
rm -rf $PKG

I wish this was the default in all build scripts.

*Why*? Save yourself a ton of work like this:

Code:

#!/bin/sh

slackbuildpath="$1"
if [ -z "$slackbuildpath" ]; then
  echo "$0: Usage: $0 SlackBuildPath" >&2
  exit 1
elif [ ! -f "$slackbuildpath" ]; then
  echo "$0: $slackbuildpath: No such file." >&2
  exit 1
fi
prgnam=$(basename "$slackbuildpath" .SlackBuild)
dirnam=$(dirname "$slackbuildpath")

cleanup=y
[ "${CLEANUP:-yes}" = 'no' ] && cleanup=n
[ "$2" = '--nocleanup' ] && cleanup=n

export TMP=${TMP:-/tmp/SBo}

cd "${dirnam}"
./"${prgnam}".SlackBuild
savedstatus=$?

[ "$cleanup" = 'y' ] && rm -rf "$TMP/${prgnam}"* "$TMP/package-${prgnam}"*

exit $savedstatus

Put that at e.g. /usr/local/sbin/runsb and use your time for something better than spoiling perfectly good SlackBuilds

Didier Spaier · 08-07-2017, 05:13 PM

If I understand well, Eduardo (aka the OP) has a separate partition for /tmp. I live without that.

I generally set TMP and OUTPUT to $CWD (I can as I run the SlackBuilds with fakeroot). Just a personal preference, I prefer to keep everything in the same place. This way I can quickly check the package's content then remove it as well as the source dir.

But I often find a lot of space used by .cache/{mozilla,thunderbird} among others; not to mention akonadi. so SBo is far to be the only culprit, here at least.

Anyway, not wasting space is the duty of the person between the chair and the keyboard, rather than that of a software

Just my 2 ¢, of course.

enorbet · 08-08-2017, 02:18 PM

Simple Solution = Larger Hard Drives are Cheap

sombragris · 08-11-2017, 02:36 PM

Quote:

Originally Posted by enorbet

Simple Solution = Larger Hard Drives are Cheap

Not that simple. My box is a ultrabook (not much hackable/upgradeable) and has a SSD with limited size. While I can attach any storage media, I have to be wise in allocating space for system resources.

sombragris · 08-11-2017, 02:50 PM

Quote:

Originally Posted by Didier Spaier

If I understand well, Eduardo (aka the OP) has a separate partition for /tmp. I live without that.

Not exactly that, but I have /home in a partition other than the main system partition.

Quote:

Originally Posted by Didier Spaier

Anyway, not wasting space is the duty of the person between the chair and the keyboard, rather than that of a software

Just my 2 ¢, of course.

I don't think you would condone useless bloat by any software; but well, we have Emacs anyway...

Well, on my point: of course the user has to monitor his/her available disk space. But, in any case, a partition with zero space left is occassion for all kinds of weird breakage with arcane messages...