rdesktop locks keyboard

Bug #81854 reported by Soroosh Radpoor
92
This bug affects 11 people
Affects Status Importance Assigned to Milestone
rdesktop (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: rdesktop

After a network fail rdesktop locks keyboad and I have to kill rdesktop from a remote dektop or a tty.( When network is disconnected you will see a black screen and if you press a single key, keyboard is locked.) And I think it should be another bug in X server that allows an application to lock keyboard .

Revision history for this message
Luxor (ranju-mathew) wrote :

I am experiencing similar problems, but haven't verified that it is triggered by a network failure. But once triggered, I have to minimize the rdesktop window to regain keyboard focus for other applications. If I restore the rdesktop window, keyboard is again locked, and the entire rdesktop window is completely blank (white). Pressing the close button on the rdesktop window does not work after this happens, and I must kill the process from a terminal. Please let me know if I need additional information.
Thanks

Luxor (ranju-mathew)
Changed in rdesktop:
status: New → Confirmed
Revision history for this message
Trevor Nightingale (trevornightingale) wrote :

I am also experiencing this problem.

I do not believe that this problem is due to network problems, however, I have not yet pinpoint what the cause is. I am able to use resktop for a variable amount of time, sometimes a couple of minutes, sometimes for an hour before this problem occurs. Mouse movement is fine, but the keyboard is unresponsive.

I am using an up to date Feisty and rdesktop 1.5.0.

I am not sure what has changed as I only noticed this problem starting a couple of weeks ago.

Regards,
Trevor

Revision history for this message
Peter Valdemar Mørch (pmorch) wrote :

I think this thread is about this too:
http://ubuntuforums.org/showthread.php?p=4483671

Revision history for this message
Luxor (ranju-mathew) wrote :

I've tracked the problem to redirecting sound to the rdesktop client. For example, 'rdesktop -u <username> -p <password>-a 16 -r sound:local -bCNzPg 1600x1110 <terminal server>. Whenever a sound event is sent to rdesktop, there is a high probability of rdesktop crashing. Disabling sound seems to keep the rdesktop client from crashing: 'rdesktop -u <username> -p <password>-a 16 -bCNzPg 1600x1110 <terminal server>. I've had a client up for weeks with the sound disabled.

Revision history for this message
Rekster (derek-vaxxine) wrote :

It does not have to do with sound redirection per say. I have disabled the audio redirect and it srill randomly freezes so I have to switch to console and kill the rdesktop process to be able to do anything at all in my gui. Is anyone looking at this problem even, it's starting to really drive me crazy. When i was using the old LTS it didn't have this problem, now with 8.04 it seems to be a common bug for a lot of people. And the behaviour is pretty much identical from what I'm reading of others descriptions.

Also, is there any logging for rdesktop that I can look at to help diagnose the problem as well?

Revision history for this message
Ken Foskey (foskey) wrote :

I have a definite cause for keyboard lock.

Using the "Terminal Server Client" I have DHCP on my network and my laptop gets a different IP address everytime the router is reset. It changes IP from 20 to 21 for example. Pressing backspace and then 1 opens the dropdown in TSClient. While the TSClient is dropped the keyboard just totally locks and you cannot work the keyboard at all. Only option is to jump to tty and kill rdesktop, when you return to the desktop you will see a disconnected screen with the IP addresses displayed.

Process to unlock is:

Ctrl-Alt-F1 (jump to terminal mode)
sign in
ps -fu username | grep rdesktop
    look for the process number is second column, eg 1234
kill 1234
exit
Ctrl-Alt-F8 (May be F7 or F9 not sure why, get back to your graphical session)
    You should see and reconnect box and a phantom list of IP addresses.
hit cancel.
   You should see the terminal services box now with the IP box expanded,
click on you IP (to close the drop box).
click OK as you normally would
    Everything should be OK now.

I have experienced the 'Network lockup' however Ctrl-Enter always works and I hit X at top right and then reconnect and everything comes back. This happens when I change the IP address on my desktop, I have a problem with network manager at present requiring a manual config.

Revision history for this message
Ken Foskey (foskey) wrote :

Sorry just reread this...

open ip address drop box on TSclient.
click OK (don't close drop box)
Rdesktop connects but keyboard does not work at all, not even Ctrl-Alt-Enter.

Ctrl-Enter above should be ctrl-alt-enter as well, sorry.

Revision history for this message
Chris (chrislazari) wrote :

Hi All,

I have recently upgraded to Intrepid Ibex and I am still experiencing the same issue as before.

Although we are able to work around this using CTRL+ALT+F1 and killing the process the issue is that it needs to be resolved.

As I am a sysadmin for most of my day rdesktop is probably the utility I use the most and having it freeze up my session every couple of logons is frustrating.

Does anyone know if anything is being done about this?

Regards

Chris

Revision history for this message
Rekster (derek-vaxxine) wrote :

Hey Chris, I have not heard of any updates either regarding this. It seemed to happen a lot more on my Ferrari 4000 laptop than it does on my desktop unit. However when it locks up on my desktop, my keyboard won't even work so I cant get to another console to kill the process. It seems to me that rdesktop has some strange bugs, I hope there is updates sometime soon!

Revision history for this message
Mr. Mike (mike-himikeb) wrote :

I'm seeing this, too. I have my sound set on "Don't Play", I'm connecting using the Cisco VPN 4.8.02 (was using 4.8.01 & seeing the same thing).

It almost always happens when I have shift and/or control and am moving the cursor.

Once, I had to toggle to console to kill it, other times, it just hangs and comes back, and once, I was able to kill it from another window within X.

Theory: It happens when you send too many key messages while it is still repainting the screen?
This is rdesktop 1.6.0, spawned by tsclient 0.150, running on Intrepid.

Revision history for this message
Ken Foskey (foskey) wrote : Re: [Bug 81854] Re: rdesktop locks keyboard

On Thu, 2008-11-20 at 08:49 +0000, Mr. Mike wrote:

> I'm seeing this, too. I have my sound set on "Don't Play", I'm
> connecting using the Cisco VPN 4.8.02 (was using 4.8.01 & seeing the
> same thing).
>
> It almost always happens when I have shift and/or control and am moving
> the cursor.
>
> Once, I had to toggle to console to kill it, other times, it just hangs
> and comes back, and once, I was able to kill it from another window
> within X.
>
> Theory: It happens when you send too many key messages while it is still repainting the screen?
> This is rdesktop 1.6.0, spawned by tsclient 0.150, running on Intrepid.

I have seen lockups when using rhythmbox and allowing sound to go back
to the main system. This caused the keyboard to lock for a period of
time as the system became confused about what it was doing and took a
while to come back.

I changed settings to play sound on remote computer and I have not had
any issues since.

My main reason for the keyboard locking is using the tsclient and
leaving the IP drop box open. This fully locks the keyboard 100% of the
time. Jumping to a text terminal and killing rdesktop brings back the
system.

--

Ken Foskey

Revision history for this message
Erik Engstrom (eengstrom) wrote :

I can confirm what Ken says above. If I connect to a remote server while rhythmbox is running, and I have "Remote Computer Sound" set to play on the local computer the keyboard locks and I have to kill the rdesktop process to get it back. If I change "Remote Computer Sound" to do not play, and reconnect it works just fine.

Erik

Revision history for this message
Chris (chrislazari) wrote :

Hi All,

It seems there are two issues here: the rhythmbox and the IP address dropdown.

I can not comment on the rhythmbox issue but can confirm what Ken says above.

You must ensure before you click connect that the drop-down list of IP addresses is not expanded. What I have done as a force of habit is mouse-click on another field before clicking connect and I have not had an issue since. To ensure that it had not just gone away I tried it with the drop-down list expanded and it froze eveytime.

Thanks Ken for the help on this.

Regards

Chris

Revision history for this message
Fülöp Róbert (fulopr) wrote :

Hi All,

Really this the solution? :) I have to use rdesktop to work and it really uncomfortable to kill process and try again. I found that if I turn off the moving actions on the last tab It works fine, so maybe this is another workaround. But on a difficult screen I miss this function too... I think that Mr Mike is right:
"Theory: It happens when you send too many key messages while it is still repainting the screen?"

I will try this "force mouse click" it can be a simple solution if it will work...

Revision history for this message
Ken Foskey (foskey) wrote :

Using Terminal Server client

- Turn off sound coming to your desktop. Sound transfer from rdesktop
and a pulse application eg rhythmbox is broken.

- ensure that when you select you system using the drop down combo box
that you close the drop down properly. My laptop is on dhcp and it
moves about a bit ip 20, 21, 22. If I select the new IP and leave the
drop down open and click OK the keyboard is locked.

--
Ken Foskey

Revision history for this message
Bassu Khan (bashukhan) wrote :

I've a similar problem with rdesktop but with the one more issue it has with the session freezings, as stated in https://bugs.launchpad.net/ubuntu/+source/rdesktop/+bug/217868

Tried enabling/disabling different features and compiled other versions as well.

Ubuntu needs to learn more discipline about Linux rdesktop!

Revision history for this message
Ken Foskey (foskey) wrote : what does 'Learn more discipline' mean?

Bassu Khan <email address hidden> wrote:

> Ubuntu needs to learn more discipline about Linux rdesktop!

I have no idea what this means. There is nothing in that statement
that says what you have changed or by doing so what changed with
rdesktop.

Could you please describe what you did and what it changed with
specifics.

Thanks
Ken

Revision history for this message
Bassu Khan (bashukhan) wrote :

Ken
> Could you please describe what you did and what it changed with
specifics. Thanks Ken

Sorry for being harsh but later I found that rdesktop has a lot of issues in most recent Linux distributions. Here's how!
I usually interact with RDCs a lot on daily basis. I've been facing the issues with rdesktop from a lot of time. Rdesktop freezes, hangs, becomes unresponsive, acts slow or either stops after 10-15 mins of inactivity and/or with keyboard or session locks up. This has been duplicated in Ubuntu (all lastests) and Fedora 10.
Tried running latest version 1.60, manually compiled earlier versions, disabled GUI stuff, tried changing networks, happens while rdc'ing local Windows machines; in fact tried whatever i could do but no luck. Happens on all of my machines in all networks.

Thanks.

Revision history for this message
Rekster (derek-vaxxine) wrote : Re: [Bug 81854] Re: rdesktop locks keyboard

I concur, although I can only base this on experiences with Ubuntu as I haven't
toyed with too many other distributions in the last few years. It's so
bizarrely random as well that it can be extremely frustrating.

The only time it has NOT been random is when I noticed there is a 'hiccup' in
network functionality for known reasons. When this happens, the entire
rdesktop locks up. My thoughts are there should be much better methods of
handling hiccups rather than just letting the session freeze up (and maybe
eventually timeout). Perhaps an indication there is a network issue and then
the ability to close/restart the session? As it is now, a full screen RDP
session that freezes up causes the entire X GUI session to be locked. The
solution is to switch to a virtual console, login, detemine the process ID and
then manually kill the process, and then switch back to the GUI and restart the
rdp connection. A major pain in the you know what..

I do appreciate the hard work of developers, especially in an open source world,
so I will cross my fingers that there is more work put into this project.

Thanks.

    Quoting Bassu Khan <email address hidden>:

> Ken
> > Could you please describe what you did and what it changed with
> specifics. Thanks Ken
>
>
> Sorry for being harsh but later I found that rdesktop has a lot of issues in
> most recent Linux distributions. Here's how!
> I usually interact with RDCs a lot on daily basis. I've been facing the
> issues with rdesktop from a lot of time. Rdesktop freezes, hangs, becomes
> unresponsive, acts slow or either stops after 10-15 mins of inactivity and/or
> with keyboard or session locks up. This has been duplicated in Ubuntu (all
> lastests) and Fedora 10.
> Tried running latest version 1.60, manually compiled earlier versions,
> disabled GUI stuff, tried changing networks, happens while rdc'ing local
> Windows machines; in fact tried whatever i could do but no luck. Happens on
> all of my machines in all networks.
>
> Thanks.
>
> --
> rdesktop locks keyboard
> https://bugs.launchpad.net/bugs/81854
> You received this bug notification because you are a direct subscriber
> of the bug.
>

------[ This message was sent using Vaxxine Webmail ]------
www.vaxxine.com - Niagara's Premier Internet Service Provider

Revision history for this message
Bassu Khan (bashukhan) wrote :

One more thing I've noticed, the session timeouts more quickly if left inactive in a minimized window whether its KDesktop or Gnome!

Revision history for this message
Mr. Mike (mike-himikeb) wrote :

Let me clarify my problem, because I think we may now be discussing 3 different issues that cause problems.

First, "rdesktop", as this bug relates to, does not seem to have a UI with a drop-down. I think you might be confusing "tsclient", which is a nice wrapper and spawns an rdesktop session. From a terminal, run: "tsclient" and connect, and from a 2nd terminal, run: "ps fax | less" and you will see. newbies: don't type the quotes :)

Second, the sound issue: I am using -rsound:off so if we ARE talking about that, then *I* am posting to the wrong place.

Finally, the issue I was seeing when I posted, which for me, I can recreate my "hang" with the following almost every time:
1) Connect to work with Cisco VPN Client 4.8.something.
2) Launch the following from an icon on my desktop:
   rdesktop -T'my-work-computer - Terminal Server Client' -umrmike -dcsg -g1260x940 -a15 -rsound:off -rclipboard:PRIMARYCLIPBOARD -b -5 xpbox.my.company.loc
   {On VPN, we have our own top-level domain server I guess, to explain the not-ending-in .com name}
