#639984 lightdm: restart/reload fails if DISPLAY is set

Package:
lightdm
Source:
lightdm
Description:
simple display manager
Submitter:
Slavko
Date:
2015-01-27 20:15:08 UTC
Severity:
wishlist
#639984#5
Date:
2011-09-01 11:07:57 UTC
From:
To:
While testing LightDM under virtual environment (VirtualBox) i was not able
to restart the LightDM, while it tries to start Xephyr, which is missing.
After installing Xephyr it fails with unknown option -novtswitch.

The invoke-rc.d does report nothing:

invoke-rc.d lightdm restart
Stopping Light Display Manager: lightdm.
Starting Light Display Manager: lightdm.

The lightdm process is running after restart (with new PID):

ps -Af | grep light
root      2328     1  0 12:34 ?        00:00:00 /usr/sbin/lightdm

(no X and no lightdm greeter), but nothing is running after reload.

The VT remains on the VT7 (default). After machine reboot, the lightdm
greeter appears again.

All logs attached, with the "normal-" prefix are the logs from system start
(first start of the lightdm) and with "restart-" prefix are logs from
restart (without xephyr installed) and finally with "reload-" prefix is
after trying reload the config.

Please, can someone confirm it in real environment?
regards
#639984#10
Date:
2011-09-01 11:45:49 UTC
From:
To:
I can't, it works just fine. Why exactly do you want to use xephyr?

Regards,
#639984#15
Date:
2011-09-01 11:53:02 UTC
From:
To:
It should work just fine, virtualbox or not. Does X work?

Regards,
#639984#20
Date:
2011-09-01 12:31:24 UTC
From:
To:
Ok, as far as I understand it, from the logs and this mail:

* X wasn't working fine in virtualbox because of missing driver. This
lead to the initial, not working state, but is unrelated to lightdm

* then you restart lightdm from ssh, with X11 forwarding enabled.
lightdm sees the DISPLAY variable and interpretes that the user wanting
a display in Xephyr.

I think the support in lightdm is fine (it's actually useful), though it
might be a little more documented. You should take care of your
environment, and if you can't, you should use invoke-rc.d (and not
directly /etc/init.d scripts) which will do the environemnt cleaning for
you.

Regards,
#639984#25
Date:
2011-09-01 11:51:15 UTC
From:
To:
hi,

Dňa Thu, 01 Sep 2011 13:45:49 +0200 Yves-Alexis Perez <corsac@debian.org>
napísal:

i don't want to use xephyr, nor configure lightdm for use it, i only
found it in logs...

regards
#639984#30
Date:
2011-09-01 12:21:35 UTC
From:
To:
Hi,

Dňa Thu, 01 Sep 2011 13:53:02 +0200 Yves-Alexis Perez <corsac@debian.org>
napísal:

I agree...

Now i tried restart from vbox console (VT) and it works. Then i try it via
SSH with unset DISPLAY and it works too. It seems that problem is with SSH
session with X-Forwarding enabled (DISPLAY=localhost:10.0).

When i put:

unset DISPLAY

on the start of the lightdm's init script, then it works, but i don't
know, if it is acceptable solution and how (if) it takes the multiple X
sessions... However, managing remote (X enabled) machines via SSH is common
practice.
#639984#35
Date:
2011-09-01 14:22:03 UTC
From:
To:
Ahoj,

Dňa Thu, 01 Sep 2011 14:31:24 +0200 Yves-Alexis Perez <corsac@debian.org>
napísal:

quote from my early email:

"invoke-rc.d lightdm restart"

seems it as the directly launched init script?
#639984#40
Date:
2011-09-01 15:26:20 UTC
From:
To:
Grmbl, so that means you need to take care of the environment cleaning
yourself.

Regards,
#639984#45
Date:
2011-09-01 19:45:12 UTC
From:
To:
Ahoj,

Dňa Thu, 01 Sep 2011 17:26:20 +0200 Yves-Alexis Perez <corsac@debian.org>
napísal:

if the behavior the lightdm with the DISPLAY variable is proper, as
you write, then it must be started in my local machine (as other X clients
are doing), but it simply dies.

But is not desired to start remote display manager on local machine when
it is restarted and completely it is not desired behavior, when
init script is called with reload argument.

My daughters are using KDM, i am using GDM an at work i have LDM. But only
LightDM has problem with this. Then all these DM works in bad manner, only
your package not?

regards
#639984#50
Date:
2011-09-01 20:16:43 UTC
From:
To:
The other ones don't support autodetecting if already running in a
graphical shell, no.
#639984#61
Date:
2014-02-11 12:22:25 UTC
From:
To:
Dear Maintainer,

we were bitten by that in a real environment, too. And, Yves-Alexis, you
were wrong when saying other login managers act equally.

I agree that when the lightdm binary is started directly it should somehow
be able to auto-detect if it runs in a nested environment or not.

Nonetheless we were using the runlevel startup scripts to restart lightdm over
a ssh connection which failed while other login managers (namely kdm) did
not. That way you can restart remotely any display manager I know of without
fiddling with the DISPLAY variable.

Thats why I ask you to accept this bug and maybe change the init script
accordingly in order to ignore the DISPLAY variable. If wanted, I can write up
a small patch which makes the behaviour configurable via /etc/defaults/lightdm.

With kind regards,
Jens
#639984#66
Date:
2014-02-11 20:47:30 UTC
From:
To:
DISPLAY is used in legitimate cases. You're free to unset DISPLAY on
your specific uses cases, you're even free to edit /etc/init.d/lightdm
file, your modifications won't be overwritten by dpkg at the next
update.

Regards,
#639984#71
Date:
2015-01-27 20:05:21 UTC
From:
To:
hello yves-alexis,

i'd like to ask you to reconsider your stance on clearing the DISPLAY
variable in the lightdm startup script.

granted, calling `/etc/init.d/lightdm restart` may not be the preferred
way of starting and stopping services any more, but as long as those
scripts don't actively resist invocation, they will be used.

while it's probably even a good idea that the lightdm binary does
something reasonable in the presence of DISPLAY, i'm pretty sure that
the lightdm instance started by the init script is never supposed to be
used in connection with a pre-set environment variable -- as you noted,
the more modern invocations of init scripts would clean that out anyway.

the situation i've ended up is similar to those situations described
earlier -- display went blank, trying to get the box up and running from
remote again, and DISPAY being set. the altered behavior of lightdm in
that situation is subtle to debug. the way Xephyr fails ("Unrecognized
option: -novtswitch / use: X [:<display>] [option]") doesn't help
either. i ended up grepping through the lightdm source code when i
discovered the Xephyr thing until i unset the DISPLAY variable and later
found this bug report. a warning along the lines of `env |grep
'^DISPLAY=' >/dev/null && echo 'Warning: DISPLAY set, lightdm will
misbehave. Use invoke-rc.d instead.'` would have helped a lot.

i'm not saying that the lightdm init script is wrong in not clearing
DISPLAY if init scripts may rely on having a cleaned environment. but as
long as this is not enforced, lightdm failing to be started from the
init script under the described conditions is a very harsh way of
educating users.

best regards
chrysn