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.
Same.
> 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
begin:
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]
Desired=Unknown/Install/Remove/Purge/Hold
| 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
Nope.
# ps -ef | grep lightdm
root 32376 32342 0 12:01 pts/0 00:00:00 grep lightdm
Nope.
# 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.
Reply to: