segmentation fault question
 

I downloaded a bunch of stuff to /tmp/download. now my /tmp filesystem is hosed. I did a du -h at one point, and it said there was 1.1T of space used...and it is 3.8G filesystem!! hmm, guess I'll know better next time not to leave my FTP client up pulling stuff down overnight!

anyhow, anytime I go into /tmp and try to ls or du, I get this error:

kernel: Assertion failure in do_get_wirte_access() at transaction.c:706: "handle->h_buffer_credits > 0"

after this error message, my system is pretty locked up. can't even shut it down cleanly. so, I'd like to fix whatever I did.

any ideas what the frick I did? I guess I would be ok with deleting the fileysystem and recreating it, but any other solutions welcome.

If you can, have you thought about mount /tmp on a separate, much larger partition to see if that would help at all?

it is probably a stack overflow, what kernel are you using? if it's an old one, that could be a problem. do you have write access to /tmp in the account you are logged on with? your computer is probably locking up because the kernel is to busy trying to process with corrupted stacks.

ok, I have 2.4.17 (default) and the 2.4.18 kernels configured. both hose when I do anything with /tmp. I can't delete files within tmp, can't do a du within tmp, and if I do, the system requires a hard shutdown (that is to say, power off is the only option). no doubt I'll corrupt other file systems if that practice continues. at this point. I would like to delete /tmp, and re-create it. I can only hope this fixes the problem.

how do I get to a point where I can umount /tmp. it is always a busy device (I suspect the system stores tmp stuff there...).

anyhow, a procedure for deleting the /tmp filesystem, and then recreating it would be appreciated. here is the /tmp line from my /etc/fstab:

LABEL=/tmp /tmp ext3 defaults 1 2

thanks in advance!

why are you mounting a directory? does /tmp contain a partition? perhaps there is something conflicting between the two versions of the kernels? can you delete the old one and use the newer one as the default?

/tmp is its own partition. the tmp filesystem is on its a partition that happens to have a label of /tmp. I am going to boot to partiion magic, deletel the /tmp partition, re-create it and I'll post my results. I had just hoped there was an easier way to solve this problem, but I can't spend my whole month worrying about this. I'll hope to post an update by the end of the day.

instead of /etc/fstab, I should have included stdout from df -h. here it is:

Filesystem Size Used Avail Use% Mounted on
/dev/hda1 3.9G 2.2G 1.5G 59% /
/dev/md0 7.7G 6.6G 816M 90% /backup
/dev/hda3 8.1G 1.7G 6.0G 21% /data
/dev/hda2 12G 7.0G 4.5G 61% /home
/dev/sda1 2.0G 2.0G 0 100% /mp3
none 251M 0 250M 0% /dev/shm
/dev/hda7 3.9G 3.4G 373M 91% /tmp
/dev/hda5 3.9G 2.5G 1.2G 67% /usr
/dev/hda6 3.9G 643M 3.1G 17% /usr/local

now the problem is that I cannot delete /dev/hda7 with partition magic 6.0, because it does not recognize ext3 filesystems....argh! so, how can I blow away /dev/hda7, and then re-create it? any help appreciated, thanks.

Use Linux fdisk (or parted). Before this I'd try to run fsck on your /tmp partition. It may help.

how do I umount /tmp? it is always busy. I cannot cleanly shut down my computer, because the /tmp filesystem is hosed. so, given that I turn off the power, and reboot, how do I boot to a mode where I can fsck /dev/hda7?

when i try to fsck now, it says that Running e2fsck on a mounted filesystem may cause SEVERE filesystem damage. is this really a concern since the filesystem is already hosed?

It sounds like you can't umount because you are getting the device busy message, right?

Just a suggestion, but if you can boot cleanly, use telinit to drop into single user. This should stop any access of /tmp by other processes. Then umount.

Don't know if it'll work. Don't really have enuf info.

If its busy try running "fuser" on it's contents and itll tell you what processes have stuff in use in /tmp

Run fsck from an installation cd.

thanks, got it. all is well ;-)