What files are safe to remove from /usr

[TroN-0074]

Hi all.

After a doing a portupgrade -a my /usr directory is full. So I was wondering what files are safe to remove from there. Originally my /usr directory is 8.0 GB big. I can't see what could be so big that is taking all that space from there.

I will appreciate some advices. Thank you.

 

[throAU]

It depends what you need. I'd limit your deletions to stuff under /usr/local (as none of that is the base system) but be aware if the box is doing actual work, you may break things.

Also, use pkg_delete or your other port/package manager of choice rather than simply getting happy with rm as you'll probably corrupt the package database sooner or later.

Also, check out the following locations for space to free:
/usr/home
Dotfiles in your home directory (caches, etc - apps you remote may have left cruft behind there).

I'd also do a clean of the /usr/ports directory and the /usr/obj directory.

If you're planning on building packages from source, rather than using pkg_add -r to install pre-built, 8 GB for /usr is a bit small IMHO. I ran a box out of space that had a 20-30gb /usr the other day (by rebuilding from source) and all it was doing is basic SMTP and anti-spam stuff.

 

[bbzz]

That's like using bandage to try cure cancer; you won't gain much and you haven't solved anything. It shouldn't be hard to backup, repartition and recreate again.

p.s. check /usr/src, /usr/obj, /usr/ports/packages, /usr/ports/distfiles

 

[TroN-0074]

Thank you I don't have a /usr/home slice during installation I created it under /home/user/

What I am wondering is if I do a

# pkg_delete -a

I will gain all that space back from /usr
I think I will have to re install all my apps using

# pkg_add -r

I will really appreciate more advices. Thank you.

 

[bbzz]

Well you can do it the "linux bumblebee" way with

