Dear Maintainer,

Hi,

I have been using gdm3 as a display manager, but wished to switch to
lightdm, so I installed lightdm (initially from testing, but when it
gave the symptoms described below also from unstable, which was
installed for this bug report).

I then ran /etc/init.d/gdm3 stop, logged out, and from a root shell
ran dpkg-reconfigure lightdm (to make it the default) and
systemctl start lightdm (the init system is sytemd.)

I was presented with a greeter with boxes for username and password. I
selected xfce as the desired session and typed my username and
password into the boxes. The greeter screen disappeared, but instead
of an xfce session appearing, the greeter screen reappeared. I again
typed my username and password into the boxes and attempted to login
but the same thing keeps happening.

I eventually switched back to the root shell, stopped lightdm,
restarted gdm3 and logged in without problems.

I attach the log files found in /var/log/lightdm.

Control: tag -1 unreproducible moreinfo

[+139.22s] DEBUG: Registering session with bus path /org/freedesktop/DisplayManager/Session2
[+139.22s] DEBUG: Session pid=31375: Running command /etc/X11/Xsession startxfce4
[+139.22s] DEBUG: Creating shared data directory /var/lib/lightdm-data/james
[+139.22s] DEBUG: Session pid=31375: Logging to .xsession-errors
[+139.25s] DEBUG: Activating VT 7
[+139.25s] DEBUG: Activating login1 session /org/freedesktop/login1/session/_320
[+139.35s] DEBUG: Session pid=31375: Exited with return value 0
[+139.35s] DEBUG: Seat: Session stopped

Can you provide a relevant .xsession-errors? I think there might be some
leftovers from gdm (like a gnome-session or something like that)
preventing the correct startup of Xfce session manager.

Regards,

.xsession-errors (and .xsession-errors.old) is an empty file. The
timestamp is consistent with the attempt to login.

In case there was something running causing the problem, I tried
configuring lightdm to be the default dm and re-booting, which gave a
ligthdm greeter with the same symptoms.

Well I'm afraid I can't help you much here… You'll have to debug
why /etc/X11/Xsession startxfce4 is failing here. It first tries to
execute the script in /etc/X11/Xsession.d so you might want to take a
look there.

Regards,

Aha.

/etc/X11/Xsession was not executable. After making it executable,
lightdm now works.

Thanks.

Any idea how it happened?

None, I'm afraid. I've no memory of changing it, and I don't normally
go round making random files non-executable to see what happens.

As I said, it worked like that with gdm3, and I've been running that
or gdm for a very long time, so assuming it also worked with gdm, it
could have happened ages ago.

Thanks again for your help on this. I'm closing the bug, since the
problem wasn't in lightdm in the first place, and is now fixed here.

Please don't hijack bugs. Also, that won't change anything. Sure we
rely on the fact that /etc/X11/Xsession is executable, like startx and
any display manager which does not specifically chose something else.
We have to rely on a minimal system, we can't really check (or worse,
fix) each and every bit of the system.

Regards,

No, startx has also worked on my machine without the executable bit on that
file. It's lightdm that seems to be depending on something others don't.

If this is an actual requirement of some standard, please reassign the bug
to the owner of the file (x11-common) and have them enforce the standard.

If it isn't a standard, please handle the legitimate discrepancy.

Neither of these options really seems onerous.

I had the impression that startx (without argument) would use Xsession.
At least the Xsession file header gives that impression.

It's already done. x11-common ships Xsession with executable bit.

Regards,

On related note, this system executes the ~/.xsession file as a shell
script, but it isn't executable :)

Well, then it shouldn't ship it as a conffile, because that implies they
can't maintain the enforcement, as the user is allowed to do all sorts of
things to conffiles (and usually expected to).

(Executable configuration file - doesn't that just sound wrong?)

No, see 50x11-common_determine-startup, if it's not executable it'll
treat it as a shell script and run it through $SHELL (or sh).

Sure, if you remove the executable bit, it won't execute. Isn't what
you wanted, then?

Anyway, end of discussion for me. It might be entertaining for you, but
it's time consuming for me.

Regards,

reassign 748944 x11-common
retitle 748944 lightdm relies on the executability of /etc/X11/Xsession, please enforce it
thanks

That's what I meant, it's effectively the same.

I have no recollection of actually removing that executable bit for any
actual purpose, and I don't generally go around chmod -x'ing arbitrary files
on my system. I'm thinking it happened through some change of functionality
on an upgrade.

I assure you that bugs like this aren't entertaining to users - being unable
to access your working environment is usually quite stressful. That I've
made a lighthearted comment should indicate to you that I'm on your side,
probably unlike N unknown lurkers who may have seen the same bug, got pissed
off at what they saw as a useless piece of software, but then never bothered
to tell us.

I've moved it to x11-common.

x11-common installs /etc/X11/Xsession executable.  Anything beyond that
is not its responsibility.

Cheers,
Julien

reopen 748944
thanks

I'm sure all of our users who hit this bug will be thrilled to see this
kind of behavior.