[opensuse] Running slow, / full
![](https://seccdn.libravatar.org/avatar/450b2e967219e620803a8b9e3c672e6e.jpg?s=120&d=mm&r=g)
My system has started running very slow, and the root directory is reported as having no free space. I've found a file /proc/kcore which is the probable culprit, being about 1000MB, with today's date, but even root is not allowed to move or delete this file. My system looks like this: Device Size Mount point Free sda2 965.1MB / 0B sda3 60.8MB /boot 46.8MB sda5 9.8GB /usr 4.9GB sda6 2.0GB /var 1.2GB sda7 2.0GB /opt 906.3MB sda8 1011.4MB /tmp 926.4MB sda9 257.3GB /home 154.1GB I've been downloading openSUSE 11.0 Alpha1, via ktorrent for the past 24 hours, but other than that I'm only doing what I always do - read email, news, browse the web, play music. -- Bob openSUSE 10.3, Kernel 2.6.22.13-0.3-default, KDE 3.5.8 Intel Celeron 2.53GB, 2GB DDR RAM, nVidia GeForce 7600GS -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/c18a749dda699514c262030be9e0ded9.jpg?s=120&d=mm&r=g)
On Jan 28, 2008 10:15 AM, Bob <linux@barrowhillfarm.org.uk> wrote:
My system has started running very slow, and the root directory is reported as having no free space. I've found a file /proc/kcore which is the probable culprit, being about 1000MB, with today's date, but even root is not allowed to move or delete this file.
My system looks like this:
Device Size Mount point Free sda2 965.1MB / 0B sda3 60.8MB /boot 46.8MB sda5 9.8GB /usr 4.9GB sda6 2.0GB /var 1.2GB sda7 2.0GB /opt 906.3MB sda8 1011.4MB /tmp 926.4MB sda9 257.3GB /home 154.1GB
/proc is virtual file system, which resides in memory, not on disk. Even some files are not actually in memory, but when you read them, you actually receive information from the kernel. In your case, read here for /proc/kcore: <http://www.unixguide.net/linux/faq/04.16.shtml> Run the command "df" to see the how your partitions are filled in. Run "top" to see which process consumes more resources. Note, that if you run firefox for several days w/o stopping it, it may eat a lot of resources. Cheers -- Svetoslav Milenov (Sunny) Even the most advanced equipment in the hands of the ignorant is just a pile of scrap. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/e31fcd42c1ff9b2ebe1046b4a88d1b0f.jpg?s=120&d=mm&r=g)
Sunny wrote:
On Jan 28, 2008 10:15 AM, Bob <linux@barrowhillfarm.org.uk> wrote:
My system has started running very slow, and the root directory is reported as having no free space. I've found a file /proc/kcore which is the probable culprit, being about 1000MB, with today's date, but even root is not allowed to move or delete this file.
My system looks like this:
Device Size Mount point Free sda2 965.1MB / 0B sda3 60.8MB /boot 46.8MB sda5 9.8GB /usr 4.9GB sda6 2.0GB /var 1.2GB sda7 2.0GB /opt 906.3MB sda8 1011.4MB /tmp 926.4MB sda9 257.3GB /home 154.1GB
/proc is virtual file system, which resides in memory, not on disk. Even some files are not actually in memory, but when you read them, you actually receive information from the kernel. In your case, read here for /proc/kcore: <http://www.unixguide.net/linux/faq/04.16.shtml>
Run the command "df" to see the how your partitions are filled in. Run "top" to see which process consumes more resources.
Note, that if you run firefox for several days w/o stopping it, it may eat a lot of resources.
Cheers
I prefer the term pseudo filesystem, since /proc does not reside in memory. As with any file system, procfs implements the functions defined by vfs, the virtual filesystem. The functions implemented actually read from, and in some cases write to, kernel data structures. The pathnames under /proc define which functions to call. There are a large number of such file systems: rootfs, sysfs, relayfs, tmpfs, and the list goes on. It works, because every filesystem is an implementation of vfs. Bill Anderson WW7BA -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/450b2e967219e620803a8b9e3c672e6e.jpg?s=120&d=mm&r=g)
On Monday 28 January 2008 17:59:44 Bill Anderson wrote:
Sunny wrote:
On Jan 28, 2008 10:15 AM, Bob <linux@barrowhillfarm.org.uk> wrote:
My system has started running very slow, and the root directory is reported as having no free space. I've found a file /proc/kcore which is the probable culprit, being about 1000MB, with today's date, but even root is not allowed to move or delete this file.
My system looks like this:
Device Size Mount point Free sda2 965.1MB / 0B sda3 60.8MB /boot 46.8MB sda5 9.8GB /usr 4.9GB sda6 2.0GB /var 1.2GB sda7 2.0GB /opt 906.3MB sda8 1011.4MB /tmp 926.4MB sda9 257.3GB /home 154.1GB
/proc is virtual file system, which resides in memory, not on disk. Even some files are not actually in memory, but when you read them, you actually receive information from the kernel. In your case, read here for /proc/kcore: <http://www.unixguide.net/linux/faq/04.16.shtml>
Run the command "df" to see the how your partitions are filled in. Run "top" to see which process consumes more resources.
Note, that if you run firefox for several days w/o stopping it, it may eat a lot of resources.
Cheers
I prefer the term pseudo filesystem, since /proc does not reside in memory. As with any file system, procfs implements the functions defined by vfs, the virtual filesystem. The functions implemented actually read from, and in some cases write to, kernel data structures. The pathnames under /proc define which functions to call. There are a large number of such file systems: rootfs, sysfs, relayfs, tmpfs, and the list goes on. It works, because every filesystem is an implementation of vfs.
Bill Anderson WW7BA
Hmmm. I can't say I understand much of that :(. I've been informed off-list that /proc/kcore is simply my running kernel, so that's probably not the file I'm looking for. Can anyone suggest a simple CLI incantation to find all files larger than, say, 500MB? -- Bob openSUSE 10.3, Kernel 2.6.22.13-0.3-default, KDE 3.5.8 Intel Celeron 2.53GB, 2GB DDR RAM, nVidia GeForce 7600GS -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/dad1a388b1f70818f2d8619f6e65516e.jpg?s=120&d=mm&r=g)
find / -size 500000k you can specify where to find however, find /home ... would find all files larger than 500mb in /home. -- Best regards, Nick Zeljkovic -----Original Message----- From: Bob [mailto:linux@barrowhillfarm.org.uk] Sent: Monday, January 28, 2008 7:21 PM To: opensuse@opensuse.org Subject: Re: [opensuse] Running slow, / full On Monday 28 January 2008 17:59:44 Bill Anderson wrote:
Sunny wrote:
On Jan 28, 2008 10:15 AM, Bob <linux@barrowhillfarm.org.uk> wrote:
My system has started running very slow, and the root directory is reported as having no free space. I've found a file /proc/kcore which is the probable culprit, being about 1000MB, with today's date, but even root is not allowed to move or delete this file.
My system looks like this:
Device Size Mount point Free sda2 965.1MB / 0B sda3 60.8MB /boot 46.8MB sda5 9.8GB /usr 4.9GB sda6 2.0GB /var 1.2GB sda7 2.0GB /opt 906.3MB sda8 1011.4MB /tmp 926.4MB sda9 257.3GB /home 154.1GB
/proc is virtual file system, which resides in memory, not on disk. Even some files are not actually in memory, but when you read them, you actually receive information from the kernel. In your case, read here for /proc/kcore: <http://www.unixguide.net/linux/faq/04.16.shtml>
Run the command "df" to see the how your partitions are filled in. Run "top" to see which process consumes more resources.
Note, that if you run firefox for several days w/o stopping it, it may eat a lot of resources.
Cheers
I prefer the term pseudo filesystem, since /proc does not reside in memory. As with any file system, procfs implements the functions defined by vfs, the virtual filesystem. The functions implemented actually read from, and in some cases write to, kernel data structures. The pathnames under /proc define which functions to call. There are a large number of such file systems: rootfs, sysfs, relayfs, tmpfs, and the list goes on. It works, because every filesystem is an implementation of vfs.
Bill Anderson WW7BA
Hmmm. I can't say I understand much of that :(. I've been informed off-list that /proc/kcore is simply my running kernel, so that's probably not the file I'm looking for. Can anyone suggest a simple CLI incantation to find all files larger than, say, 500MB? -- Bob openSUSE 10.3, Kernel 2.6.22.13-0.3-default, KDE 3.5.8 Intel Celeron 2.53GB, 2GB DDR RAM, nVidia GeForce 7600GS -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2008-01-28 at 18:20 -0000, Bob wrote:
My system looks like this:
Device Size Mount point Free sda2 965.1MB / 0B sda3 60.8MB /boot 46.8MB sda5 9.8GB /usr 4.9GB sda6 2.0GB /var 1.2GB sda7 2.0GB /opt 906.3MB sda8 1011.4MB /tmp 926.4MB sda9 257.3GB /home 154.1GB
...
Can anyone suggest a simple CLI incantation to find all files larger than, say, 500MB?
Considering that / is only 1 GB in size, I don't think that's the problem. I would use 'mc', mark all directories not included in the list above, and then tell it to display directory sizes. Find what they are and what they hold. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHniXTtTMYHG2NR9URAqbpAJ4roWtJs/GtsAC1A+qV3cB2kmdToQCgh55P WRkJ8l+6crNM1sqTtze6hz0= =DdmP -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/4302315541574064a521c84aefd10a7f.jpg?s=120&d=mm&r=g)
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Monday 2008-01-28 at 18:20 -0000, Bob wrote:
My system looks like this:
Device Size Mount point Free sda2 965.1MB / 0B sda3 60.8MB /boot 46.8MB sda5 9.8GB /usr 4.9GB sda6 2.0GB /var 1.2GB sda7 2.0GB /opt 906.3MB sda8 1011.4MB /tmp 926.4MB sda9 257.3GB /home 154.1GB
...
Can anyone suggest a simple CLI incantation to find all files larger than, say, 500MB?
Considering that / is only 1 GB in size, I don't think that's the problem.
I would use 'mc', mark all directories not included in the list above, and then tell it to display directory sizes. Find what they are and what they hold.
His problem is that his home directory is on the root partition, so he filled up the root partition with personal files. Why ANY installer doesn't make /home a separate partition by default is beyond me. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/4ffefd677c49c0369e9922bc51d4151e.jpg?s=120&d=mm&r=g)
On Jan 28, 2008 7:24 PM, Aaron Kulkis <akulkis00@hotpop.com> wrote:
Carlos E. R. wrote:
The Monday 2008-01-28 at 18:20 -0000, Bob wrote:
My system looks like this:
Device Size Mount point Free sda2 965.1MB / 0B sda3 60.8MB /boot 46.8MB sda5 9.8GB /usr 4.9GB sda6 2.0GB /var 1.2GB sda7 2.0GB /opt 906.3MB sda8 1011.4MB /tmp 926.4MB sda9 257.3GB /home 154.1GB
[...]
His problem is that his home directory is on the root partition, so he filled up the root partition with personal files. Are you sure about that? I see / on sda2 and /home on sda9. I strongly suspect that /root might be the problem here...
ne... -- Registered Linux User # 125653 (http://counter.li.org) Certified: 75% bastard, 42% of which is tard. http://www.thespark.com/bastardtest Now accepting personal mail for GMail invites. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2008-01-28 at 14:24 -0500, Aaron Kulkis wrote:
Carlos E. R. wrote:
The Monday 2008-01-28 at 18:20 -0000, Bob wrote:
My system looks like this:
Device Size Mount point Free sda2 965.1MB / 0B ... sda9 257.3GB /home 154.1GB ...
His problem is that his home directory is on the root partition, so he filled up the root partition with personal files.
No, look again. His /home is separate and is 257GiB - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHnz/btTMYHG2NR9URAoTiAJ4llSAdFqpNaDkuVZ5DYa9QJthqDgCbBit2 mY++eBu7/M5GkYvmU5AOzDg= =gnN4 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/067e5d0b8bad5213e476ae53bc7214b9.jpg?s=120&d=mm&r=g)
On Tuesday 29 January 2008 05:01:37 am Carlos E. R. wrote:
The Monday 2008-01-28 at 14:24 -0500, Aaron Kulkis wrote:
Carlos E. R. wrote:
The Monday 2008-01-28 at 18:20 -0000, Bob wrote:
> My system looks like this: > > Device Size Mount point Free > sda2 965.1MB / 0B
...
> sda9 257.3GB /home 154.1GB
...
His problem is that his home directory is on the root partition, so he filled up the root partition with personal files.
No, look again.
His /home is separate and is 257GiB
-- Cheers, Carlos E. R.
er, where is the swap? i would first suspect something like beagle or ktorrent filling up all the ram, then all of swap and then everything blazes along at the speed of molasses in Greenland:), regardless of free hard space... come to think of it, the default ktorrent settings as set automatically in my system would do that, had to tweak them myself... open ktorrent, settings, memory usage or something like it.. d. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/b12cfb65ca4faebc3e3aac17838e8f8d.jpg?s=120&d=mm&r=g)
On Monday 28 January 2008 10:20, Bob wrote:
...
Can anyone suggest a simple CLI incantation to find all files larger than, say, 500MB?
% find startingDirectory -size +500M The plus sign means "bigger than." The M suffix means units of 2^20 (1048576 bytes); A G suffix makes the units 2^30 (1073741824 bytes). If you want decimal sizes, use the actual number (e.g., 1000000) and suffix it with 'c'. Man find for more details, of course.
-- Bob
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/b12cfb65ca4faebc3e3aac17838e8f8d.jpg?s=120&d=mm&r=g)
On Monday 28 January 2008 09:59, Bill Anderson wrote:
...
I prefer the term pseudo filesystem, since /proc does not reside in memory. As with any file system, procfs implements the functions defined by vfs, the virtual filesystem. The functions implemented actually read from, and in some cases write to, kernel data structures. The pathnames under /proc define which functions to call. There are a large number of such file systems: rootfs, sysfs, relayfs, tmpfs, and the list goes on. It works, because every filesystem is an implementation of vfs.
Where they do _not_ reside is on mass storage. It most certainly _does_ reside in primary storage (a.k.a. "memory," a.k.a. RAM). The fact that the information is derived on-demand from the current state of the system is only incidental and not fundamentally different from the constituents of any more ordinary file system.
Bill Anderson WW7BA
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/e31fcd42c1ff9b2ebe1046b4a88d1b0f.jpg?s=120&d=mm&r=g)
On Monday 28 January 2008 09:59, Bill Anderson wrote:
...
I prefer the term pseudo filesystem, since /proc does not reside in memory. As with any file system, procfs implements the functions defined by vfs, the virtual filesystem. The functions implemented actually read from, and in some cases write to, kernel data structures. The pathnames under /proc define which functions to call. There are a large number of such file systems: rootfs, sysfs, relayfs, tmpfs, and the list goes on. It works, because every filesystem is an implementation of vfs.
Where they do _not_ reside is on mass storage. It most certainly _does_ reside in primary storage (a.k.a. "memory," a.k.a. RAM). The fact that the information is derived on-demand from the current state of the system is only incidental and not fundamentally different from the constituents of any more ordinary file system.
Bill Anderson WW7BA
Randall Schulz You will not find a structure in the kernel that is an exact reflection of /proc. As I said, it is only a filesystem in that every filesystem is an implemention of vfs. The system calls involving any filesystem, flow
Randall R Schulz wrote: through vfs. Furthermore, any module can create an entry in the /proc filesystem, and provide the routines to handle the open, close, read, and write requests. The reason for the existence of /proc is to provide a link between kernel space and user space that does not involving the creation of a system call to handle every request for information. Furthermore, you can configure the kernel so that it does not create a /proc structure. Of course, some of the user space commands will not work (eg: ps, vmstat, lsof, lsmod, lsusb, lspci, and others), as they derive their information from /proc. If you have an doubts, you can see the source fo information by using strace on any command. Bill Anderson WW7BA -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/4302315541574064a521c84aefd10a7f.jpg?s=120&d=mm&r=g)
Bob wrote:
My system has started running very slow, and the root directory
That's what happens when you leave /home on the root filesysem.
is reported as having no free space. I've found a file /proc/kcore
Don't screw with that -- it takes NO disk space ... Remember...EVERYTHING on Unix and Linux is a file.... including system memory. The entire /proc directory is a virtual filesystem -- it's not on any disk drive ANYWHERE. /proc/kcore is all of kernal memory presented as a file. Don't touch it unless you are George Goble (whom I have witnessed tuning the kernel parameters of a running kernal using a symbolic debugger...with 50+ user logged in and doing their work... and only AFTER obtaining the desired performance, recompiling the kernel to match his tuning)
which is the probable culprit, being about 1000MB, with today's date, but even root is not allowed to move or delete this file.
My system looks like this:
Device Size Mount point Free sda2 965.1MB / 0B sda3 60.8MB /boot 46.8MB sda5 9.8GB /usr 4.9GB sda6 2.0GB /var 1.2GB sda7 2.0GB /opt 906.3MB sda8 1011.4MB /tmp 926.4MB sda9 257.3GB /home 154.1GB
I've been downloading openSUSE 11.0 Alpha1, via ktorrent for the past 24 hours, but other than that I'm only doing what I always do - read email, news, browse the web, play music.
Your problem is that you failed to make a /home partition, and your personal files have filled up the root partition. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/006622e8f332b00f48fc8486198808a7.jpg?s=120&d=mm&r=g)
Aaron Kulkis wrote:
Your problem is that you failed to make a /home partition, and your personal files have filled up the root partition.
I don't know if it would help in this situation at all, but I found my server filling up for no good reason I could think of. Then I happened to look at my /tmp directory, and was amazed at what all was there. Don't applications that create temp files ever clean up after themselves anymore? I changed to runlevel 1 to make the file system as quiet as possible, removed /tmp/* and /tmp/.*, and gained 112 GB of space. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/c18a749dda699514c262030be9e0ded9.jpg?s=120&d=mm&r=g)
On Jan 29, 2008 5:21 AM, Jerry Houston <jerry@effjayare.net> wrote:
I don't know if it would help in this situation at all, but I found my server filling up for no good reason I could think of. Then I happened to look at my /tmp directory, and was amazed at what all was there. Don't applications that create temp files ever clean up after themselves anymore?
Check in Yast/System/sysconfig/System/Cron - there are setting to enable automatic cleanup of the temp directories. -- Svetoslav Milenov (Sunny) Even the most advanced equipment in the hands of the ignorant is just a pile of scrap. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/067e5d0b8bad5213e476ae53bc7214b9.jpg?s=120&d=mm&r=g)
On Tuesday 29 January 2008 12:26:32 pm Jerry Houston wrote:
Sunny wrote:
Check in Yast/System/sysconfig/System/Cron - there are setting to enable automatic cleanup of the temp directories.
Sounds good. Thanks!
well, i guess i will try a repost: the problem at hand is most probably a filled up memory and swap. ktorrent by default becomes a memory hog, it needs to be told to do with less. that's all... d. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/4302315541574064a521c84aefd10a7f.jpg?s=120&d=mm&r=g)
Jerry Houston wrote:
Aaron Kulkis wrote:
Your problem is that you failed to make a /home partition, and your personal files have filled up the root partition.
I don't know if it would help in this situation at all, but I found my server filling up for no good reason I could think of. Then I happened to look at my /tmp directory, and was amazed at what all was there. Don't applications that create temp files ever clean up after themselves anymore?
Sadly, no. That's one reason why I also keep /tmp on a its own partition (also to keep write() activity to a minimum on the root partition -- corrupted root => difficult or no boot-up
I changed to runlevel 1 to make the file system as quiet as possible, removed /tmp/* and /tmp/.*, and gained 112 GB of space.
In the future, boot to runlevel S (or s)
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/11b4b3cf016b1d6a62454324eaaacc59.jpg?s=120&d=mm&r=g)
On Monday 28 January 2008 10:15:40 am Bob wrote:
My system looks like this:
Device Size Mount point Free sda2 965.1MB / 0B sda3 60.8MB /boot 46.8MB sda5 9.8GB /usr 4.9GB sda6 2.0GB /var 1.2GB sda7 2.0GB /opt 906.3MB sda8 1011.4MB /tmp 926.4MB sda9 257.3GB /home 154.1GB
I've been downloading openSUSE 11.0 Alpha1, via ktorrent for the past 24 hours, but other than that I'm only doing what I always do - read email, news, browse the web, play music.
The /proc is discussed, so to make it simple, just forget it. That is not your problem. The kcore doesn't use hard disk. The problem seems to be somewhat tight size of partitions: Device Size Mount point Free sda2 965.1MB / 0B sda8 1011.4MB /tmp 926.4MB With 1GB /tmp file operation that want to work on 2 GB file will have a problem if it uses /tmp. Download will use /tmp sometimes. The problem is that / is full and it is on primary partition. There is few solutions to make another bigger, and move everything there, or to delete some of content. What is in / to use 965 MB I can only guess. I was looking few directories that are left in your / directory: 76M /lib 7.3M /bin 112K /dev 41M /etc 60K /srv 9.0M /sbin Nothing close to 965 MB. For instance /root has some big files that can be moved to your home directory. It could be old /tmp and /var that have files that are not deleted before you mounted partitions on that directories and they take place on hard disk. I would check /root (home of root user) first and move large files to your home directory. If that doesn't help, than, end GUI session (log out > end current session) go to console with Ctrl+Alt+F2 login as root, and: init 1 umount /tmp ls -al /tmp if you see any files delete them. cd /tmp rm -IR ./* # check man page. The rm command can do a damage. cd Mount /tmp again: mount /dev/sda8 /tmp Now /var: umount /var ls -al /var if you see any files delete them. cd /var rm -IR ./* # check man page. The rm command can do a damage. cd mount /dev/sda6 /var back to GUI init 5 Apropos download: To download you can use console program: wget -c <URL> started in directory where you want to save file. Recently I stopped download and opted not to delete temporary file in download directory. It was ending with *.iso.part. Renaming *.iso.part to *.iso and starting 'wget -c <URL>', with server address instead of <URL>, in that directory wget picked up and downloaded the rest (first surprise, somewhat expected). That was Alpha1 and iso works in VirtualBox (second surprise, not really expected). -- Regards, Rajko -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2008-01-29 at 00:20 -0600, Rajko M. wrote:
The problem seems to be somewhat tight size of partitions: Device Size Mount point Free sda2 965.1MB / 0B sda8 1011.4MB /tmp 926.4MB
Probably. They are too small, no margin.
I was looking few directories that are left in your / directory: 76M /lib
Mine is 133 MiB
7.3M /bin 112K /dev 41M /etc
Mine is 98 MiB
60K /srv
180 MiB
9.0M /sbin
13 MiB - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHn0G7tTMYHG2NR9URAmexAJ9n7yDDJhER7P0LFErCZ2xapzT6PQCfYCtD t2Hkvn2/JY93msRJKnUVdKM= =5qMy -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/11b4b3cf016b1d6a62454324eaaacc59.jpg?s=120&d=mm&r=g)
On Tuesday 29 January 2008 09:09:47 am Carlos E. R. wrote:
The Tuesday 2008-01-29 at 00:20 -0600, Rajko M. wrote:
The problem seems to be somewhat tight size of partitions: Device Size Mount point Free sda2 965.1MB / 0B sda8 1011.4MB /tmp 926.4MB
Probably. They are too small, no margin.
I was looking few directories that are left in your / directory: 76M /lib
Mine is 133 MiB
7.3M /bin 112K /dev 41M /etc
Mine is 98 MiB
60K /srv
180 MiB
9.0M /sbin
13 MiB
-- Cheers, Carlos E. R.
Still, it is not close to 965 MiB. Looking the partitions it seems that all is created during installation, so it should not be a /tmp and /var previous content that is using hard disk, unless installer used them and forgot to clean after mounting partitions. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/eeaa070dd6317ec84ae2eb35d4eaf01f.jpg?s=120&d=mm&r=g)
Rajko M. pecked at the keyboard and wrote:
On Tuesday 29 January 2008 09:09:47 am Carlos E. R. wrote:
Carlos E. R.
Still, it is not close to 965 MiB. Looking the partitions it seems that all is created during installation, so it should not be a /tmp and /var previous content that is using hard disk, unless installer used them and forgot to clean after mounting partitions.
Since it is quite _obvious_ that the _root_ partition is full that is where the OP needs to start looking. du -sk|sort -n will report least used to most used. Ignore filesystems on other partitions and you are on your way to solving the problem. When you find which directory is the culprit cd to it and run the command again and again cd to the most used directory again until you find the problem. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Tuesday 2008-01-29 at 23:40 -0500, Ken Schneider wrote:
du -sk|sort -n will report least used to most used. Ignore filesystems on other partitions and you are on your way to solving the problem. When you find which directory is the culprit cd to it and run the command again and again cd to the most used directory again until you find the problem.
Considering that one of the partitions has 250 GB, that will take a long time. Better use a command that will not consider any other partition. Like du -x, perhaps. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHoHOqtTMYHG2NR9URAqRiAJsFvrdmG2JduT5Zs9XOs5DSJEM8TACfTjZM xs1V6J4xwugPRev+OcqMGkk= =RuEf -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/7ac97ea47b95f79d6f0501bd93df3062.jpg?s=120&d=mm&r=g)
On Wednesday 30 January 2008 13:55, Carlos E. R. wrote:
du -sk|sort -n will report least used to most used. Ignore filesystems on other partitions and you are on your way to solving the problem. When you find which directory is the culprit cd to it and run the command again and again cd to the most used directory again until you find the problem.
Considering that one of the partitions has 250 GB, that will take a long time. Better use a command that will not consider any other partition.
Like du -x, perhaps.
I wonder why anybody would bother with "du" on the command line these days for this kind of task. There are a number of GUI applications to do just that. http://kdirstat.sourceforge.net/ or Baobab for GNOME or FileLight. ANY of those is way superior to repeatedly typing "du" and trying to figure out manually what's going on. CU -- Stefan Hundhammer <sh@suse.de> Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/eeaa070dd6317ec84ae2eb35d4eaf01f.jpg?s=120&d=mm&r=g)
Stefan Hundhammer pecked at the keyboard and wrote:
On Wednesday 30 January 2008 13:55, Carlos E. R. wrote:
du -sk|sort -n will report least used to most used. Ignore filesystems on other partitions and you are on your way to solving the problem. When you find which directory is the culprit cd to it and run the command again and again cd to the most used directory again until you find the problem. Considering that one of the partitions has 250 GB, that will take a long time. Better use a command that will not consider any other partition.
Like du -x, perhaps.
I wonder why anybody would bother with "du" on the command line these days for this kind of task. There are a number of GUI applications to do just that.
http://kdirstat.sourceforge.net/
or Baobab for GNOME or FileLight. ANY of those is way superior to repeatedly typing "du" and trying to figure out manually what's going on.
CU
Because you need to use the tools _installed_ when the root directory is full and you cannot install any other software. And it is always nice to have knowledge of other tools at your disposal. In this case / was full so no other software could be installed for trouble shooting purposes. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/7ac97ea47b95f79d6f0501bd93df3062.jpg?s=120&d=mm&r=g)
On Wednesday 30 January 2008 14:58, Ken Schneider wrote:
I wonder why anybody would bother with "du" on the command line these days for this kind of task. There are a number of GUI applications to do just that.
http://kdirstat.sourceforge.net/
or Baobab for GNOME or FileLight. ANY of those is way superior to repeatedly typing "du" and trying to figure out manually what's going on.
Because you need to use the tools _installed_ when the root directory is full and you cannot install any other software.
Depending on what you installed initially, chances are you have one of these installed anyway. But even if you don't, the OP had this setup: http://lists.opensuse.org/opensuse/2008-01/msg03094.html
My system looks like this:
Device Size Mount point Free sda2 965.1MB / 0B sda3 60.8MB /boot 46.8MB sda5 9.8GB /usr 4.9GB sda6 2.0GB /var 1.2GB sda7 2.0GB /opt 906.3MB sda8 1011.4MB /tmp 926.4MB sda9 257.3GB /home 154.1GB
So even though / was full, there was still plenty of free space in /usr, /opt, and /var. This is what you need to install software. The "rpm" command will change the RPM DB, which resides in /var/lib/rpm (1.2 GB free). No problem. I didn't check for the other two packages, but kdirstat will install files to /opt/kde3 (906.3 MB free) and to /usr/share/doc (4.9 GB free). So it turns out that even though he tried to delete /proc/kcore, he is not such a newbie after all. At least, his partitioning shows that he did take action to prevent a number of disasters that hit many other people when the root file system is filling up. I agree that most users won't be able to install any more software once the root file system is full since typically they also have /var, /usr, and /opt on the same partition. But not in this case.
And it is always nice to have knowledge of other tools at your disposal.
Sure it's nice to know about other tools so you have a fallback solution when the easier-to-use tools are unavailable for whatever reason, but still you want to choose the right tool for the job. And in most cases, this is the one that is simpler to use. Remember, the OP had a real problem. Is this the time for academic proofs of concept or the time for solutions that work? ;-)
In this case / was full so no other software could be installed for trouble shooting purposes.
See above. ;-) CU -- Stefan Hundhammer <sh@suse.de> Penguin by conviction. YaST2 Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Nürnberg, Germany -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/eeaa070dd6317ec84ae2eb35d4eaf01f.jpg?s=120&d=mm&r=g)
Carlos E. R. pecked at the keyboard and wrote:
The Tuesday 2008-01-29 at 23:40 -0500, Ken Schneider wrote:
du -sk|sort -n will report least used to most used. Ignore filesystems on other partitions and you are on your way to solving the problem. When you find which directory is the culprit cd to it and run the command again and again cd to the most used directory again until you find the problem.
Considering that one of the partitions has 250 GB, that will take a long time. Better use a command that will not consider any other partition.
Like du -x, perhaps.
-- Cheers, Carlos E. R.
I tried using that on my system and the du command seemed to ignore the -x. Perhaps du -x |sort -n|tail -10 would work better? -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2008-01-30 at 08:54 -0500, Ken Schneider wrote: Reposting after my unsubsription :-/
Considering that one of the partitions has 250 GB, that will take a long time. Better use a command that will not consider any other partition.
Like du -x, perhaps.
I tried using that on my system and the du command seemed to ignore the -x. Perhaps du -x |sort -n|tail -10 would work better?
The problem is that if you write something like "du -x /*", then you are saying "/", but also "/home" and all other partitions. I'm not a fan of "du", I'm afraid, so I don't really know how to use it to get exactly what I want, ie, a summary of each directory hanging from /, but on the / filesystem exclusively. I'd have to play for a bit, and then I'll forget the next time :-} - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHoKDGtTMYHG2NR9URAuTQAJ9BDpHtv1B/zWGMkHH5X8HtlgbKJQCeN0jS Xovgmn8zKDsw/N4c9iU6cTw= =9l+N -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/b72f250a4f5b7bc95f1e9b00f684ecc1.jpg?s=120&d=mm&r=g)
On Tuesday 29 January 2008 18:40:29 Ken Schneider wrote:
Rajko M. pecked at the keyboard and wrote:
On Tuesday 29 January 2008 09:09:47 am Carlos E. R. wrote:
Carlos E. R.
Still, it is not close to 965 MiB. Looking the partitions it seems that all is created during installation, so it should not be a /tmp and /var previous content that is using hard disk, unless installer used them and forgot to clean after mounting partitions.
Since it is quite _obvious_ that the _root_ partition is full that is where the OP needs to start looking.
du -sk|sort -n will report least used to most used. Ignore filesystems on other partitions and you are on your way to solving the problem. When you find which directory is the culprit cd to it and run the command again and again cd to the most used directory again until you find the problem.
-- Ken Schneider SuSe since Version 5.2, June 1998
I ran :~> du -sk|sort -n 73457269 . and only got a number. Jerome -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/450b2e967219e620803a8b9e3c672e6e.jpg?s=120&d=mm&r=g)
On Tuesday 29 January 2008 15:09:47 Carlos E. R. wrote:
The Tuesday 2008-01-29 at 00:20 -0600, Rajko M. wrote:
The problem seems to be somewhat tight size of partitions: Device Size Mount point Free sda2 965.1MB / 0B sda8 1011.4MB /tmp 926.4MB
Probably. They are too small, no margin.
That's obviously true of / (at the moment) but why do you say the margin is tight on /tmp? It's only 8.5% full! Bob -- Bob openSUSE 10.3, Kernel 2.6.22.13-0.3-default, KDE 3.5.8 Intel Celeron 2.53GB, 2GB DDR RAM, nVidia GeForce 7600GS -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/77cb4da5f72bc176182dcc33f03a18f3.jpg?s=120&d=mm&r=g)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2008-01-30 at 21:41 -0000, Bob wrote:
That's obviously true of / (at the moment) but why do you say the margin is tight on /tmp? It's only 8.5% full!
Normally. But you could have to run a process needing large temporary files, like a 3 GiB one, and you are done. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHoPhztTMYHG2NR9URAoOfAJ9MNX/IOkJJEyDzTPhjmCQtpvUMUwCePUer GvJQFr+QSI/MrHZXR+8gz4Y= =QWi3 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/50003a59950b35ef05d8de10a54c2515.jpg?s=120&d=mm&r=g)
Bob wrote:
My system has started running very slow, and the root directory is reported as having no free space. I've found a file /proc/kcore which is the probable culprit, being about 1000MB, with today's date, but even root is not allowed to move or delete this file.
My system looks like this:
Device Size Mount point Free sda2 965.1MB / 0B sda3 60.8MB /boot 46.8MB sda5 9.8GB /usr 4.9GB sda6 2.0GB /var 1.2GB sda7 2.0GB /opt 906.3MB sda8 1011.4MB /tmp 926.4MB sda9 257.3GB /home 154.1GB
I've been downloading openSUSE 11.0 Alpha1, via ktorrent for the past 24 hours, but other than that I'm only doing what I always do - read email, news, browse the web, play music.
Hi, fwiw I experienced such a behaviour with using rsnapshot for backup purposes. When I began, I foolishly forgot to set "no_create_root 1" in rsnapshot conf. Consequently when the backup ran AND the backup disk was not mounted, it created a directory "/media/backup" and the rsnapshot backup filled this until my / was 100% full. You learn something anytime, indeed. Kind regards Eberhard -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/450b2e967219e620803a8b9e3c672e6e.jpg?s=120&d=mm&r=g)
On Tuesday 29 January 2008 19:03:49 Eberhard Roloff wrote:
Hi,
fwiw I experienced such a behaviour with using rsnapshot for backup purposes. When I began, I foolishly forgot to set "no_create_root 1" in rsnapshot conf. Consequently when the backup ran AND the backup disk was not mounted, it created a directory "/media/backup" and the rsnapshot backup filled this until my / was 100% full.
That could be the answer, as I back up to an external USB hard drive using an rsync script which is very similar to rsnapshot. I had noticed that the backup disk was almost full (150GB), just before the root directory problem. I'm also looking into my ktorrent settings. Thanks to everyone who has replied to this thread. One suggestion was that the / directory was too small at 1GB. It seemed to have been very happy with this size until Yast2 software management warned me when I was installing some more packages. I'd be interested to know how big other people's / is. Would 2GB suffice? Bear in mind I have /usr, /var, /opt and /tmp all in their own partitions (which may or may not be large enough!). So, apart from /etc there's not a lot left for /. Bob -- Bob openSUSE 10.3, Kernel 2.6.22.13-0.3-default, KDE 3.5.8 Intel Celeron 2.53GB, 2GB DDR RAM, nVidia GeForce 7600GS -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (15)
-
Aaron Kulkis
-
Bill Anderson
-
Bob
-
Carlos E. R.
-
Eberhard Roloff
-
Jerry Houston
-
kanenas@hawaii.rr.com
-
Ken Schneider
-
ne...
-
Nick Zeljkovic
-
Rajko M.
-
Randall R Schulz
-
Stefan Hundhammer
-
Sunny
-
Susemail