sudo rm -rf /usr/*

That should free up some space.

 

[throAU]

^ don't do that.

 

[jb_fvwm2]

cd /usr/ports/distfiles
gnuls -oSr | sort -k 4 | sort -k 8

You'd want to pipe it to less, /lookat/... you may find large distfiles that are duplicates... /gnuls/ is a port. No time to find a native solution this year.

 

[TroN-0074]

I must admit I am quite desperate to solve this problem. My whole system is only 26GB I am using 2GB for Swap and 10GB for /home the rest is for the OS. I would like not having to reinstall but I am tempted to remove all applications. Will I get back my space if I do that? Or will I end up with lots of orphan files from removed applications.
Please advice. Thank you.

 

[bbzz]

Why don't you dump your filesystems? If you don't have another drive you can dump 26GB on 5 DVDs. Recreate partitions, and then restore. This is really the best option and should be quite straight forward.

 

[wblock@]

I must admit I am quite desperate to solve this problem. My whole system is only 26GB I am using 2GB for Swap and 10GB for /home the rest is for the OS. I would like not having to re install but I am tempted to remove all applications. Will I get back my space if I do that? Or will I end up with lots of orphan files from removed applications.
Please advice. Thank you.

Splitting off /home like that was a premature optimization.

How much room is in /usr? Use du(1) to find out what is taking up space:
# du -xhd1 /usr

As bbzz posted in #3, some directories can be removed to regain space because they can be easily recreated. My guess is that port distfiles are the biggest problem.

 

[jb_fvwm2]

cd /usr/ports/distfiles
gnuls -oSr | sort -k 4 | sort -k 8

You'd want to pipe it to less, /lookat/... you may find large distfiles that are duplicates... /gnuls/ is a port. No time to find a native solution this year.

Found a command that might make it easier, by chance today, one less port.

ls -lac /usr/ports/distfiles | tee -a /usr/bigfile.txt
ls -lac /usr/ports/distfiles/gnome2 | tee -a /usr/bigfile.txt
ls -lac /usr/ports/distfiles/KDE | tee -a /usr/bigfile.txt
ls -lac /usr/ports/distfiles/python | tee -a /usr/bigfile.txt 
...
cat /usr/bigfile.txt | sort -k 12 | lookat (less...) 
#hopefully correct, copied it down hurriedly.

You may use it on other directories you suspect large duplicate files in, maybe...
No time to test if that works on

 find /usr -type d | tee -a /usr/bigfile.txt

No reason to run these if you've deleted distfiles as below...

 

[TroN-0074]

Thank you I removed the distfiles directory by issuing

# rm -r /usr/ports/distfiles/*

Then just to make sure I also did

portsclean -CDD

and if it wasnt enought I also ran

# cd /usr/ports && make clean

Now this is how my /usr directory looks like

2.0K /usr/.snap
31M /usr/bin
18M /usr/include
28M /usr/lib
92K /usr/libdata
18M /usr/libexec
3.8G /usr/local
19M /usr/sbin
37M /usr/share
2.0K /usr/src
702M /usr/ports
2.0K /usr/compat
2.0K /usr/games
2.0k /usr/obj
4.7G /usr

Can I trim it down more? As you can see if I have to upgrade in few more weeks I will run into trouble again filling up /usr Or is there a better way?
I will appreciate your inputs. Thank you.

 

[jb_fvwm2]

Put distfiles on a thumbdrive?

mount -t ufs /dev/da0 /mnt
mkdir -p /mnt/distfiles
umount /mnt
mount -t ufs -o union /dev/da0 /usr/ports

You can use this method even to installworld from a thumbdrive (given that there may not be enough space on that machine to buildworld...) , saving greater than a gigabyte from moving it [( /usr/src /usr/obj from /usr (I put it in another post...probably in the off-topic section.)
If I've no typos in the information above, that might be one way.
....
Only found this method several weeks ago, after lengthy testing, search engines, etc.

 

[throAU]

Considered moving the entirety of /usr/ports using the above method?

You really don't have enough space allocated to /usr to comfortably upgrade/install things from source, IMHO - given that you have 3.8gb of stuff installed under /usr/local.

I reckon it's time to either add more storage and mount under /usr somewhere, re-structure (reinstall) your filesystem, or go to binary distribution.

 

[jb_fvwm2]

Warning...

Put distfiles on a thumbdrive?

mount -t ufs /dev/da0 /mnt
mkdir -p /mnt/distfiles
umount /mnt
mount -t ufs -o union /dev/da0 /usr/ports

You can use this method even to installworld from a thumbdrive (given that there may not be enough space on that machine to buildworld...) , saving greater than a gigabyte from moving it [( /usr/src /usr/obj from /usr (I put it in another post...probably in the off-topic section.)
If I've no typos in the information above, that might be one way.
....
Only found this method several weeks ago, after lengthy testing, search engines, etc.

*warning* Copying data to (vs from) a point on a thumbdrive (say, /usr/src > /mnt/src may probably hang the machine. I'd use

rsync... bwlimit=1000

(search the forums for the long command line). Otherwise, and/or, if it results
in an unclean UFS filesystem on the /dev/da0, fsck may refuse to work. I found since
yesterday that

fsck_ffs /dev/da0

will work where fsck won't, and have labelled at least one
thumbdrive (tape label) accordingly.
....
So those three points make it a not-feasible > feasible solution IMHO.

 

[Beeblebrox]

• Are you sure that everything under the source (/src) is valid? You might have old libraries (see Makefile in /usr/src):
  # cd /usr/src && make delete-old-libs
• install ports-mgmt/pkg_cutleaves and run it. Maybe you have left over binaries from deleted ports which you had installed at one time. This will clean those left-overs out and that's the only way you can be sure "what files are safe to remove from there"
• Not a huge improvement but you could trim-down the space that world takes. Modify /etc/src.conf and build your new world as explained here - could save about 150K.

 

[paulbeard]

cruft under /usr/local

It depends what you need. I'd limit your deletions to stuff under /usr/local (as none of that is the base system)

Found this thread after discovering a couple of problems. One, that at some point, port[upgrade|master] had upgraded ports in /usr/local without using bin, sbin, include, libexec, info, etc., and that two, that I have a lot of what look to be duplicated files from /usr/lib in /usr/local. They're not identical, so I'm not sure what they are or how they got there. A lot of them are links to files in /usr/lib, so that's OK. But .o files (crt1.o, gcrt1.o, etc.) don't seem like they belong there.

The ports shambles is almost cleaned up, after a lot of fumbling around. Reinstalling from scratch is almost always the best solution, time-consuming as it is. I am doing a full kernel/world build now in hopes of finding out of these files in /usr/local belong there. I am operating under the assumption that if they are not touched with today's date (and their counterparts in /usr/local are), that they are cruft.

Any idea what caused this?

 

[wblock@]

Found this thread after discovering a couple of problems. One, that at some point, port[upgrade|master] had upgraded ports in /usr/local without using bin, sbin, include, libexec, info, &c,

I don't understand what you are saying there.

and that two, that I have a lot of what look to be duplicated files from /usr/lib in /usr/local. They're not identical, so I'm not sure what they are or how they got there. A lot of them are links to files in /usr/lib, so that's OK. But .o files (crt1.o, gcrt1.o, &c.) don't seem like they belong there.

There are typically directories of the same name in /usr/local. That is where user-installed applications go. So there will be a /usr/local/bin with different contents than the system /bin.

The ports shambles is almost cleaned up, after a lot of fumbling around. Reinstalling from scratch is almost always the best solution, time-consuming as it is.

I disagree. Reinstalling from scratch often papers over the problem without finding and fixing the cause. So it will happen again.

I am doing a full kernel/world build now in hopes of finding out of these files in /usr/local belong there. I am operating under the assumption that if they are not touched with today's date (and their counterparts in /usr/local are), that they are cruft.

hier(7) shows the standard file hierarchy. Please see that before deleting files in /usr/local.

 

[paulbeard]

I don't understand what you are saying there.



There are typically directories of the same name in /usr/local. That is where user-installed applications go. So there will be a /usr/local/bin with different contents than the system /bin.

Yes, I know about that. What I found was that files that should have been installed in /usr/local/bin/ or sbin or libexec were installed in /usr/local without the last part of the hierarchy.

I disagree. Reinstalling from scratch often papers over the problem without finding and fixing the cause. So it will happen again.

I would like to know the cause. But in the meantime, I need to clean up the mess.

hier(7) shows the standard file hierarchy. Please see that before deleting files in /usr/local.

They should never have been installed directly in /usr/local: that's the problem. I have a cloned copy of the filesystem as it was with lots of *.so files that should be in /usr/local/lib, etc. that were installed in the wrong place. These are not one-off installations of things that I couldn't find in the ports tree: I'm talking about libpng and too many others to cite. They all share a common date so something went wrong on August 31 on this system. I may never know what that was but for now, I just want to be sure I have everything cleaned up.

So am I given to understand that I should not have duplicated files in /usr/lib and /usr/local? It reads to me like system files reside in /usr/lib or /lib and that /usr/local is for site or host-specific files. If that's the case, this seems odd.

for i in *.so.[0-9]; do if [ -e ../lib/$i ]; then ls -l $i ../lib/$i; fi; done
-r--r--r--  1 root  wheel  260812 May  6 07:05 ../lib/libarchive.so.5
-r--r--r--  1 root  wheel  260812 Aug 31  2012 libarchive.so.5
-r--r--r--  1 root  wheel  16424 May  6 07:05 ../lib/libauditd.so.5
-r--r--r--  1 root  wheel  16424 Aug 31  2012 libauditd.so.5
-r--r--r--  1 root  wheel  15424 May  6 07:05 ../lib/libbluetooth.so.4
-r--r--r--  1 root  wheel  15424 Aug 31  2012 libbluetooth.so.4
-r--r--r--  1 root  wheel  96640 May  6 07:04 ../lib/libbsm.so.3
-r--r--r--  1 root  wheel  96640 Aug 31  2012 libbsm.so.3
-r--r--r--  1 root  wheel  66992 May  6 07:05 ../lib/libbz2.so.4
-r--r--r--  1 root  wheel  66992 Aug 31  2012 libbz2.so.4
-r--r--r--  1 root  wheel  5916 May  6 07:05 ../lib/libcalendar.so.5
-r--r--r--  1 root  wheel  5916 Aug 31  2012 libcalendar.so.5

Note the August 31 timestamp. I feel pretty confident none of those files belong there.

The mess where the final piece of the path /usr/local/ lib, include, bin, sbin was missing I have cleared up. I'm sorry but I don't see any other reliable way to ensure that a port in installed properly, other than to install it from source. If a file is damaged or lost, how else would you replace it? Yes, a backup is fine but how reliable is it?

 

[wblock@]

The key question is "what happened?" If you can't keep it from happening again, fixing it manually is not going to help.

It looks like maybe a restore(8) was done into the wrong directory.

The last question is easy to answer: a backup that isn't reliable is not very useful. But I don't understand how that relates to the rest of this.

 

[ShelLuser]

Yes, I know about that. What I found was that files that should have been installed in /usr/local/bin/ or sbin or libexec were installed in /usr/local without the last part of the hierarchy.

Just so that we're fully clear on this: so files which should have been installed in /usr/local/bin ended up in /usr/local?

Can you give any (specific) names of ports where this happened? Also: did you by any chance override certain compile flags or have you (drastically) changed the /etc/make.conf file by any chance?

I'm talking about libpng and too many others to cite. They all share a common date so something went wrong on August 31 on this system. I may never know what that was but for now, I just want to be sure I have everything cleaned up.

That doesn't tell us very much:

root@smtp2:/usr/ports #make search name=libpng | grep Port
Port:   fpc-libpng-2.6.2
Port:   gstreamer-plugins-libpng-0.10.31,3
Port:   graphics/ruby-libpng

It would be helpful if you could mention some other names where things went wrong. And also how you installed those exactly. Also note that the paste you did above also doesn't tell us much since you're not sharing from which directory you ran that command. I'm assuming /usr/local but when trying to solve problems the first thing not to do is to make or use assumptions.

I'm sorry but I don't see any other reliable way to ensure that a port in installed properly, other than to install it from source.

That makes absolutely no sense to me, at all. What do you mean with "install from source"?

First the obvious; when installing a port you are using source code to install it, unless of course you're resorting to binary packages. But that wouldn't really classify as installing a port in my opinion.

Second: after a port is installed it will get registered with your package management system. As such its pretty easy to check if the installation went right. For example, after installing sysutils/screen its very easy to determine what happened:

smtp2:/home/peter $ pkg_info -L screen*
Information for screen-4.0.3_14:

Files:
/usr/local/man/man1/screen.1.gz
/usr/local/bin/screen
/usr/local/share/screen/utf8encodings/01
/usr/local/share/screen/utf8encodings/02
...

Thus I can immediately determine that it installed the binary in /usr/local/bin, some other files in /usr/local/share/screen and so on...

Would my assumption be correct that you didn't install the port(s) using the common method of running # make install clean within the ports directory, but instead used other ways to install them?

Because that would sure explain a lot.

 

[paulbeard]

The key question is "what happened?" If you can't keep it from happening again, fixing it manually is not going to help.

It looks like maybe a restore(8) was done into the wrong directory.

The last question is easy to answer: a backup that isn't reliable is not very useful. But I don't understand how that relates to the rest of this.

And not much of what I have read in response to my question goes to answering it. I have no idea what happened. I suspect something to do with a port upgrade cycle but I don't experiment with make.conf or esoteric flags on the command line. And no, I don't use

pkg_info -L

to check that it worked.

I don't use restore, though I do dump each filesystem to a spare disk weekly.

The question was quite simple: do any files or hierarchies not specifically listed in the hier man page as clarified by wblock@;219262 belong in /usr/local and should there be duplicates of files that appear in /usr/lib?

And I don't even understand this question:

What do you mean with "install from source"?

What else could it mean? It means "make install clean" or some variant thereof. pkg-add -rv in a pinch but rarely.

I don't know what that snippet of code around libpng has to do with anything: I didn't post it. If you want a list of all the files that were erroneously installed, here's some of it:

  Length      Date    Time    Name
---------  ---------- -----   ----
     2284  08-31-2012 16:33   Scrt1.o
     1988  08-31-2012 16:33   crt1.o
     1548  08-31-2012 16:34   crtbegin.o
     2072  08-31-2012 16:34   crtbeginS.o
     1868  08-31-2012 16:34   crtbeginT.o
     1244  08-31-2012 16:34   crtend.o
     1432  08-31-2012 16:34   crtendS.o
      892  08-31-2012 16:33   crti.o
      848  08-31-2012 16:33   crtn.o
        0  08-31-2012 16:34   dtrace/
        0  08-31-2012 16:35   engines/
     2157  08-31-2012 16:33   gcrt1.o
     8495  08-31-2012 16:35   kgzldr.o
    44610  08-31-2012 16:34   libalias.a
     2488  08-31-2012 16:34   libalias_cuseeme.a
     2654  08-31-2012 16:34   libalias_cuseeme_p.a
     1968  08-31-2012 16:34   libalias_dummy.a
     2016  08-31-2012 16:34   libalias_dummy_p.a
     7584  08-31-2012 16:34   libalias_ftp.a
     7728  08-31-2012 16:34   libalias_ftp_p.a
     4438  08-31-2012 16:34   libalias_irc.a
     4486  08-31-2012 16:34   libalias_irc_p.a
     4620  08-31-2012 16:34   libalias_nbt.a
     4844  08-31-2012 16:34   libalias_nbt_p.a
    46914  08-31-2012 16:34   libalias_p.a
     4204  08-31-2012 16:34   libalias_pptp.a
     4356  08-31-2012 16:34   libalias_pptp_p.a
     2592  08-31-2012 16:34   libalias_skinny.a
     2640  08-31-2012 16:34   libalias_skinny_p.a
     5580  08-31-2012 16:34   libalias_smedia.a
     5708  08-31-2012 16:34   libalias_smedia_p.a

The suggestion these files were installed by hand or outside the ports system, either through

make install

from the port directory or using

postmaster/portupgrade

, is keenly resented. I never have any need to do that.

The best guess I can make is that pkgng, for the short time I tried it, wasn't honoring the correct prefix and I did find some things weren't going as expected. So I stopped using it. I may have filed a PR on in. But I'm not clear on when that was.

 

[throAU]

The ports shambles is almost cleaned up, after a lot of fumbling around. Reinstalling from scratch is almost always the best solution, time-consuming as it is. I am doing a full kernel/world build now in hopes of finding out of these files in /usr/local belong there. I am operating under the assumption that if they are not touched with today's date (and their counterparts in /usr/local are), that they are cruft.

Any idea what caused this?

You are aware that anything not part of the base system WILL go under /usr/local by design, right?

The way FreeBSD works, the /usr/bin, /usr/lib, etc. directories are for BASE only...

 

[wblock@]

There are still so few details it's impossible for me to get a handle on this, so I'm just going to add a couple of points:

pkg_info -W [i]filename[/i] will show which package installed the file. Use full paths. That's for the base system. If you have converted to PKGNG, I think the equivalent is pkg which. PKGNG is not a pick-and-choose thing, if you switched, converting back is not a minor thing.