SUSE / openSUSEThis Forum is for the discussion of Suse Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Do df -h and see what if any other filesystems you have. If /tmp were a separate filesystem then its files are not part of the issue but if it is not then its files would be. Similarly would be /var due to /var/tmp.
That would be the first place to look. Delete anything more than a day old . You can delete things newer than that but should use fuser or lsof to verify they are not currently in use by some application.
Another good place to check would /var/log - you may not have log rotation turned on and if so things like maillog and messages would grow until the end of time. You'd have to stop syslogd (and any other deamon using the specific log e.g. sendmail for maillog) then delete the log and create an empty one by simply doing "touch <logname>" then restart the daemons you'd stopped.
Do "find / -name core" and check out any core file it shows you. Typically these are memory dumps of programs that crashed for one reason or another. Do "file /pathto/core" on any you find to determine what they are. (Some things like Oracle actually create directories named "core" and you do NOT want to delete those.)
Also do a "find / -name *.tar" to find any tar bundles you may have on the system. Typically you can gain some space simply by compressing these with gzip (gzip file.tar). A lot of .tar files might be ungzipped .tar.gz files and if you have both the .tar and the .tar.gz you should just delete the .tar. If you unbundled the contents of one of these .tar or .tar.gz into a directory to do an install of something and still have the .tar or .tar.gz you might consider deleting the directory you unbundled to (assuming you just used that to do the install to another location rather than using it as the installed location itself).
Distribution: openSUSE, Raspbian, Slackware. Previous: MacOS, Red Hat, Coherent, Consensys SVR4.2, Tru64, Solaris
Posts: 2,785
Rep:
Quote:
Originally Posted by dYz
I have this minor problem that my "/" partition is almost full.
What other partitions/filesystem did you create when you went through the installation. If you have /tmp as part of "/", that's a candidate migrating to a separate filesystem though it really depends on how heavily /tmp is actually getting used. Also /var. If that's not been used as a mount point for a separate filesystem and /var is actually part of the root filesystem, you likely have a bunch of log files that are using the space. It's tough to tell without seeing your "df" output. If there are a lot of logs, some of the older ones may be deletable. At the very least you ought to consider compressing them with
Code:
gzip -9 somelogfile
or
Code:
bzip2 -9 somelogfile
Log files typically compress very well. (Of course, if they're no longer needed, removing them would free up the most disk space. )
If you have noticed that certain log files seem to be immense, check to see if an application has been set to log debugging information. Some applications -- databases and bind/named, for example -- can create a frightful amount of information when they've been configured to provide detailed debugging messages in the log.
You can determine which directories (or trees) are using the disk space by issuing:
Code:
cd /
du -sk *
You can ignore the output for any directories that are known to be mount points for other filesystems; they're not contributing to your root filesystem space problem.
Is it possible to post this information? (The "df" and the "du" output, that is.) It'd be easier to make a suggestion if we could see how your filesystems are laid out.
7356 bin
8304 boot
84 dev
29036 etc
9784280 home
74492 lib
16 lost+found
4 media
4 mnt
1344784 opt
du: kan ikke tilgå 'proc/4499/task/4499/fd/3': Ingen sådan fil eller filkatalog
du: kan ikke tilgå 'proc/4499/fd/4': Ingen sådan fil eller filkatalog
518817 proc
20636 root
12060 sbin
1340 srv
0 sys
40712 tmp
3832144 usr
1603312 var
Yep. Nearly everything's under a single "/" partition.
You wouldn't happen to have a extra IDE drive laying around, would ya?
Quote:
my "du -sk *" output:
Code:
7356 bin
8304 boot
84 dev
29036 etc
9784280 home
74492 lib
16 lost+found
4 media
4 mnt
1344784 opt
du: kan ikke tilgå 'proc/4499/task/4499/fd/3': Ingen sådan fil eller filkatalog
du: kan ikke tilgå 'proc/4499/fd/4': Ingen sådan fil eller filkatalog
518817 proc
20636 root
12060 sbin
1340 srv
0 sys
40712 tmp
3832144 usr
1603312 var
Well, none of the above looks out of the ordinary. You can, obviously, ignore the record for "home" as that's in a separate partition. "/var" would be the first place I'd look. If you cd into /var, you can repeat the "du" command and try to ferret out what directory tree is using the most space. Purging some of the bigger, rolled over log files (they usually have a .N suffix like ".0", ".1", etc.), particularly if they're older and you're sure you'll never need them, would be a likely place to begin cleaning up. Someone else already mentioned looking at logrotate to help you manage log files. Even if it's already] enabled, check into the settings for "logrotate" ( probably in "/etc/logrotate.conf"). You can configure it so that older log files are compressed automatically. That feature may not be turned on by default (at least on my system) but might be helpful for you.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.