3) Using rdesktop, Open Notepad, and enter several lines of text, like alksdflskdjf over and over
4) Position the cursor somewhere in the middle of the lines, and hold down the shit-key to select a range of text.
5) press-AND-HOLD (important!!) cursor-up or cursor-down until it repeats
6) after 1 or 2 lines get selected, key-entry is denied. The cursor in notepad IS STILL BLINKING, but my keyboard is non-responsive within the rdesktop window, but after about 15-30 seconds (usually) my buffered key-pressed get applied, and functionality returns to normal.
I could not recreate this when connecting, using a similar rdesktop line, to a windows OS running within VirtualBox/host networking on the same machine, so maybe it has something to do with the speed of the network over which rdesktop is connected.

Revision history for this message
Ken Foskey (foskey) wrote :

On Sun, 2009-03-22 at 17:43 +0000, Mr. Mike wrote:

> Let me clarify my problem, because I think we may now be discussing 3
> different issues that cause problems.
>
> First, "rdesktop", as this bug relates to, does not seem to have a UI
> with a drop-down. I think you might be confusing "tsclient", which is a

This is true,
https://bugs.launchpad.net/ubuntu/+source/tsclient/+bug/347039

Also note another bug regarding full screen mode and graphics effects
conflicting:

https://bugs.launchpad.net/ubuntu/+source/tsclient/+bug/347039

