TWiki> DICE Web>ManagedPlatformUnit>XRDPService (revision 14)EditAttach

Virtual Desktop Service (xrdp)

Project blog:


The RDP servers need some routine housekeeping. Here's how to do that.

If someone reports a problem

They're still logged in

A lot of people just don't seem to realise that when you quit the Remote Desktop app, the DICE session doesn't logout - it stays running. This has a few consequences:
  • A screensaver starts after a while. This can confuse people when they next login.
  • When the session's AFS credentials expire, some processes (e.g. firefox) can get upset, and use a lot of CPU while trying and failing to get access to their files.
  • Sometimes processes in abandoned sessions can get so upset that the session becomes unusable - but it's still running.
Abandoned sessions are auto-killed after two weeks.

"I logged in but it was all black."

If someone starts a session but they just see blackness instead of windows and a desktop, it's almost certainly a screensaver from their previous session. If they click on the blackness, a screensaver window should pop up and ask for their password. Hopefully they'll then be able to unlock the screensaver and resume that session. If that doesn't work, try killing their processes for them.

How to kill all of a user's processes on a machine

If someone's session has become stuck or unusable, you can kill all of their processes on that machine. To do that, become root on that server then:
killall -u UUN
Alternatively, use
loginctl terminate-user UUN

If someone is having problems on their remote server, you can just ssh to it:
The "remote" names are just DNS aliases. Everybody has one. You can rely on each "remote" alias staying the same - they won't be switching about and pointing to other machines.

General server health

How to tell if something's wrong

One way is to check the load average on each server. This command can help:

If a server's load average is way into double figures then something's definitely wrong.

Look more closely

Having found a machine which is being hammered, ssh to it then, as root, run top -c. This should tell you which processes are using the most CPU time. If you find a process using near 100% CPU time (sometimes more, if it has lots of threads) here's what to do:

  • Is the machine otherwise quiet? Maybe leave it alone for now.
  • Is the load average high? First try limiting the CPU which that process's session is allowed to use. Copy the PID of the process, then, still as root, leash PID . This should limit that process's entire session so that it's allowed to use a maximum of half a CPU at any one time. Go back to top -c to check, and repeat for other troublesome processes.
  • leash doesn't work on some processes, because they're no longer associated with a session. In this case you might want to kill them. You can do this from inside top by pressing k. This will first prompt you for the PID of the process to kill (it defaults to the first process in the display, and this is usually the one you want). When you press return, it'll ask for the signal you want to send to the process. The default of 15 usually works, but if that doesn't make the process exit, you can try again with a signal of 9. Obviously, be careful not to kill root processes.


If someone is persistently running CPU-heavy things on a remote desktop server, you could mail them to ask them not to. It might help to explain that every taught student has a alias they can ssh to, and they can do their coursework there. There's a help page at

Crashes, hangs and reboots

Even with regular attention, a popular remote desktop server can become unusable after a few weeks of enthusiastic use. We've seen two problems occur multiple times. The first has been a server crashing with an AFS-related kernel crash. This should be solved now. The second is that certain commands start to hang indefinitely. The only cure we've found for this behaviour is to reboot the server.


The server-side configuration is closely based on a prototype service developed by SEE. It uses xrdp project to provide remote access to the X server. In front of that is a proxy which uses HAProxy to load balance across a cluster of machines. Up to now we have only had a single "staff" server and a single "student" server but with there being a lot more interest in supporting distance learning we clearly are going to have to expand our provision and this should provide the ideal solution.

Based on the work of FreeRDP and rdesktop, xrdp uses the remote desktop protocol to present a GUI to the user. The goal of this project is to provide a fully functional Linux terminal server, capable of accepting connections from rdesktop, freerdp, and Microsoft's own terminal server / remote desktop clients. Xrdp uses Xvnc or X11rdp to manage the X session.
A free, very fast and reliable solution offering high availability, load balancing, and proxying for TCP and HTTP-based applications.

SEE headers (needs EASE authentication):

LCFG headers (closely based on SEE):

DICE headers:

We have these servers:

  • is the general service. It's on two machines, lute and archlute. An "haproxy" service sends users to one or other of them.
  • is the staff, postgrad and visitor server. It's on waterloo, an old Dell PowerEdge R720.
  • From time to time there's a test server on


One of our biggest issues with the previous NX service was the lack of decent client software for all platforms. The open-source versions were rarely sufficiently well maintained so we relied on the closed-source versions from NoMachine, newer versions of which no longer support the old protocol. With RDP it is all a lot simpler as it's a "standard" protocol on Windows and MacOSX.

Various clients are available, the current best appears to be Remmina which is available as a package for at least Fedora, Debian, Ubuntu.
The standard Microsoft Remote Desktop application (which is free to install) should work. See this page for details.
Microsoft provide a free application in the App Store

SEE have put together some basic notes on how to configure various RDP clients.

Further Ideas,

(Copied from - thanks!)

To remove hosts from remote.inf you need to do three things:

  • rfe dns/remoteHostList
  • As root on oramo, edit /var/lcfg/conf/DNS/zone.remote.inf and remove all of the entries pointing to hosts that you want to remove. (The script tries to preserve the mappings between users and machines to make session resumption easier. If that's not a concern, the file can just be removed, or moved aside, as it will be completely regenerated in the next step anyway. If it is removed, though, it's important that the next step is not then missed out.)
  • As root on oramo, run /usr/lib/lcfg/dns/generateRemoteInf to generate a new zone. Users not already allocated to a machine will be spread across the remaining ones in the remoteHostList map.

lab.inf comes from a netgroup, so for that one you need to:

  • Arrange to update the netgroup
  • As root on oramo edit /var/lcfg/conf/DNS/zone.lab.inf
  • As root on oramo, run /usr/lib/lcfg/dns/generateLabInf to generate a new zone.

This is also covered in the Infrastructure Unit's DNS care and feeding document.

Edit | Attach | Print version | History: r16 < r15 < r14 < r13 < r12 | Backlinks | Raw View | Raw edit | More topic actions...
Topic revision: r14 - 17 Jun 2020 - 08:14:25 - ChrisCooke
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies