Universal trash ? & Log in prob.
Hello SuSE people. First of all reunning 9.2 & KDE 3.4 Universal trash is a question/warning for others. The log in problem is related/caused by that which I don't know how to fix. A little long-winded but necessary to understand the problem. History is: A few nights ago I ripped a movie DVD. When I finished I put the 7 gig file in the trash. Last night I started to do a Kdar backup and started to get error messages. One being that /tmp was full and couldn't proceed. I have /tmp set to empty every time I boot up so I just rebooted. After the reboot, SuSE brings me to a screen message that says / directory is full and KDE is unable to start. I drop down to init 3 and look at the /tmp & / directories and find nothing obvious. Then I boot from the DVD and do a system repair. Still nothing obvious. My / directory is 2 gig and is normally about 20% used. After several hours of this I just start trying different things to empty those directories. /tmp IS empty after the reboot except for the normal boot stuff. Just the / directory is 100% full. I finally see the huge trash files and empty the trash for all 3 users AND root! That empties my / directory. Hence the question/warning. How is it possible that trash can be in root's trashcan?? Is the trash universal with all users? Anyway, that returned my / directory to normal and I reboot. Now I get to the log in screen and attempt to log in as my normal user. X starts it's thing and I am dumped back to the log in screen. I try the other users and they work normally and bring up their KDE screens. Only I cannot log in this way. I have to drop back to init 3 log in and then startx. Then I get my normal KDE screen. Why only me? and how do I go about fixing that ? Bob S.
On Thursday 16 June 2005 00:18, B. Stia wrote:
Hello SuSE people.
First of all reunning 9.2 & KDE 3.4
Universal trash is a question/warning for others. The log in problem is related/caused by that which I don't know how to fix.
A little long-winded but necessary to understand the problem. History is: A few nights ago I ripped a movie DVD. When I finished I put the 7 gig file in the trash. Last night I started to do a Kdar backup and started to get error messages. One being that /tmp was full and couldn't proceed. I have /tmp set to empty every time I boot up so I just rebooted. After the reboot, SuSE brings me to a screen message that says / directory is full and KDE is unable to start. I drop down to init 3 and look at the /tmp & / directories and find nothing obvious. Then I boot from the DVD and do a system repair. Still nothing obvious. My / directory is 2 gig and is normally about 20% used. After several hours of this I just start trying different things to empty those directories. /tmp IS empty after the reboot except for the normal boot stuff. Just the / directory is 100% full. I finally see the huge trash files and empty the trash for all 3 users AND root! That empties my / directory. Hence the question/warning. How is it possible that trash can be in root's trashcan?? Is the trash universal with all users?
Anyway, that returned my / directory to normal and I reboot. Now I get to the log in screen and attempt to log in as my normal user. X starts it's thing and I am dumped back to the log in screen. I try the other users and they work normally and bring up their KDE screens. Only I cannot log in this way. I have to drop back to init 3 log in and then startx. Then I get my normal KDE screen.
Why only me? and how do I go about fixing that ?
Bob S.
Whoops !! It isn't the trash. Just found out that my / directory is 98.4% full again. Looked at everything. Can't figure out what it is or what is causing that. Did a YOU kernel upgrade two days ago. What is filling up 1.5 gigs of my / directory?? Bob S.
Quoting B. Stia <usr@sanctum.com>: [snip]
Whoops !! It isn't the trash. Just found out that my / directory is 98.4% full again. Looked at everything. Can't figure out what it is or what is causing that. Did a YOU kernel upgrade two days ago. What is filling up 1.5 gigs of my / directory??
du -s /* HTH, Jeffrey
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2005-06-16 at 02:24 -0400, B. Stia wrote:
Whoops !! It isn't the trash. Just found out that my / directory is 98.4% full again. Looked at everything. Can't figure out what it is or what is causing that. Did a YOU kernel upgrade two days ago. What is filling up 1.5 gigs of my / directory??
Kernels can be big, for example. Sometimes YOU don't delete the old version. Another place that gets big is the directory where YOU keeps its downloaded stuff. If you keep patches (I do, my download time is valuable) you can purge older rpms or save them to a CD. You can do a "du -s /*", as Jeffrey said; I prefer options -sch. Or you can use "mc", midnight commander, it can also show directory sizes (an option in the command menu). Then you can navigate and find the offending files. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFCsVpStTMYHG2NR9URAoxQAJ9IJ43Kp2VvwVNO+yTEbSShBhLazQCeNgKK lPy1o//2GrcC17fpdLYmVJM= =rXa5 -----END PGP SIGNATURE-----
On Thu, 2005-06-16 at 02:24 -0400, B. Stia wrote:
On Thursday 16 June 2005 00:18, B. Stia wrote:
Whoops !! It isn't the trash. Just found out that my / directory is 98.4% full again. Looked at everything. Can't figure out what it is or what is causing that. Did a YOU kernel upgrade two days ago. What is filling up 1.5 gigs of my / directory??
Bob S.
Try using du -sk * starting at / to see what is using all the space. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
On Thursday 16 June 2005 07:16, Ken Schneider wrote:
On Thu, 2005-06-16 at 02:24 -0400, B. Stia wrote:
On Thursday 16 June 2005 00:18, B. Stia wrote:
Whoops !! It isn't the trash. Just found out that my / directory is 98.4% full again. Looked at everything. Can't figure out what it is or what is causing that. Did a YOU kernel upgrade two days ago. What is filling up 1.5 gigs of my / directory??
Bob S.
Try using du -sk * starting at / to see what is using all the space.
Jeffrey, Carlos, Ken, Thanks for replying. I did the disk usage command and the following is the result. That partition is 2 gigs. I don' see amything that jumps out at me. Maybe I am not seeing/doing it correctly. EasyStreet:/ # du -sch /* 7.7M /bin 6.8M /boot 480K /dev 26M /etc 8.0K /hdabkup 74M /lib 14M /lib64 16K /lost+found du: `/media/cdrecorder': No medium found du: `/media/dvdrecorder': No medium found du: `/media/floppy': No medium found 12K /media 4.0K /mnt 1.1G /proc 53M /root 11M /sbin 1.4M /srv 0 /sys 56K /tmp 12K /windows ??G total (about 195 M not counting proc of 1.1 G)(Does /proc count in disk usage ?) EasyStreet:/ # I didn't show /home, usr, opt, var as they are all on their own partitions. More ideas, guidance, please ? KDiskFree shows the / partition as being 98.6 % used Carlos, checked in mc also. Nothing obvious. I do have several old kernels laying around. Is it safe to remove anything and everything associated with an old kernel? Here is what I have in my /boot directory: bob@EasyStreet:/boot> ls -l total 6584 -rw-r--r-- 1 root root 512 2005-06-14 23:45 backup_mbr lrwxrwxrwx 1 root root 1 2004-11-25 23:16 boot -> . -rw-r--r-- 1 root root 512 2004-11-16 22:48 boot.0300 -rw-r--r-- 1 root root 49224 2005-06-02 11:52 config-2.6.8-24.16-default drwxr-xr-x 2 root root 4096 2004-11-25 23:16 grub lrwxrwxrwx 1 root root 26 2005-06-14 23:45 initrd -> initrd-2.6.8-24.16-default -rw-r--r-- 1 root root 1892352 2005-06-14 23:45 initrd-2.6.8-24.16-default -rw------- 1 root root 184832 2005-06-11 23:17 map -rw-r--r-- 1 root root 94720 2004-12-29 22:03 message -rw-r--r-- 1 root root 76168 2005-06-02 11:52 symvers-2.6.8-24.16-x86_64-default.gz -rw-r--r-- 1 root root 879433 2005-06-02 11:45 System.map-2.6.8-24.16-default -rw-r--r-- 1 root root 1892964 2005-06-02 11:52 vmlinux-2.6.8-24.16-default.gz lrwxrwxrwx 1 root root 27 2005-06-11 23:17 vmlinuz -> vmlinuz-2.6.8 -24.16-default -rw-r--r-- 1 root root 1609722 2005-06-02 11:46 vmlinuz-2.6.8-24.16-default bob@EasyStreet:/boot> All of the Yast2 stuff is in /var/lib/yast which is on a different partition so it wouldn't effect this problem. (pretty big though and if I knew what I was doing I would clean it out) Bob S. Bob S.
On Fri, 2005-06-17 at 00:13 -0400, B. Stia wrote:
On Thursday 16 June 2005 07:16, Ken Schneider wrote:
On Thu, 2005-06-16 at 02:24 -0400, B. Stia wrote:
On Thursday 16 June 2005 00:18, B. Stia wrote:
Whoops !! It isn't the trash. Just found out that my / directory is 98.4% full again. Looked at everything. Can't figure out what it is or what is causing that. Did a YOU kernel upgrade two days ago. What is filling up 1.5 gigs of my / directory??
Bob S.
Try using du -sk * starting at / to see what is using all the space.
Jeffrey, Carlos, Ken,
Thanks for replying. I did the disk usage command and the following is the result. That partition is 2 gigs. I don' see amything that jumps out at me. Maybe I am not seeing/doing it correctly.
EasyStreet:/ # du -sch /* 7.7M /bin 6.8M /boot 480K /dev 26M /etc 8.0K /hdabkup 74M /lib 14M /lib64 16K /lost+found du: `/media/cdrecorder': No medium found du: `/media/dvdrecorder': No medium found du: `/media/floppy': No medium found 12K /media 4.0K /mnt 1.1G /proc 53M /root 11M /sbin 1.4M /srv 0 /sys 56K /tmp 12K /windows ??G total (about 195 M not counting proc of 1.1 G)(Does /proc count in disk usage ?) EasyStreet:/ #
I didn't show /home, usr, opt, var as they are all on their own partitions. More ideas, guidance, please ? KDiskFree shows the / partition as being 98.6 % used
Can you also show the results of df? -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
On Friday 17 June 2005 08:32, Ken Schneider wrote:
On Fri, 2005-06-17 at 00:13 -0400, B. Stia wrote:
On Thursday 16 June 2005 07:16, Ken Schneider wrote:
On Thu, 2005-06-16 at 02:24 -0400, B. Stia wrote:
On Thursday 16 June 2005 00:18, B. Stia wrote:
Whoops !! It isn't the trash. Just found out that my / directory is 98.4% full again. Looked at everything. Can't figure out what it is or what is causing that. Did a YOU kernel upgrade two days ago. What is filling up 1.5 gigs of my / directory??
Bob S.
Try using du -sk * starting at / to see what is using all the space.
Jeffrey, Carlos, Ken,
Thanks for replying. I did the disk usage command and the following is the result. That partition is 2 gigs. I don' see amything that jumps out at me. Maybe I am not seeing/doing it correctly.
EasyStreet:/ # du -sch /* 7.7M /bin 6.8M /boot 480K /dev 26M /etc 8.0K /hdabkup 74M /lib 14M /lib64 16K /lost+found du: `/media/cdrecorder': No medium found du: `/media/dvdrecorder': No medium found du: `/media/floppy': No medium found 12K /media 4.0K /mnt 1.1G /proc 53M /root 11M /sbin 1.4M /srv 0 /sys 56K /tmp 12K /windows ??G total (about 195 M not counting proc of 1.1 G)(Does /proc count in disk usage ?) EasyStreet:/ #
I didn't show /home, usr, opt, var as they are all on their own partitions. More ideas, guidance, please ? KDiskFree shows the / partition as being 98.6 % used
Can you also show the results of df?
Ken, Following is output of df: EasyStreet:/ # df -ah /* Filesystem Size Used Avail Use% Mounted on /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb8 2.6G 326M 2.2G 13% /data /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb9 2.7G 33M 2.5G 2% /hdabkup /dev/hdb3 5.4G 1.1G 4.0G 21% /home /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb5 7.7G 33M 7.3G 1% /newlinux /dev/hdb4 1.5G 824M 570M 60% /opt proc 0 0 0 - /proc /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% / - 0 0 0 - /sys /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb7 3.3G 2.8G 283M 91% /usr /dev/hdb10 1.5G 516M 885M 37% /var /dev/hdb1 2.0G 1.9G 30M 99% / EasyStreet:/ # Are more options necessary ? Bob S.
On Fri, 2005-06-17 at 17:29 -0400, B. Stia wrote:
On Friday 17 June 2005 08:32, Ken Schneider wrote:
Can you also show the results of df?
Ken,
Following is output of df:
EasyStreet:/ # df -ah /* Filesystem Size Used Avail Use% Mounted on /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb8 2.6G 326M 2.2G 13% /data /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb9 2.7G 33M 2.5G 2% /hdabkup /dev/hdb3 5.4G 1.1G 4.0G 21% /home /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb5 7.7G 33M 7.3G 1% /newlinux /dev/hdb4 1.5G 824M 570M 60% /opt proc 0 0 0 - /proc /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% / - 0 0 0 - /sys /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb7 3.3G 2.8G 283M 91% /usr /dev/hdb10 1.5G 516M 885M 37% /var /dev/hdb1 2.0G 1.9G 30M 99% / EasyStreet:/ #
Are more options necessary ? Bob S.
Wow, 15 entries for /. There should only be one. Something is radically wrong here. Try booting to the rescue DVD/CD and running fsck on /dev/hdb1 and see if anything shows up there. It's almost as though there is some corruption going on with the hard drive or a flaky power supply causing intermittent problems. Try removing the /etc/mtab file while in rescue mode, if it exists. You will need to mount /dev/hdb1 to /some_mount_point while booted in rescue mode to look for it. Something like: mount /dev/hdb1 /mnt rm /mnt/etc/mtab (there will be an error if it does not exist and it shouldn't if you are not booted to the hard drive) umount /mnt Also look in /lost+found and see if anything is there as it would indicate file system problems as well and show faulty disk usage. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2005-06-17 at 17:41 -0400, Ken Schneider wrote:
/dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% /
Wow, 15 entries for /. There should only be one.
:-O Have a look at /etc/fstab - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFCs1+AtTMYHG2NR9URArZdAKCNqWIXf3v0gCKhZq9Swiup6znIPACeJNRi aIQHE4SCJWex2y1bgVpzfNE= =cRsP -----END PGP SIGNATURE-----
On Friday 17 June 2005 17:41, Ken Schneider wrote:
On Fri, 2005-06-17 at 17:29 -0400, B. Stia wrote:
On Friday 17 June 2005 08:32, Ken Schneider wrote:
Can you also show the results of df?
Ken,
Following is output of df:
EasyStreet:/ # df -ah /* Filesystem Size Used Avail Use% Mounted on /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% / ...............<snip restof output>..........
Wow, 15 entries for /. There should only be one. Something is radically wrong here. Try booting to the rescue DVD/CD and running fsck on /dev/hdb1 and see if anything shows up there.
Ken, Already did that twice in the rescue mode repair system but will try again.
It's almost as though there is some corruption going on with the hard drive or a flaky power supply causing intermittent problems. Try removing the /etc/mtab file while in rescue mode, if it exists.
Ummm...OK but does that file regenerate itself? Power supply is only a few months old and is way oversize for the systm. (450W)
You will need to mount /dev/hdb1 to /some_mount_point while booted in rescue mode to look for it. Something like: mount /dev/hdb1 /mnt rm /mnt/etc/mtab (there will be an error if it does not exist and it shouldn't if you are not booted to the hard drive) umount /mnt
And then reboot to the hard drive I assume ?
Also look in /lost+found and see if anything is there as it would indicate file system problems as well and show faulty disk usage.
Nothing in lost & found, nor trash. Carlos, Checked both fstab & mtab. Both appear to be normal. No multiple entries. Remember now, I did a kernel upgrade a few days ago. The / directory may have been running at 98% and functioning (as it is now) until I trashed an old kdar backup as root. That put me "over the top" 100%. Now, when I cleaned out the trash I was able to log in again with X. That was what prompted my original message about the trash. I did see the / directory drop back to 16% though at that time. Since then, thinking I was OK, I did my kdar backups ( as root,but to another hard drive) Then I saw again that the / partition was almost full again. Other ideas re: kernel upgrade / kdar ? And, I still am the only user who cannot log-in to the KDM screen. Have to drop back to a console and startx. Bob S.
On Friday 17 June 2005 17:41, Ken Schneider wrote:
On Fri, 2005-06-17 at 17:29 -0400, B. Stia wrote:
On Friday 17 June 2005 08:32, Ken Schneider wrote:
Can you also show the results of df?
Ken,
Following is output of df:
EasyStreet:/ # df -ah /* Filesystem Size Used Avail Use% Mounted on /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% /
...............<snip everthing>.............. Wellllllll.....I cured it - not solved it. In my last just recently posted message I speculated about the kernel and kdar. Decided to check. I stated that after doing another kdar backup (4 files) the problem returned. Remember now, the backup was done by root to a different hard drive. I went in and deleted the files one by one on the other hard drive and watched the / directory diminish in size with KDiskFree. After deleting them all, my / directory returned to it's mormal size. The df command was also normal showing only one hdb1 posting. Strange !! Seems impossible. Has to be some kind of bug. Guess I won't be using kdar anymore unless I burn the file to disks and then delete them. Too bad. I thought putting my backups on another hard drive would be a great thing to do. Still wonder if it has anything to do with the kernel upgrade. Used to work just fine. Hope this will be helpful to people who might run into this same problem. BTW, still have the problem of not being able to log in via the KDM log in dialogue, where my other users can. That is a hold-over from the original problem. (see previous post) Would appreciate any help on solving that. Bob S.
On Sat, 2005-06-18 at 03:09 -0400, B. Stia wrote:
On Friday 17 June 2005 17:41, Ken Schneider wrote:
...............<snip everthing>..............
Wellllllll.....I cured it - not solved it. In my last just recently posted message I speculated about the kernel and kdar. Decided to check.
I stated that after doing another kdar backup (4 files) the problem returned. Remember now, the backup was done by root to a different hard drive. I went in and deleted the files one by one on the other hard drive and watched the / directory diminish in size with KDiskFree. After deleting them all, my / directory returned to it's mormal size. The df command was also normal showing only one hdb1 posting. Strange !! Seems impossible. Has to be some kind of bug.
Guess I won't be using kdar anymore unless I burn the file to disks and then delete them. Too bad. I thought putting my backups on another hard drive would be a great thing to do. Still wonder if it has anything to do with the kernel upgrade. Used to work just fine. Hope this will be helpful to people who might run into this same problem.
BTW, still have the problem of not being able to log in via the KDM log in dialogue, where my other users can. That is a hold-over from the original problem. (see previous post) Would appreciate any help on solving that.
Bob S.
I tried using kdar a couple of times and had nothing but trouble with it crashing and leaving incomplete backup files behind. I have since moved to mondo/mindi (SuSE 9.3) for doing backups. I really like the disaster recovery function it provides. As far as the KDE thing goes, have you tried moving your .kde to .kde.old (while logged in as root) and then login in again? This will show whether or not there is some corrupt config file. Also, try logging in using a different WM and see if you have problems. This too can point to problems with a .kde config file. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
On 2005-06-18 09:09 +0200, B. Stia wrote:
Wellllllll.....I cured it - not solved it. In my last just recently posted message I speculated about the kernel and kdar. Decided to check.
I stated that after doing another kdar backup (4 files) the problem returned. Remember now, the backup was done by root to a different hard drive. I went in and deleted the files one by one on the other hard drive and watched the / directory diminish in size with KDiskFree.
How did you delete them, using 'kdar', or 'rm'? I don't understand how deleting a file in a drive can have effect on another disk ussage... unless kdar does some kind of association "he" is aware of :-?
After deleting them all, my / directory returned to it's mormal size.
The df command was also normal showing only one hdb1 posting. Strange !! Seems impossible. Has to be some kind of bug.
"Next" time, try 'df /', not 'df /*'.
Guess I won't be using kdar anymore unless I burn the file to disks and then delete them. Too bad. I thought putting my backups on another hard drive would be a great thing to do. Still wonder if it has anything to do with the kernel upgrade. Used to work just fine. Hope this will be helpful to people who might run into this same problem.
Weird. I think you should report this to feedback, or to the author. Kdar must be using temporary space somewhere.
BTW, still have the problem of not being able to log in via the KDM log in dialogue, where my other users can. That is a hold-over from the original problem. (see previous post) Would appreciate any help on solving that.
I don't know... -- Cheers, Carlos Robinson
On Sat, 2005-06-18 at 22:59 +0000, Carlos E. R. wrote:
On 2005-06-18 09:09 +0200, B. Stia wrote:
I don't understand how deleting a file in a drive can have effect on another disk ussage... unless kdar does some kind of association "he" is aware of :-?
After deleting them all, my / directory returned to it's mormal size.
The df command was also normal showing only one hdb1 posting. Strange !! Seems impossible. Has to be some kind of bug.
"Next" time, try 'df /', not 'df /*'.
Why not just use df without any arguments? It will show the usage of all mounted filesystems. df / will only show the root filesystem usage. -- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998 "The day Microsoft makes something that doesn't suck is probably the day they start making vacuum cleaners." -Ernst Jan Plugge
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Sunday 2005-06-19 at 07:39 -0400, Ken Schneider wrote:
"Next" time, try 'df /', not 'df /*'.
Why not just use df without any arguments? It will show the usage of all mounted filesystems. df / will only show the root filesystem usage.
Ah, yes, of course: you are right. As a matter of fact, I use "df -h" myself (it gives the sizes in "human readable format"). - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFCtguhtTMYHG2NR9URAv1JAJwPSB5V0/Yh1gnjlFvx21HCpnu67gCfXFJo dyI267LUtYEfr+lKVYzWrtY= =P8Ju -----END PGP SIGNATURE-----
On Saturday 18 June 2005 18:59, Carlos E. R. wrote:
On 2005-06-18 09:09 +0200, B. Stia wrote:
Wellllllll.....I cured it - not solved it. In my last just recently posted message I speculated about the kernel and kdar. Decided to check.
I stated that after doing another kdar backup (4 files) the problem returned. Remember now, the backup was done by root to a different hard drive. I went in and deleted the files one by one on the other hard drive and watched the / directory diminish in size with KDiskFree.
How did you delete them, using 'kdar', or 'rm'?
Hello Carlos, Deleted them using rm. Funny thing is if I used the GUI and put them in the trash there was no change.
I don't understand how deleting a file in a drive can have effect on another disk ussage... unless kdar does some kind of association "he" is aware of :-?
I dunno Carlos. Beats me. I even duplicated the process by building new Kdar files and deleting them, all the while watching my / directory. Happened again. Be nice if someone else could duplicate the problem. Now, I am not sure, but I don't believe this happened before the latest kernel upgrade.
After deleting them all, my / directory returned to it's mormal size.
The df command was also normal showing only one hdb1 posting. Strange !! Seems impossible. Has to be some kind of bug.
Welllll.. what seems impossible is that the / directory would grow when writing to a completely different hard drive. Anyway, I know now what to avoid in creating future problems of this type. You know the saying. "Burn me once, shame on you. Burn me twice, shame on me."
"Next" time, try 'df /', not 'df /*'.
Bob S.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2005-06-20 at 01:35 -0400, B. Stia wrote:
How did you delete them, using 'kdar', or 'rm'?
Hello Carlos, Deleted them using rm. Funny thing is if I used the GUI and put them in the trash there was no change.
Well, that's obvious, the trash is in fact another directory. Files sent to the trash are just moved, not deleted.
I don't understand how deleting a file in a drive can have effect on another disk ussage... unless kdar does some kind of association "he" is aware of :-?
I dunno Carlos. Beats me. I even duplicated the process by building new Kdar files and deleting them, all the while watching my / directory. Happened again. Be nice if someone else could duplicate the problem. Now, I am not sure, but I don't believe this happened before the latest kernel upgrade.
Dunno... - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFCtqVLtTMYHG2NR9URAi+cAJ9JSgfWMA8YbBYQH1jkIeoyDEQMAQCgjJNO E2ILjysqAyweW/RUv9De27M= =fwSW -----END PGP SIGNATURE-----
B. Stia wrote:
Welllll.. what seems impossible is that the / directory would grow when writing to a completely different hard drive.
Is your /tmp on the same partition? It probably creates temporary files there before copying to the partition you selected. Just a guess. -- Joe Morris New Tribes Mission Email Address: Joe_Morris@ntm.org Registered Linux user 231871
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2005-06-20 at 10:22 -0500, Joe Morris (NTM) wrote:
B. Stia wrote:
Welllll.. what seems impossible is that the / directory would grow when writing to a completely different hard drive.
Is your /tmp on the same partition? It probably creates temporary files there before copying to the partition you selected. Just a guess.
True. Yast backup does just that. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFCt1pTtTMYHG2NR9URAiW2AJ43Av1WHOWDlGevYynE8gXrqZROaACfTkYm NMzatQ+WBUXZZw+itP8UvlI= =NoA0 -----END PGP SIGNATURE-----
On Monday 20 June 2005 11:22, Joe Morris (NTM) wrote:
B. Stia wrote:
Welllll.. what seems impossible is that the / directory would grow when writing to a completely different hard drive.
Is your /tmp on the same partition? It probably creates temporary files there before copying to the partition you selected. Just a guess. --
Hi Joe, Do you mean are /tmp & / on the same device? Yes hdb1. But I can go look directly at /temp and there is nothing unusual there. (unless they are hidden and I didn't check that) In fact I looked at all of the partitions on hdb1. Nothing unusual. Whatever it is doesn't go away, even with reboots. Beats me, and I don't know enough to investigate further. Doesn't matter though except for academic value, because I just won't use kdar anymore. Always willing to hear suggestions from you though. Bob S.
B. Stia wrote:
Do you mean are /tmp & / on the same device? Yes hdb1. Yes, that is what I meant. What do you have set up for your Archive storage directory under the General options in the kdar settings? That is where I believe it will save it's temporary files. But I can go look directly at /temp and there is nothing unusual there. Mine is in my home directory, perhaps yours is as well. Whatever it is doesn't go away, even with reboots. That is understandable. Temp files will stay until deleted. Doesn't matter though except for academic value, because I just won't use kdar anymore. I haven't used it yet, but it looks interesting. Too bad it quit working for you. -- Joe Morris New Tribes Mission Email Address: Joe_Morris@ntm.org Registered Linux user 231871
On Sat, 2005-06-18 at 15:59, Carlos E. R. wrote: > On 2005-06-18 09:09 +0200, B. Stia wrote: > > > Wellllllll.....I cured it - not solved it. In my last just recently > > posted message I speculated about the kernel and kdar. Decided to > > check. > > > > I stated that after doing another kdar backup (4 files) the problem > > returned. Remember now, the backup was done by root to a different > > hard drive. I went in and deleted the files one by one on the other > > hard drive and watched the / directory diminish in size with > > KDiskFree. > > How did you delete them, using 'kdar', or 'rm'? > > I don't understand how deleting a file in a drive can have effect on > another disk ussage... unless kdar does some kind of association "he" > is aware of :-? > > > After deleting them all, my / directory returned to it's mormal size. > > > > The df command was also normal showing only one hdb1 posting. > > Strange !! Seems impossible. Has to be some kind of bug. > > "Next" time, try 'df /', not 'df /*'. > OR try > df -alh /* | sort | uniq - 0 0 0 - /sys /dev/hda10 69M 5.6M 60M 9% /boot /dev/hda3 5.8G 4.0G 1.5G 73% / /dev/hda4 9.7G 8.6G 1.1G 89% /home Filesystem Size Used Avail Use% Mounted on proc 0 0 0 - /proc It puts the headder out of place but at least the duplicates are eliminated. -- ___ _ _ _ ____ _ _ _ | | | | [__ | | | |___ |_|_| ___] | \/
Carl, On Monday 20 June 2005 21:01, Carl William Spitzer IV wrote:
...
"Next" time, try 'df /', not 'df /*'.
OR try
df -alh /* | sort | uniq
Well, if you're going to do that, just use the "-u" option to sort: % df -ah /* |sort -u /dev/sda1 12G 9.7G 1.8G 86% /root91 /dev/sda2 12G 5.6G 5.9G 49% /home /dev/sda3 12G 243M 12G 3% /dar Filesystem Size Used Avail Use% Mounted on LABEL=Root93 20G 11G 9.5G 53% / proc 0 0 0 - /proc sysfs 0 0 0 - /sys Of course, the displacement of the header line is unsightly... Randall Schulz
Ken, On Friday 17 June 2005 14:41, Ken Schneider wrote:
On Fri, 2005-06-17 at 17:29 -0400, B. Stia wrote:
On Friday 17 June 2005 08:32, Ken Schneider wrote:
Can you also show the results of df?
Ken,
Following is output of df:
EasyStreet:/ # df -ah /* Filesystem Size Used Avail Use% Mounted on /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb8 2.6G 326M 2.2G 13% /data /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb9 2.7G 33M 2.5G 2% /hdabkup /dev/hdb3 5.4G 1.1G 4.0G 21% /home /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb5 7.7G 33M 7.3G 1% /newlinux /dev/hdb4 1.5G 824M 570M 60% /opt proc 0 0 0 - /proc /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb1 2.0G 1.9G 30M 99% / - 0 0 0 - /sys /dev/hdb1 2.0G 1.9G 30M 99% / /dev/hdb7 3.3G 2.8G 283M 91% /usr /dev/hdb10 1.5G 516M 885M 37% /var /dev/hdb1 2.0G 1.9G 30M 99% / EasyStreet:/ #
Are more options necessary ? Bob S.
Wow, 15 entries for /. There should only be one.
Not true at all. Try it on your system. When you apply "df" to a directory that is not a mount point, it tells you it's "mounted on" the mount point of the file system to which it belongs. It's unfortunate that df does not include the argument in the output line generated by that argument. Here's the output for my system: Filesystem Size Used Avail Use% Mounted on /dev/sda2 12G 5.6G 6.0G 49% /home LABEL=Root93 20G 11G 9.5G 53% / LABEL=Root93 20G 11G 9.5G 53% / LABEL=Root93 20G 11G 9.5G 53% / LABEL=Root93 20G 11G 9.5G 53% / /dev/sda3 12G 243M 12G 3% /dar LABEL=Root93 20G 11G 9.5G 53% / LABEL=Root93 20G 11G 9.5G 53% / /dev/sda2 12G 5.6G 6.0G 49% /home LABEL=Root93 20G 11G 9.5G 53% / LABEL=Root93 20G 11G 9.5G 53% / LABEL=Root93 20G 11G 9.5G 53% / LABEL=Root93 20G 11G 9.5G 53% / LABEL=Root93 20G 11G 9.5G 53% / LABEL=Root93 20G 11G 9.5G 53% / proc 0 0 0 - /proc /dev/sda2 12G 5.6G 6.0G 49% /home LABEL=Root93 20G 11G 9.5G 53% / /dev/sda1 12G 9.7G 1.8G 86% /root91 LABEL=Root93 20G 11G 9.5G 53% / LABEL=Root93 20G 11G 9.5G 53% / sysfs 0 0 0 - /sys LABEL=Root93 20G 11G 9.5G 53% / LABEL=Root93 20G 11G 9.5G 53% / LABEL=Root93 20G 11G 9.5G 53% / LABEL=Root93 20G 11G 9.5G 53% / (I use XFS and mount my rood directory by label, not device name.)
Something is radically wrong here.
There nothing wrong with this output. Whatever the OP's other symptoms are, they don't relate to anything that can be discerned in the df output he supplied.
...
-- Ken Schneider UNIX since 1989, linux since 1994, SuSE since 1998
Randall Schulz
On 2005-06-18 15:47 +0200, Randall R Schulz wrote:
Wow, 15 entries for /. There should only be one.
Not true at all. Try it on your system. When you apply "df" to a directory that is not a mount point, it tells you it's "mounted on" the mount point of the file system to which it belongs.
It's unfortunate that df does not include the argument in the output line generated by that argument.
I have tried myself. The problem arises when the command line includes an "*", like in "df -ah /*". It is caused by the shell expansion of "/*". The man page explains it: SYNOPSIS df [OPTION]... [FILE]... ... DESCRIPTION This manual page documents the GNU version of df. df displays the amount of disk space available on the file system containing each file name argument. I.e., for each expansion of "*" (for each file given, in this case, in /), df reports the free space on the disk containing it. Redundant. So, yes, you are absolutely right. The output is correct... but confusing. -- Cheers, Carlos Robinson
On Saturday 18 June 2005 09:47, Randall R Schulz wrote:
Ken,
On Friday 17 June 2005 14:41, Ken Schneider wrote:
On Fri, 2005-06-17 at 17:29 -0400, B. Stia wrote:
On Friday 17 June 2005 08:32, Ken Schneider wrote:
Can you also show the results of df?
Not true at all. Try it on your system. When you apply "df" to a directory that is not a mount point, it tells you it's "mounted on" the mount point of the file system to which it belongs.
It's unfortunate that df does not include the argument in the output line generated by that argument.
Here's the output for my system:
Filesystem Size Used Avail Use% Mounted on /dev/sda2 12G 5.6G 6.0G 49% /home
............<snip output>......
(I use XFS and mount my rood directory by label, not device name.)
Something is radically wrong here.
There nothing wrong with this output. Whatever the OP's other symptoms are, they don't relate to anything that can be discerned in the df output he supplied.
Randall, Seems I have a way with generating weird kinds of situations. Your explanation is undoubtedly correct, very instructional, and clarifying. Thanks for that. Appreciated and noted for the future. Regarless of that, although somewhat misleading, the command showed 15? instances of a 98.6% full / directory. That is the weird part. Wish there were an answer to that, but not really important now Bob S.
Bob, On Sunday 19 June 2005 22:50, B. Stia wrote:
On Saturday 18 June 2005 09:47, Randall R Schulz wrote:
...
There nothing wrong with this output. Whatever the OP's other symptoms are, they don't relate to anything that can be discerned in the df output he supplied.
Randall,
Seems I have a way with generating weird kinds of situations. Your explanation is undoubtedly correct, very instructional, and clarifying. Thanks for that. Appreciated and noted for the future.
Regarless of that, although somewhat misleading, the command showed 15? instances of a 98.6% full / directory. That is the weird part. Wish there were an answer to that, but not really important now
I thought I did explain it. For every argument given to the "df" command, it finds the file system that holds that file or directory (assuming the name actually refers to a file or directory) and shows the utilization for that volume, listing its mount-point directory name (completely omitting the argument, which is where the confusion arises). It's a dubious choice, but df has been that way for as long as I can remember. Since many of the entries in / are not mount points, "df /*" produces many repeated occurrences of the output for the root file system.
Bob S.
Randall Schulz
On Monday 20 June 2005 09:36, Randall R Schulz wrote:
Bob,
On Sunday 19 June 2005 22:50, B. Stia wrote:
On Saturday 18 June 2005 09:47, Randall R Schulz wrote:
...
There nothing wrong with this output. Whatever the OP's other symptoms are, they don't relate to anything that can be discerned in the df output he supplied.
Randall,
Seems I have a way with generating weird kinds of situations. Your explanation is undoubtedly correct, very instructional, and clarifying. Thanks for that. Appreciated and noted for the future.
Regarless of that, although somewhat misleading, the command showed 15? instances of a 98.6% full / directory. That is the weird part. Wish there were an answer to that, but not really important now
I thought I did explain it.
For every argument given to the "df" command, it finds the file system that holds that file or directory (assuming the name actually refers to a file or directory) and shows the utilization for that volume, listing its mount-point directory name (completely omitting the argument, which is where the confusion arises).
It's a dubious choice, but df has been that way for as long as I can remember.
Since many of the entries in / are not mount points, "df /*" produces many repeated occurrences of the output for the root file system.
Bob S.
Randall, No, no, not that. Guess I was not very clear. What I meant about the "weird" part was the 98.6% full part. As stated previously I understand what you explained. I'm sorry I put you to the pain of explaining it again. Thanks. You cannot imagine what I have learned from this list over the past few years. Bob S. Bob S.
participants (7)
-
B. Stia -
Carl William Spitzer IV -
Carlos E. R. -
Jeffrey L. Taylor -
Joe Morris (NTM) -
Ken Schneider -
Randall R Schulz