This may assist some people.

Ta
Ken

Revision history for this message
Ken Foskey (foskey) wrote :

tsclient drop down open bug (replaces 347039)

https://bugs.launchpad.net/ubuntu/+source/tsclient/+bug/270374

Revision history for this message
Ken Foskey (foskey) wrote :

I found that compiz and rdesktop are simply incompatible, I cannot use compiz at all. For those willing to try please look at http://www.steveneppler.com/blog/2005/12/07/full-screen-and-tsclient Comment 32 gives you this:

QUOTE:
“I found a way how to enable “exit fullscreen” key combination for rdesktop when compiz is active. It was in “compiz setting manager”. There is plugin - “Workarounds”, which was enabled in my case. Among settings of this plugin there is option - “Legacy Fullscreen support”. It was enabled, and when I disabled it fullscreen in rdesktop began to work properly, that is, pressing “CTRL ALT ENTER” exits/enters fullscreen mode. Since tsclient uses rdesktop when it connects to windows hosts, this should work for it too.”

Revision history for this message
Markus Birth (mbirth) wrote :

This seems to be the related entry in the Debian bugtracker: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=317068

Markus Birth (mbirth)
tags: added: input keyboard lock rdesktop
Changed in rdesktop (Debian):
status: Unknown → New
Revision history for this message
PaulH (huffton) wrote :

