Control-C causes LightDM to restart in a Multiseat configuration

[Calvin Morrow]

A single computer is setup in a Multiseat setup (2 keyboards, 2 mice, 2 video cards, 2 users). LightDM is configured to allow multiseat so that multiple users can run X sessions simultaneously with -sharevts and -novtswitch options passed to the X server.

On ONE of the seat greeters, pressing the keyboard combination "Control-C" causes ONE of the LightDM greeter sessions to quit and restart the associated X server. On the other seat "Control-C" has no (negative) effect. This happens regardless of whether LightDM is sitting in the login screen or whether the user has logged in to a desktop environment. Pressing "Control-C" in the desktop environment (to copy text for pasting later) causes the LightDM greeter session to quit (as seen in the lightdm log), and then restart the X session.

ProblemType: Bug
DistroRelease: Ubuntu 11.10
Package: lightdm 1.0.6-0ubuntu1.1
ProcVersionSignature: Ubuntu 3.0.0-13.22-generic 3.0.6
Uname: Linux 3.0.0-13-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 1.23-0ubuntu4
Architecture: amd64
Date: Tue Nov 22 06:49:04 2011
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: lightdm
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

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

[Paulo J. S. Silva (pjssilva)]

Same here.

Even if I start a single seat, commenting out the entry in lightdm.conf for the second seat, the problem with ctr-c continues. Actually, I found out that the problem is easily reproducible even in usual computers with a single graphic card in single seat configuration. Only add the option

xserver-command=X -sharevts

to the /etc/lightdm/lightdm.conf file. Now any press to ctr-c will kill X.

If you delete the -sharevts option then the problem is gone. Hence the culprit seems to be how lightdm (or the X) handles this option.

[Paulo J. S. Silva (pjssilva)]

I have found out that the first seat can be called without using th -sharevts option. See the attached lightdm.conf. With this new configuration I get an almost perfect two seat configuration but one problem remain.

If the second seat closes a session (and hence restart its X server to go back to lightdm greeting screen) the first seat is moved to a new virtual terminal. To get back to the original terminal we need to type alt-f7 in seat 1. This is quite annoying, but much less annoying than killing the session with ctr-c. Note that the -sharevts option precludes this behavior but has the ctr-c kills X problem.

[Paulo J. S. Silva (pjssilva)]

Ops... the name of the attachment in the comment above (#7) should be Lightdm configuration with -sharevts option only in the second seat (instead of first seat). Sorry for the typo.

[Paulo J. S. Silva (pjssilva)]

It seems like lightdm demands -keeptty option. The attached ightdm.conf works for me now in an updated 11.10 machine.

[Johannes Storm (jo-master)]

same with patched gdm+consolekid. so maybe don't depends on lightdm.

[Launchpad Janitor (janitor)]

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

[mac.ryan (macryan)]

Suggestion at #9 fixed the issue.

[Johannes Storm (jo-master)]

i don't think that enabling the debugging mode is a clean fix.

[mac.ryan (macryan)]

I see what you mean, and I will understand if you will change back the status of the bug. My rationale in changing the status was the following though:

1. I think it is important for people using launchpad to know at first glance if an issue has been solved or not, a bit like prepending "[solved]" to the topic of a thread in a forum.

2. The documentation says "This option is only useful when debugging the server", but per se -keeptty prevent tty detachment i.e. it's not a "debugging mode" in the typical sense of the expression.

However I shall repeat that I will understand if you´ll change the status of the bug. It would be useful if launchpad would offer a "workaround available" flag for the bugs though... this would really be a closer description of where this bug stands! :)

[Johannes Storm (jo-master)]

maybe we should leave it here as fixed and go further on bug fixing at lightdm bug tracker. an exploration of the behaviour is at https://bugs.launchpad.net/lightdm/+bug/903194