[SOLVED] startx through DM fails but works from command line

diesmond · 2020-02-20 21:23:47

Hi

I've been playing around with zsh+suckless terminal+i3 gaps and having quite a time.
Just one thing I have not been able to figure out:

When logging in using the DisplayManager I just get a black screen with a cursor.
After a while I then get redirected to the login screen.
Dropping to the command line, logging in and running startx however works fine.

My .xinitrc has exec i3 in it and my .profile/.zprofile should be running startx by:
[ "$(tty)" = "/dev/tty1" ] && ! pgrep -x Xorg >/dev/null && exec startx.

I've been through multiple iterations of the above line and it's location but nothing worked. Mainly I think I'm missing some debugging tools for this.
Any ideas where to keep looking?
Thank you in advance!

Greetings
diesmond

Last edited by diesmond (2020-06-29 16:41:16)

seth · 2020-02-20 22:20:02

When logging in using the DisplayManager I just get a black screen with a cursor.
After a while I then get redirected to the login screen.

You'll need to elaborate on that.
- What "DisplayManager"?
- Black screen w/ a mouse or a text cursor?
- What login screen?

Running "startx" from a graphical target (X11 or wayland) won't work.

My .xinitrc has exec i3 in it and my .profile/.zprofile should be running startx by:

No paraphrasing, please. Post the actual files

diesmond · 2020-02-22 20:18:04

Ok here's what I got:

- The display manager is lightdm. I checked the display-manager.service status and saw there were some errors:

lightdm.service - Light Display Manager
     Loaded: loaded (/usr/lib/systemd/system/lightdm.service; enabled; vendor preset: disabled)
     Active: active (running) since Sat 2020-02-22 19:00:08 CET; 1h 55min ago
       Docs: man:lightdm(1)
   Main PID: 779 (lightdm)
      Tasks: 12 (limit: 18856)
     Memory: 125.2M
     CGroup: /system.slice/lightdm.service
             ├─ 779 /usr/bin/lightdm
             ├─1481 /usr/lib/Xorg -dpi 220 :0 -seat seat0 -auth /run/lightdm/root/:0 -nolisten tcp>
             └─1508 lightdm --session-child 14 21

Feb 22 19:00:06 diegorenner systemd[1]: Starting Light Display Manager...
Feb 22 19:00:08 diegorenner systemd[1]: Started Light Display Manager.
Feb 22 19:00:08 diegorenner lightdm[779]: Error getting user list from org.freedesktop.Accounts: G>
Feb 22 19:00:09 diegorenner lightdm[1086]: Error getting user list from org.freedesktop.Accounts: >
Feb 22 19:00:09 diegorenner lightdm[1086]: pam_unix(lightdm-greeter:session): session opened for u>
Feb 22 19:00:13 diegorenner lightdm[1103]: gkr-pam: unable to locate daemon control file
Feb 22 19:00:13 diegorenner lightdm[1103]: Error getting user list from org.freedesktop.Accounts: >
Feb 22 19:00:14 diegorenner lightdm[1103]: pam_unix(lightdm:session): session opened for user dieg>
Feb 22 19:01:05 diegorenner lightdm[1492]: Error getting user list from org.freedesktop.Accounts: >
Feb 22 19:01:05 diegorenner lightdm[1492]: pam_unix(lightdm-greeter:session): session opened for u>
lines 1-22/22 (END)

Are those important? I can't figure out where they are coming from.
I found a similar case where someting was wrong with the autologin conf of lightdm but I never changed anything in that file.

- It's a black screen with a mouse.
- By login screen I mean the screen displayed by the display manager.

- Here is my .xinitrc and my .zprofile/.profile file (they are the same):
.xinitrc:

#!/usr/bin/env sh

[[ -f ~/.Xresources ]] && xrdb -merge -I$HOME ~/.Xresources

exec i3

.profile:

# Profile file. Runs on login. Environmental variables are set here.

# Adds `~/.local/bin` to $PATH
export PATH="$PATH:$(du "$HOME/.local/bin/" | cut -f2 | tr '\n' ':' | sed 's/:*$//')"


# Default programs:
export EDITOR="nvim"
export TERMINAL="st"
export BROWSER="brave"
export READER="zathura"
export FILE="ranger"

# Clean-up:
export XAUTHORITY="$XDG_RUNTIME_DIR/Xauthority"
export NOTMUCH_CONFIG="$HOME/.config/notmuch-config"
export GTK2_RC_FILES="$HOME/.config/gtk-2.0/gtkrc-2.0"
export LESSHISTFILE="-"
export WGETRC="$HOME/.config/wget/wgetrc"
export INPUTRC="$HOME/.config/inputrc"
export ZDOTDIR="$HOME/.config/zsh"
export PASSWORD_STORE_DIR="$HOME/.local/share/password-store"

