Console woes.

[RaydnMalachi]

I broke my console. I have no idea how, or why, or when, even. I've just noticed that it's been acting really wonky lately.

By wonky, I mean that running certain commands locks the console with no prompt, and accepts no commands.

This behaviour is reproducible on a per-program basis (certain programs / commands ALWAYS do it, others NEVER do).

It does this for all users, and even outside of an X session.

For example, I run:

Code: Select all

 ps aux 

Once it finishes its output, I'm left with no bash prompt, and the console is frozen. Ctrl + C does nothing, and I have to open a new console to execute any sort of commands.

I don't even know where to begin troubleshooting this, so any help would be greatly appreciated.

[El Tazar]

Is this behaviour the same for a console login outside of X, or perhaps an alternative terminal emulator, such as xterm/gnome-term/whatever ?

As you're probably using BASH, could you paste your ~/.bashrc /etc/bashrc and relevant files?

[RaydnMalachi]

Thank you for your prompt reply!

I'm going to consider this problem solved for now, as it doesn't seem to be acting up any more. I rebuilt my kernel this morning, so I'm thinking that must have had something to do with resolving it.

I'll keep you posted if it starts behaving oddly again.

Many thanks,
Rayd'n Malachi.

[RaydnMalachi]

I spoke too soon. Ten minutes later, and it's acting up again. This behaviour is indeed consistent across every terminal emulator I use.

My ~/.bashrc:

Code: Select all

# /etc/skel/.bashrc:
#
# This file is sourced by all *interactive* bash shells on startup,
# including some apparently interactive shells such as scp and rcp
# that can't tolerate any output.  So make sure this doesn't display
# anything or bad things will happen !


# Test for an interactive shell.  There is no need to set anything
# past this point for scp and rcp, and it's important to refrain from
# outputting anything in those cases.
if [[ $- != *i* ]] ; then
	# Shell is non-interactive.  Be done now!
	return
fi

# Enable colors for ls, etc.  Prefer ~/.dir_colors #64489
if [[ -f ~/.dir_colors ]]; then
	eval `dircolors -b ~/.dir_colors`
else
	eval `dircolors -b /etc/DIR_COLORS`
fi
alias ls="ls --color=auto"

# Change the window title of X terminals 
case $TERM in
	xterm*|rxvt*|Eterm)
		PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME%%.*}:${PWD/$HOME/~}\007"'
		;;
	screen)
		PROMPT_COMMAND='echo -ne "\033_${USER}@${HOSTNAME%%.*}:${PWD/$HOME/~}\033\\"'
		;;
esac

My /etc/bash/bashrc:

Code: Select all

# /etc/bash/bashrc
#
# This file is sourced by all *interactive* bash shells on startup,
# including some apparently interactive shells such as scp and rcp
# that can't tolerate any output.  So make sure this doesn't display
# anything or bad things will happen !


# Test for an interactive shell.  There is no need to set anything
# past this point for scp and rcp, and it's important to refrain from
# outputting anything in those cases.
if [[ $- != *i* ]] ; then
	# Shell is non-interactive.  Be done now!
	return
fi

# Bash won't get SIGWINCH if another process is in the foreground.
# Enable checkwinsize so that bash will check the terminal size when
# it regains control.  #65623
# http://cnswww.cns.cwru.edu/~chet/bash/FAQ (E11)
shopt -s checkwinsize

# Set colorful PS1 only on colorful terminals.
# dircolors --print-database uses its own built-in database
# instead of using /etc/DIR_COLORS.  Try to use the external file
# first to take advantage of user additions.
use_color=false
safe_term=${TERM//[^[:alnum:]]/.}	# sanitize TERM

if [[ -f /etc/DIR_COLORS ]] ; then
	grep -q "^TERM ${safe_term}" /etc/DIR_COLORS && use_color=true
elif type -p dircolors >/dev/null ; then
	if dircolors --print-database | grep -q "^TERM ${safe_term}" ; then
		use_color=true
	fi
fi

if ${use_color} ; then
	if [[ ${EUID} == 0 ]] ; then
		PS1='\[\033[01;31m\]\h\[\033[01;34m\] \W \$\[\033[00m\] '
	else
		PS1='\[\033[01;32m\]\u@\h\[\033[01;34m\] \w \$\[\033[00m\] '
	fi

	alias ls='ls --color=auto'
else
	if [[ ${EUID} == 0 ]] ; then
		# show root@ when we don't have colors
		PS1='\u@\h \W \$ '
	else
		PS1='\u@\h \w \$ '
	fi
fi

# Try to keep environment pollution down, EPA loves us.
unset use_color safe_term

[El Tazar]

Hmm, nothing springs into my eyes there. Try pasting some of last few entries of /var/log/emerge.log to see what you've been messing with last. A wild guess could be that this is related with either bash or libc (try reemerging libc then bash)

Another guess: Could this be related to a kernel configuration change you've made?

[RaydnMalachi]

Well, I've managed to isolate the culprit. I'm still not sure why exactly it's happening, though.

It seems like every time I run anything with Wine (even something as simple as winecfg) my consoles go wacky. I don't really know why this is the case, but I've noticed that it happens consistently. A reboot puts everything back to normal, but as soon as I run anything with Wine they start screwing up again.

Any ideas why this might be the case?

[El Tazar]

Which useflags is wine compiled with?

[RaydnMalachi]

Wine, as with most things on my system were compiled with the following, in my make.conf:

Code: Select all

USE="-gtk -gnome qt kde alsa dvd cdr 3dnow radeon sse sse2 mmx mmx2 3dnow 3dnowext"

[El Tazar]

I was thinking of the specific useflags for the wine ebuild, as reported if you do "emerge wine -vp"

[RaydnMalachi]

Ah... my sincere apologies. Here you go!

Code: Select all

app-emulation/wine-0.9.8-r1  +X +alsa +arts +cups -debug -esd +gif +glut -jack +jpeg +lcms -ldap -nas +ncurses +opengl +oss -scanner +truetype +xml2

[El Tazar]

Sorry for the delay, been out for the weekend..

Another longshot, but try rebuilding wine, and if that doesn't help make a revdep-rebuild check