User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0
We had an overloaded AFS (www.openafs.org) network filesystem directory.
cd /afs/our-cell/path/to/overloaded/dir # required a long time to finish
ls | wc -l
now konsole was not responding for several minutes: Not possible to switch to other
tabs or to open new Tabs. Keyboard input is ignored too in all konsole windows.
Cursor always invisible as long as above the konsole window. Konsole did not die with
click on [x] in window border or when kwin asked if the window should be killed.
On the other hand executing the 'equivalent':
ls /afs/afs-cell/path/to/overloaded/dir | wc -l
and konsole was still responsive, nothing blocked. No problem at all.
I guess that konsole does something like a blocking getcwd() to update
tab and/or window title. Depending how slow overloaded the (network)
filesystems all konsole windows and tabs seem to be dead. (In our case
30 sec to several minutes)
Reproducible: Didn't try
Konsole should not block all other konsole windows and tabs when the filesystem in one tab is very slow to respond.
I've created a new profile and set in 'Tabs' Tab title format and remote tab title format to empty strings. Didn't help:
ls | wc -l
was hanging konsole. But no problem with
ls /path/to/slow/dir | wc -l
Thanks for reporting.
Your guessing is unfortunately right. Konsole reads the symbolic link /proc/<pid>/cwd to know the current directory. That is a blocking operation. When the current directory is on a remote filesystem and the network connection is bad or lost, konsole is just frozen.
The specific title format does not make difference here, because Konsole always need to know the current directory so that other features can work as expected, such as "open new tab in current directory" and "open filemanager here".
See bug 251351 and bug 279133.
*** This bug has been marked as a duplicate of bug 251351 ***