[ "$(tty)" = "/dev/tty1" ] && ! pgrep -x Xorg >/dev/null && exec startx

PATH=$PATH:/usr/bin/matlab_desktop

jasonwryan · 2020-02-22 20:23:55

Your xinitrc is incomplete: read the wiki page.

Also, read the wiki page for journalctl and then post a log with wrapped, not truncated, lines.

Finally, why are you starting X from your zprofile and running a DM?

seth · 2020-02-22 23:12:50

Next to that, depending on your i3 config (post that), a black screen w/ a mouse cursor is all you'll get w/ that xinitrc.

qinohe · 2020-02-24 18:51:04

diesmond wrote:

.profile:

....

[ "$(tty)" = "/dev/tty1" ] && ! pgrep -x Xorg >/dev/null && exec startx

That's a rationale that stems from auto starting X and makes no sense this way, like others said already...
Lightdm also has no need for it, you could start a home brew DM with it though;)
However I would change it than.

diesmond · 2020-06-29 16:37:41

Thank you all for your quick responses and sorry for my late one.
I've been able to figure out what the problem was and I will be posting a journalctl log with wrapped lines if I ever have to again.
I get now that the DM takes care of launching X itself so of course starting X anywhere else is pointless.
My problem ended up being this line that I must have used unwittingly in a fit of reconfiguring my setup:

export XAUTHORITY="$XDG_RUNTIME_DIR/Xauthority"

in my .profile file.

After redirecting XAUTHORITY to my default Xauthority file in my home directory everything worked again.
Looking into what the Xauthority file is I gathered that without it or without the right permission on it the login credentials can't be stored and used for authenticating applications that want to connect to the display.

Let me know if this is wrong or inprecise
Thanks again for all your support.

Trilby · 2020-06-29 16:45:39

You can set XAUTHORITY to be wherever you'd like, but the X11 server and client programs must be provided with the same XAUTHORITY or you will run into a wide range of errors.

By setting the variable in your profile, you provided a non-default value for many client programs, but not to the server itself when started by a DM as the DM does not inherit the environment set in the profile. It worked when you ran startx from the tty because then the server process did inherit the profile variable setting.

In short, if you know what you are doing, you can set XAUTHORITY to something other than the default. But if you don't, then don't.

Also given that we've seen a few of these errors recently due to explicitly setting XAUTHORITY in a shell profile, I gather you used some unsupported third party tutorial to configure your system (or just copy-pasta'd a crap config which is also evident in how you are starting X from your shell profile which is nothing like the recommendations in the wiki).

Last edited by Trilby (2020-06-29 16:52:39)

diesmond · 2020-06-30 10:04:15

Thanks for clarifying.
I tried removing everything that I didn't understand before posting here but I must have missed that line.
Starting X from the shell profile was a move of desperation since I couldn't find any other solution,
I had tried the wiki suggested way first aswell.
I'll be more careful next time.

Trilby · 2020-06-30 11:48:54

diesmond wrote:

I tried removing everything that I didn't understand before posting here but I must have missed that line.

Further evidence that this isn't (vanilla) arch linux. There wouldn't be anything you don't understand in your shell profile and configs on an arch system.

For future reference, you'll need to seek help on the support channels for whatever spin-off distro or installer you are using.

Last edited by Trilby (2020-06-30 11:49:33)

kilix · 2020-06-30 12:45:55

diesmond, did you use LARBS to autoconfigure your system by any chance?

Arch Linux

#1 2020-02-20 21:23:47

[SOLVED] startx through DM fails but works from command line

#2 2020-02-20 22:20:02

Re: [SOLVED] startx through DM fails but works from command line

#3 2020-02-22 20:18:04

Re: [SOLVED] startx through DM fails but works from command line

#4 2020-02-22 20:23:55

Re: [SOLVED] startx through DM fails but works from command line

#5 2020-02-22 23:12:50

Re: [SOLVED] startx through DM fails but works from command line

#6 2020-02-24 18:51:04

Re: [SOLVED] startx through DM fails but works from command line

#7 2020-06-29 16:37:41

Re: [SOLVED] startx through DM fails but works from command line

#8 2020-06-29 16:45:39

Re: [SOLVED] startx through DM fails but works from command line

#9 2020-06-30 10:04:15

Re: [SOLVED] startx through DM fails but works from command line

#10 2020-06-30 11:48:54

Re: [SOLVED] startx through DM fails but works from command line

#11 2020-06-30 12:45:55

Re: [SOLVED] startx through DM fails but works from command line

Board footer