I notice on redhat using rdesktop 1.6 it does not lock up. I think it may be due to some kind of conflict with compiz. I logged in using gnome safe mode (I think that switches off compiz) and it seems not to hang up any more. (I am using Linux Mint Julia which Is based on Maverick Meerkat - 10.10)

Revision history for this message
Tomas Pospisek (tpo-deb) wrote :

Same ole bug present in 10.04 Lucid Lynx, rdesktop 1.6.0-2ubuntu3.1

Reported upstream here:

https://sourceforge.net/tracker/index.php?func=detail&aid=3398169&group_id=24366&atid=381347

Revision history for this message
zoredache (francyci) wrote :

FYI: I am pretty sure freerdp (a rdesktop fork) fixes this issue with the refactoring they have been doing.

@PaulH (huffton), I am quite certain this lockup described has nothing to do with compiz. I see this in a thinclient setup where there there is no window manager at all, just rdesktop. But perhaps you are seeing a separate problem unrelated to the initial report.

Revision history for this message
Ken Foskey (foskey) wrote :

I am absolutely certain that there is a conflict with compviz. Seems to conflict with the way that they both hook into the keyboard handler.

There is also a problem with no dismissing a dialogue box that breaks rdesktop as well.

Thanks for the pointer to the fork.

Revision history for this message
David Gettis (forliberty) wrote :

Using Ubuntu 13.04 (rdesktop 1.7.1), I can confirm that a network disconnect still locks the keyboard for my entire system. The only solution is to kill the rdesktop process.

Revision history for this message
penalvch (penalvch) wrote :

Not reproducible in Trusty.

Changed in rdesktop (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
Alroger Filho (alroger-cafe-ti) wrote :

Same thing still in Ubuntu / Xubuntu 16.04, 17.04.

Revision history for this message
penalvch (penalvch) wrote :

Alroger Filho, given this report is closed, it will help immensely if you file a new report with Ubuntu via a terminal:
ubuntu-bug rdesktop

Please feel free to subscribe me to it.

no longer affects: rdesktop (Ubuntu)
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in rdesktop (Ubuntu):
status: New → Confirmed
penalvch (penalvch)
affects: rdesktop (Debian) → rdesktop (Ubuntu)
Changed in rdesktop (Ubuntu):
importance: Unknown → Undecided
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.