Startx doesn't start automatically everytime.

Sotitsi · 2020-09-03 07:01:52

Hello, I have a small issue, and I don't know where to start to fix it.
It happens for a couple of days now, maybe after a system upgrade, I'm not sure.

When I logged in, startx used to start automatically everytime. There are some times though that it doesn't and I need to execute it myself. Other times it starts automatically though...

This is my bash profile:

#
# ~/.bash_profile
#

[[ -f ~/.bashrc ]] && . ~/.bashrc

if systemctl -q is-active graphical.target && [[ ! $DISPLAY && $XDG_VTNR -eq 1 ]]; then
	exec startx
fi

How should I approach this.. and why it happens only some times and not always..

Thank you..

nimrod_mack · 2020-09-03 07:17:29

One possibility might be that the Virtual Terminal Number changes. I don't know why that would be the case, but who knows...

I assume it's also possible you have a race condition with the graphical.target there - possibly, the graphical.target sometimes isn't fully reached when the .bash_profile is run.

As far as I've learned, it's more reliable to use

-z "$DISPLAY"

to test if a variable is not set.

You might consider writing out the outputs of the individual statements to get an overview of what is going on:

D = "~/.startx_debug.log"
date >> $D
systemctl is-active graphical.target >> $D
echo $? >> $D
echo $DISPLAY >> $D
echo $XDG_VTNR >> $D

I hope that helps!

V1del · 2020-09-03 07:17:49

Remove the graphical.target check or add a small sleep beforehand. There's a race condition between enabling the graphical target on login and the relevant script executing while checking whether graphical.target is active.

Sotitsi · 2020-09-03 07:24:12

Thank you.. this is true.. I just remembered this started happening after setting a Reflector service.

Will I have any problems if I remove the graphical.target condition.. I found it that way in the wiki.. why it is there in the first place?

Is it possible to delay reaching the login until everything else is loaded?

seth · 2020-09-03 10:38:44

https://bbs.archlinux.org/viewtopic.php … 8#p1890988

Trilby · 2020-09-03 13:28:21

Sotitsi wrote:

why it is there in the first place?

It's there to create a race condition and randomly break. Don't use it. A sleep may not even realy help - it simply doesn't do what it was intended to do: when it "works" it works by coincidence, not because it's doing what is intended.

Last edited by Trilby (2020-09-03 13:29:03)

gsgleason · 2020-09-03 15:24:43

I used this recommendation as well from the wiki. https://wiki.archlinux.org/index.php/Xi … X_at_login

I also ran into cases where it wouldn't start X after logging in, and I found that it was indeed that the graphical target wasn't active if I logged in immediately after boot, but would be after a bit longer.

If indeed it's broken, are there any systemd bug reports on it?

seth · 2020-09-03 15:27:51

This is not a bug in systemd but a logic error, again: https://bbs.archlinux.org/viewtopic.php … 8#p1890988

edit:

[ $(systemctl get-default) = "graphical.target" ]

might be what was intended…

Last edited by seth (2020-09-03 15:35:38)

GaKu999 · 2020-09-03 15:37:38

From my ~/.profile:

# Start Xorg on vt1, tmux on vt2
[ -z "$DISPLAY" ] && [ "$XDG_VTNR" -eq 1 ] && exec startx #TODO: sx again? Make one from scratch?
[ "$XDG_VTNR" -eq 2 ] && exec tmux -f "$HOME/.tmuxrc" new -s secure

EDIT: yay newer version with less lines...

Since you already login to a tty, and you would usually login into tty1, just make it autostart.
And leave the other ttys for console logins, without starting Xorg.

The check for DISPLAY just in case some goofed terminal pretends to be tty1 and Xorg is already alive...
And for some reason the spawned shell inside a virtual terminal is a login shell.
Haven't seen the goof tho, but hey, who knows.
Still, startx outside of a console can only do when unconfigured:

/usr/lib/Xorg.wrap: Only console users are allowed to run the X server

The syntax is because I choose POSIX for my ~/.profile...
And exec because I don't want access to my terminal if Xorg dies for some reason...

The default check is also a solution...
But not every system uses systemd right?

Last edited by GaKu999 (2020-09-03 17:44:57)

seth · 2020-09-03 15:57:22

No but we can anticipate it because it's used in the adapted, albeit broken, example.
You can btw. simplify your test, it's equivalent to the second part in the example (unless your init system does not set XDG_VTNR)

Trilby · 2020-09-03 16:00:03

