User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0 Build Identifier: We had an overloaded AFS (www.openafs.org) network filesystem directory. When executing: 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 Expected Results: 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: cd /path/to/slow/dir ls | wc -l was hanging konsole. But no problem with ls /path/to/slow/dir | wc -l Achim
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 ***