Web lists-archives.com

Re: issues with stretch, issue 2 from many

On Tue, Nov 27, 2018 at 10:32:24AM -0600, David Wright wrote:
> > Question 2.1: Why .xsession is not read and .xsessionrc is read?
> Don't know. But you haven't posted how you start X.

He said he used "xdm and kdm", if I recall correctly.  Sounds like he
is switching things around randomly and frequently, instead of focusing
on one setup and describing it in detail.

> I use startx myself.


> But AIUI Debian has put a lot of effort into
> making it possible for X server sessions to end up in the same
> configuration whether they were started from a VC or a DM. Your using
> .xsessionrc sounds as if you might be working around some other
> "misconfiguration" that's happened to work until now. It might even
> have been like that since the "Great X Reorganisation" back in the
> days of slink.

My understanding is .xsessionrc was created in order to give users a
modicum of control over their own lives if they happen to use GNOME.
Since normally a gdm3/GNOME session will ignore everything in the
user's .xsession file, Debian created this other file that can be used
with GNOME.  Or with sddm/KDE, or lightdm, or xdm, or whatever other
bizarre display managers may appear in the future and screw everything
up even more.

I documented everything I could figure out about .xsessionrc and friends
at <https://wiki.debian.org/Xsession>.  There are definitely holes in my
knowledge when it comes to Desktop Environments (GNOME, KDE, and their
ilk), because I do not use them.  The more I learn about them, the less
I want to be anywhere near one.  Ever.

If the OP, or anyone else, wants help understanding how their X startup
works, we need a few concrete pieces of information before we can even

1) What version of Debian are you using?

2) How do you log in to your computer?  If it's a display manager
   (graphical login), which one is it?  If you need help figuring this
   out, see below.

3) How do you start X?  (Do you explicitly type a command, or is it started
   automatically by your graphical login?)

Figuring out which display manager you are using:

This is freakin' hard.  Way harder than it needs to be, in my opinion,
but I don't have any specific suggestions for how to remedy this, short
of the display managers individually choosing to identify themselves
in some way on the screen.

There are two ways I can think of to approach the situation.  The first
is to ask the Debian package manager which display manager(s) are
installed.  This basically means you need to know the names of ALL of
the common display manager packages, so you can ask for them all.

As a shortcut, however, we can take advantage of the fact that most of
them end with the letters "dm", or with the letters "dm" followed by
a single digit.  Thus:

# dpkg -l \*dm \*dm\[0-9]
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version      Architecture Description
un  gdm3           <none>       <none>       (no description available)
ii  kde-config-sdd 4:5.8.4-1    amd64        KCM module for SDDM
un  mdadm          <none>       <none>       (no description available)
ii  sddm           0.14.0-4+deb amd64        modern display manager for X11

On this system, it looks like sddm is installed.  So that's probably
the display manager that's in use.

The second approach is to log out of your X session so that the display
manager is actually running.  Then login on the text console (by pressing
Ctrl-Alt-F2), or by ssh-ing into the computer, and ask the system which
display manager processes are running.  Again, this requires that you
have some knowledge of the *names* of these processes, so you know what
to look/ask for.

# ps -ef | grep gdm
root     32374 32342  0 12:01 pts/0    00:00:00 grep gdm


# ps -ef | grep lightdm
root     32376 32342  0 12:01 pts/0    00:00:00 grep lightdm


# ps -ef | grep sddm
root       603     1  0 Nov02 ?        00:00:00 /usr/bin/sddm
root       683   603  0 Nov02 tty7     00:38:45 /usr/lib/xorg/Xorg -nolisten tcp -auth /var/run/sddm/{2b3b5bd9-8457-4fd5-b80d-b4c78b6bbc85} -background none -noreset -displayfd 18 vt7
root      1155   603  0 Nov02 ?        00:00:00 /usr/lib/x86_64-linux-gnu/sddm/sddm-helper --socket /tmp/sddm-authe24f9403-2eb8-4029-a8c8-83969060da79 --id 2 --start /usr/bin/sddm-greeter --socket /tmp/sddm-:0-nWnvBg --theme /usr/share/sddm/themes/debian-theme --user sddm --greeter
sddm      1157     1  0 Nov02 ?        00:00:00 /lib/systemd/systemd --user
sddm      1158  1157  0 Nov02 ?        00:00:00 (sd-pam)
sddm      1160  1155  0 Nov02 ?        01:40:22 /usr/bin/sddm-greeter --socket /tmp/sddm-:0-nWnvBg --theme /usr/share/sddm/themes/debian-theme
sddm      1168     1  0 Nov02 ?        00:00:00 dbus-launch --autolaunch 5942ce2e232449d09bfb1b98b5b26d87 --binary-syntax --close-stderr
sddm      1169     1  0 Nov02 ?        00:00:00 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session
root     32378 32342  0 12:01 pts/0    00:00:00 grep sddm

Bingo!  Looks like sddm is in use.

Of course, a third method would be to know what each display manager
actually *looks* like on the screen, so that you can identify it visually.
If you can do that, great.  I don't expect it to be a realistic choice
for most people.