Indeed there are *many* options of what to put in this conditional. There is no one size fits all as each person's system is a bit different and each persons specific goals are a bit different. If you really just want to start X at log in ever time, then there is no need for any conditiona check, just run `exec startx`. However this will have some undesirable side effects for a vast majority of users. So conditionals checks are recommended. But which restrictions you really want is up to you. Learn what each check actually does and make an informed choice. The following discussion on the same issue may be a helpful overview of many of the most common conditional checks:
https://bbs.archlinux.org/viewtopic.php … 3#p1921673

GaKu999 · 2020-09-03 16:12:20

seth wrote:

No but we can anticipate it because it's used in the adapted, albeit broken, example.
You can btw. simplify your test, it's equivalent to the second part in the example (unless your init system does not set XDG_VTNR)

I guess it's right, there's a lot of steam in the wiki about that part.
I do have XDG_VTNR properly assigned, since I use systemd, just mentioned so the more experienced archers that powned the init weren't left out.

I'll have to decide whether to make it systemd dependant or init agnostic tho...or set XDG_VTNR by hand on the profile, so init is not responsible for it's creation...
~~The latter seems healthier, let's code and test...~~
EDIT;
Nope, not healthy, wrong assumption.

Last edited by GaKu999 (2020-09-03 16:23:47)

Trilby · 2020-09-03 16:16:39

GaKu999 wrote:

or set XDG_VTNR by hand on the profile

What would be the point of that? If you mean hard-code it to a specific value then it serves no purpose at all but will break in making X start on any tty. If you mean setting it manually to a processed output of $(tty), then it's still pointless, but a little less likely to break - it'll just end up using more processes for no reason (e.g., you'll have to do string processing likely with an additional subshell to parse the output from `tty`).

GaKu999 · 2020-09-03 16:22:26

Trilby wrote:

GaKu999 wrote:
or set XDG_VTNR by hand on the profile
What would be the point of that?.

"Research"
But yes, it's not healthy at all! I searched for if it was possible to mimic it's creation, or if something can call the original tty from getty.

Trilby · 2020-09-03 16:26:48

Well if the point is just to avoid using an external binary you could use something like `readlink` or `realpath` or `ls -l` on /proc/self/fd/0 (if these are builtins).

Last edited by Trilby (2020-09-03 16:27:27)

GaKu999 · 2020-09-03 16:45:09

Trilby wrote:

Well if the point is just to avoid using an external binary you could use something like `readlink` or `realpath` or `ls -l` on /proc/self/fd/0 (if these are builtins).

Will I be grounded by a mod if I continue this topic?
Last post to avoid being put on timeout...just in case.

Using tty is not the issue per-see, and readlink|ls aren't builtins for me, you are using busybox or something?
I tried to get the original tty that agetty was in before Xorg was alive from within a terminal emulator inside Xorg, in essence, not end up with /dev/pts/$number...
I think I tried to do black magic because on a search engine and documentation I find nothing regarding that.

Trilby · 2020-09-03 16:57:09

Ah ... yeah that has nothing to do with this topic: you'd never need to know the controlling virtual terminal number for checking on whether X should be started. `tty` will return /dev/tty1 if you are actually in a tty. If you are in a pseudoterminal under X, do you really care WHAT vt you're in? You'd not want to start X within X, that's the point.

But for the totally off-topic question, there are other ways to get the controlling terminal - fgconsole for example.

Arch Linux

#1 2020-09-03 07:01:52

Startx doesn't start automatically everytime.

#2 2020-09-03 07:17:29

Re: Startx doesn't start automatically everytime.

#3 2020-09-03 07:17:49

Re: Startx doesn't start automatically everytime.

#4 2020-09-03 07:24:12

Re: Startx doesn't start automatically everytime.

#5 2020-09-03 10:38:44

Re: Startx doesn't start automatically everytime.

#6 2020-09-03 13:28:21

Re: Startx doesn't start automatically everytime.

#7 2020-09-03 15:24:43

Re: Startx doesn't start automatically everytime.

#8 2020-09-03 15:27:51

Re: Startx doesn't start automatically everytime.

#9 2020-09-03 15:37:38

Re: Startx doesn't start automatically everytime.

#10 2020-09-03 15:57:22

Re: Startx doesn't start automatically everytime.

#11 2020-09-03 16:00:03

Re: Startx doesn't start automatically everytime.

#12 2020-09-03 16:12:20

Re: Startx doesn't start automatically everytime.

#13 2020-09-03 16:16:39

Re: Startx doesn't start automatically everytime.

#14 2020-09-03 16:22:26

Re: Startx doesn't start automatically everytime.

#15 2020-09-03 16:26:48

Re: Startx doesn't start automatically everytime.

#16 2020-09-03 16:45:09

Re: Startx doesn't start automatically everytime.

#17 2020-09-03 16:57:09

Re: Startx doesn't start automatically everytime.

Board footer