Customized KDE environment slowly dies

[SLK001]

I have customized my KDE environment (just simple stuff, like background, clock, etc) and ran Linux-Live-6.1.5 to create an new build. The build boots fine and everything seems to be in its proper place. When I enter the KDE environment, I can open a terminal and enter a command, such as aircrack-ng (no arguments, it just prints out a help screen). As the session progresses, I slowly lose the ability to run commands.

For instance, entering the command aircrack-ng once more results in this error:

bt ~ # /usr/local/bin/aircrack-ng  Cannot execute binary file.

The command is still there and is still marked as executable. If I am quick enough once this starts to happen, I will usually have enough time to logout of the KDE environment. However, this behavior follows me back to the main terminal environment. Almost any command entered now results in this error. The only commands that will execute seem to be internal bash commands.

It's like I have been slowly bled of any and all privileges. The only way out of this is a reboot.

Entering whoami reveals that I am still "root".

Now, on the otherhand, the flux environment operates correctly for as long as needed (but a working KDE environment is much nicer).

I was hoping that there were linux experts around that had some idea why this was happening.

[DayZiro]

I'm having the same problem, there have been several threads about this but no one seems to know what causes it. It starts out normal, but after a few minutes every program locks up. All but the ones you've used before. What I normally do is run airodump-ng, cp, ls, aireplay-ng, aircrack, etc with no arguments as soon as I get into a terminal, which seems to 'reserve' them so they can be used when I need them. This leads me to believe there is a leak somewhere. Like the system runs out of RAM or inodes run out (which causes the system to not be able to tell the permissions on the file). I have a perl script from a linux magazine that will list the directories with the most inodes, allowing you to track down abuse, but I can't seem to get it to work. I'm relatively new to linux and don't know any perl.

#!/usr/bin/perl -w

my $start=$ARGV[0];

foreach $object (`find '$start`){
	my @parts=split(/\//,$object);
	while(pop(@parts)  ){
		my $object = join('/',@parts);
		$object =~ s/\/+/\//g;
		$object2qty{$object}++;
	}
}

foreach $object (sort { $object2qty{$a} <=> $object2qty{$b} }
			keys %object2qty){
	print $object2qty{$object} . "\t${object}\n";
}

the problem in the script seems to be around line 5 (foreach). The original probably isn't inodes anyway.

Any other ideas what could cause this problem?

[SLK001]

It turns out this problem is due to "user/owner" issues. When I looked at the "/" directory, it was mostly "root/root", except for /boot.

I fixed this by changing the "config" file found under BT/tools/WIN directory to this:

-v
-J
-R
-D
-uid 0
-gid 0
-no-emul-boot
-boot-info-table
-boot-load-size 4 
-b "boot/isolinux/isolinux.bin"
-c "boot/isolinux/isolinux.boot"

This corrected the permissions and stopped all the "slow deaths". If you use the .sh to create your .iso, you will need to change the .sh to reflect the property issues.

[DayZiro]

just to update, my problem was different. It turned out to be my dvd drive. After a few minutes without access, the drive would just fail to read data.

Personally, my drive worked when i physically shook the laptop-the drive would spin right up. This wasn't a BT thing because it worked in both debian and xp.

Lesson learned? Screw hp and buy a thinkpad.

PS: that glitch was a bitch to debug