Which directories of a Raspbian installation can be deleted so that disk space is freed, but Raspbian is still able to boot onto desktop.

Backstory: I recorded with Audacity and forgot to turn recording off. So Audacity filled the whole SD card with silence and crashed. The Raspberry Pi does not boot onto desktop anymore, but I can access via SSH. So I hope to recover the session, but I need the Raspi to safely boot onto desktop again, therefore trying to recover a little space on the card.

  • How about inserting an USB stick 32 or 64 GB and copy the recording to it? Or copy it to another computer via network? – ott-- Sep 22 '16 at 17:53
  • Sounds like that should be reported as a bug to Debian. As there should be a mechanism to prevent this from ever happening, preventing boot because no free space. – Piotr Kula Sep 22 '16 at 18:01
  • 1
    @ppumkin It hasn't actually prevented boot; note he can still SSH in. It wouldn't be a bug, since it is expected behaviour. The filesystem should have 5% reserved for superuser purposes, which is why it can still boot and sshd still works; this means root can still log in and fix the problem. It won't make any difference to say, "We'll reserve this much of the filesystem for Bob so Bob can use it after Bob has used everything else Bob could use" -- once Bob's used all the space Bob could use first Bob will just use the space Bob can now use second. – goldilocks Sep 22 '16 at 20:04
  • Ahh right. Yes. It just X cannot start because it cant create swap? OK, that is how I understood that and thought it was bug because I misread the question :) Thanks – Piotr Kula Sep 22 '16 at 20:06
  • It's not about about swap, swap is for overflow from RAM. It's because the GUI desktop makes use of various little files on disk. E.g., the basic X server writes a ~/.Xauthority file as your user. It's only a handful of bytes but more than zero (and the fs uses 4K blocks anyway). – goldilocks Sep 22 '16 at 20:10

System directories don't exist for no reason, so don't start deleting them willy-nilly.

If you did this as user pi, chances are the data is in /home/pi somewhere, but sometimes applications will also use /tmp as it is world writable, or somewhere in /var if they have a writable location there.1 Commonly /tmp is actually a small, in memory directory (meaning it won't hold much and does not persist across boots) but I believe this is not the case by default on current versions of Raspbian (there are a few similar things though; you can check for such directories with mount | grep "^tmpfs" -- but these are obviously not the problem here).

A good tool for finding this kind of thing is du; this will give you per directory totals for a tree, e.g.:

> du -h /home/pi/temp
11.4M   /home/pi/temp/bearPics/candid_poses
19M     /home/pi/temp/bearPics
172K    /home/pi/temp/foobarTutorial
9.0M    /home/pi/temp/sunshine
28M     /home/pi/temp/ 

The -h provides more "human" digestible numbers (with units). Here you can see /home/pi/temp contains a total of 28 MB, most of it in bearPics, most of that in bearPics/candid_poses.

With large trees, it may be easier to use du -h -d 1, where the -d 1 means to show just 1 level deep; you can then analyze individual subdirectories from there. If you want to get really fancy (thanks stevieb from comments below):

 du -h /home/pi | sort -n -r | head -n 10

Will show you the top 10 largest directories in descending order; logically the top one will be /home/pi, since it includes everything inside.

Don't try this on / as it will take a long time. You can try it on /home/pi, which will probably give you a long list (somewhere -d 1 might help) but the last line is always the grand total, meaning it is easy to tell whether this is the place or not.

If not check /var and /tmp. There is more information on du in man du.

1. If it is outside of /home, don't delete the actual directory when you find it unless it is owned by the user whose data it contains; just delete the fat data files inside. Otherwise the application may not be able to recreate the (possibly system wide) data directory when run as a normal user.

| improve this answer | |
  • 1
    another piece you may want to add is run a lsof | grep -i deleted. Any large ones in there can be safely deleted, as they are simply files that were deleted by processes, but the process may still be running. I can't remember if lsof is installed by default, but a sudo apt-get install lsof will fix that – stevieb Sep 22 '16 at 13:28
  • 2
    another useful trick is to list files, and sort by size: du -h /home/pi | sort -n -r | head -n 10. That'll show the 10 largest files, by size in descending order – stevieb Sep 22 '16 at 13:36
  • @DmitryGrigoryev: If they show up with lsof as deleted, they are already flagged for deletion, but have not yet been removed from disk because the process that deleted them has not yet freed them. This problem is very common with things like web servers, where they delete their own large log files, but aren't freed from disk yet because the process hasn't yet been restarted since the delete. – stevieb Sep 22 '16 at 14:05
  • @stevieb The OP obviously rebooted several times after the crash, so lsof is unlikely to be useful. – Dmitry Grigoryev Sep 22 '16 at 14:06
  • 1
    Also useful for a few mb of disk space: apt-get clean – Ferrybig Sep 29 '16 at 13:33

According to documentation, Audacity saves its files in /var/tmp/audacity-<your username>. That should be the first candidate for cleanup.

| improve this answer | |
  • 1
    I may be wrong, but I believe the OP wants to keep those files to attempt to restore/recover the Audacity session after access to the UI is possible. – stevieb Sep 22 '16 at 18:19
  • 1
    @stevieb >_< Yeah missed that the first time. However in that case, if the card has been filled up with application data, it is crazy to start deleting system stuff "temporarily" to get the system to do a GUI boot; either other user stuff should be deleted, or, since the OP can still use SSH, transfer the Audacity stuff off that way. Trying to make it useful on the pi itself is a bit of a lost cause. – goldilocks Sep 22 '16 at 19:58
  • I'm not sure, didn't he say Audacity recoded silence? In any case, read "cleanup" as "copy those files somewhere if needed, and remove them from SD card" – Dmitry Grigoryev Sep 23 '16 at 7:36

While strictly not directories as asked in the question, I will answer with the understanding that recovering some free disk space is the intent. Depending on how many packages' debs have been cached, you could gain nothing, something or a lot of disk space using apt-get autoclean. this thread has some relevant discussion on the topic. Be sure read and understand what the various options apt-get supports before executing the commands.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.