[Solved] startx not executed automatically at boot

Ichirou · 2020-03-07 13:53:25

I don't use any display manager, just use startx/xinit. I use Zsh + getty and I want my Arch machine to login automatically and execute startx right away.
Follow the guide from ArchWiki, here is my ~/.zprofile

linux> cat ~/.zprofile
if systemctl -q is-active graphical.target && [[ ! $DISPLAY && $XDG_VTNR -eq 1 ]]; then
	exec startx
fi

Here is xinitrc

linux> cat ~/.xinitrc
numlockx &
exec i3

And here is my getty's override.conf

linux> cat /etc/systemd/system/getty@tty1.service.d/override.conf
[Service]
Type=simple
ExecStart=
ExecStart=-/usr/bin/agetty --autologin ichirou2910 --noclear %I $TERM

This should works, but what I got was just the automatic login, the startx didn't happen.
--------
A bit more details just in case. I used TeamViewer few days ago, which required a DM to work properly, so I installed SDDM. I didn't configure anything. I just uninstalled TeamViewer and thus SDDM too. That was when I encountered this problem. Any help is appreciated.

Last edited by Ichirou (2020-03-08 12:51:24)

seth · 2020-03-07 14:06:50

I'm gonna say "systemctl -q is-active graphical.target" fails at this point.
It's in the wiki, but the history shows it objected and I could imagine this to become a race condition.

Edit: Please don't create shopping list threads, ie. start one thread per problem.
The xorg log only shows the keyboard (SINO WEALTH USB) added w/ the server start - is it supposed to cover such re-plug?

Last edited by seth (2020-03-07 14:12:21)

Ichirou · 2020-03-07 14:12:34

seth wrote:

I'm gonna say "systemctl -q is-active graphical.target" fails at this point.
It's in the wiki, but the history shows it objected and I could imagine this to become a race condition.

Hi, thanks for the answer.
As I wrote in the post, the problem just raised recently, so maybe coincidently after I uninstalled SDDM. I will remove that part and try booting again.

Ichirou · 2020-03-07 14:15:56

seth wrote:

Edit: Please don't create shopping list threads, ie. start one thread per problem.
The xorg log only shows the keyboard (SINO WEALTH USB) added w/ the server start - is it supposed to cover such re-plug?

I thought I could find something like "keyboard not found" but it's not there, how should I trace the problem then?
And I got your point. If possible, I want to seek solution for 2 problems this time, I will make it seperately next time. Thanks for the feedback.

Lone_Wolf · 2020-03-07 14:17:01

your xinitrc lacks some things , see https://wiki.archlinux.org/index.php/Xinit#xinitrc
(The missing things may not be the cause of the issues, but need correcting anyway) .

About startx not being executed :
most DMs only work if systemd boots to graphical.target, the code snippet in .zprofile only works if graphical.target hasn't been reached.
Maybe sddm install changed systemd default target to graphical .

run systemctl get-default to verify, it should list multi-user.target to make startx autostarting work.
https://wiki.archlinux.org/index.php/Sy … _boot_into

What type of keyboard is this : usb, ps2 ?
Does it work for before X is started ?

Last edited by Lone_Wolf (2020-03-07 14:18:04)

Trilby · 2020-03-07 14:19:04

Ichirou wrote:

And I got your point. If possible, I want to seek solution for 2 problems this time, I will make it seperately next time.

Then you did not get the point. This is not how these forums work and it will only result in a nonsensical and counterproductive thread (we're already well on our way to that). You can edit your first post and title as needed, and you can create another thread.

Ichirou · 2020-03-07 14:24:58

Trilby wrote:

Ichirou wrote:
And I got your point. If possible, I want to seek solution for 2 problems this time, I will make it seperately next time.
Then you did not get the point. This is not how these forums work and it will only result in a nonsensical and counterproductive thread (we're already well on our way to that). You can edit your first post and title as needed, and you can create another thread.

Ok I will create another thread. Sorry for the inconvenience.

Ichirou · 2020-03-07 14:39:25

Lone_Wolf wrote:

run systemctl get-default to verify, it should list multi-user.target to make startx autostarting work.

Hi, I changed to multi-user.target, but things still didn't work. So I tried removing that systemctl part in .zprofile and wow, it worked! So I think it's as seth said. Thanks for your help anw.

seth · 2020-03-07 14:47:45

Changing it to multi-user.target will not work for sure.
But if you had it at graphical.target, this is simply a race condition and supports my hunch that the wiki is giving bad advice here.

Lone_Wolf · 2020-03-07 15:41:15

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

That condition is not hard to break down :

A= result of systemctl -q is-active graphical.target
B = result of "! $DISPLAY"
C= result of $XDG_VTNR -eq 1

A && [[ B && C ]]

If A equals zero, condition is false > no startx
Incase A is non-zero result depends on the remainder of the condition .

[[ B && C]]

If B is zero, [[ B && C]] is also zero , conditon is false, no startx
Incase B is non-zero , result depends on remainder of the condition

If C is zero , [[ B && C]] is also zero, condition is false > no startx
In case C is non-zero , [[ B && C]] is also non-zero , condition is true > STARTX is executed .

Now let's look at A= result of systemctl -q is-active graphical.target .

man systemctl wrote:

is-active PATTERN...
Check whether any of the specified units are active (i.e. running). Returns an exit code 0 if at least one is active, or non-zero
otherwise. Unless --quiet is specified, this will also print the current unit state to standard output.

"systemctl -q is-active graphical.target" results in A = zero when graphical.target is reached , non-zero in any other case.

If multi-user is default target, systemd doesn't initialize graphical.target at all .
In this case "systemctl -q is-active graphical.target" results in non-zero which means B and C matter .

TL;DR :
if default target is graphical target the code will only work as intended UNTIL graphical.target is reached.
That's probably the race condition you see , seth ?
simplest method to ensure it doesn't get to that : set multi-user as default target.

seth wrote:

supports my hunch that the wiki is giving bad advice here.

On that we agree.

My personal method for startx uses multi-user.target as default target and this as condition :

if [[ -z "$DISPLAY" ]] && [[ $(tty) = /dev/tty1 ]]; then

That condition is true if "$DISPLAY" is a null-string AND user is logging in on tty1 .
It doesn't depend on logind or other session management systems and works with sysv-init, openrc & systemd.

Last edited by Lone_Wolf (2020-03-07 15:42:40)

seth · 2020-03-08 15:49:07

"systemctl -q is-active graphical.target" results in A = zero when graphical.target is reached , non-zero in any other case.

Nope.

Try

systemctl -q is-active graphical.target && echo foobar
systemctl -q is-active graphical.target; echo $?

in a graphical session.
The return code of 0 makes the stateent true, not false.

if default target is graphical target the code will only work as intended UNTIL graphical.target is reached.
That's probably the race condition you see , seth ?

No. The race condition is that the graphical target needs to be reached before the zprofile is executed from the getty login.

Not sure (not tried), but "is-enabled" might be the actually desired query (to shield from explicit multi-user.target boots)
Booting the multi-user.target and inspecting the enabled status of the graphical.target would tell…

Trilby · 2020-03-08 17:01:36

Oh dear - I've never used that condition as it struck me as mostly pointless. But I always assumed the intent was as described by Seth for the 'is-enabled' so the user could boot to a different target and not start X. I've always just booted to multi-user, so I never bothered.

But if indeed the condition is to check that the graphical target is not (yet) active, then it is indeed complete rubbish. I suppose one could use that to prevent X sessions starting on additional ttys after X is started by a display manager. But if one is starting X with a display manager and not wanting additional X sessions started on other ttys, then they'd just never put that whole block in their (z)profile in the first place.

So unless there is something else entirely, that condition seems to serve no purpose whatsoever other than to occasionally break in unexpected and unpredictable ways.

Last edited by Trilby (2020-03-08 17:02:15)

seth · 2020-03-08 22:10:47

As mentioned, it's not uncontested:
https://wiki.archlinux.org/index.php/Ta … X_at_login
https://wiki.archlinux.org/index.php?ti … did=580584

From the talk, I gather the idea is to check whether the target is active (and not startx otherwise) and since the getty.target is a requirement to be reached even before the mult-user.target, I don't see how this can be reliably expected.
The system has to get into the graphical.target faster than the getty target performs the autologin (what I guess will require the multi-user.target) and process the users shell profile - so a more complicated (slow) shell profile might reliably work and a simple one reliably fail.

If one wanted to wait for the graphical.target, one should rather engage in a user service.

Edit:typo

Last edited by seth (2020-03-08 22:11:13)

Arch Linux

#1 2020-03-07 13:53:25

[Solved] startx not executed automatically at boot

#2 2020-03-07 14:06:50

Re: [Solved] startx not executed automatically at boot

#3 2020-03-07 14:12:34

Re: [Solved] startx not executed automatically at boot

#4 2020-03-07 14:15:56

Re: [Solved] startx not executed automatically at boot

#5 2020-03-07 14:17:01

Re: [Solved] startx not executed automatically at boot

#6 2020-03-07 14:19:04

Re: [Solved] startx not executed automatically at boot

#7 2020-03-07 14:24:58

Re: [Solved] startx not executed automatically at boot

#8 2020-03-07 14:39:25

Re: [Solved] startx not executed automatically at boot

#9 2020-03-07 14:47:45

Re: [Solved] startx not executed automatically at boot

#10 2020-03-07 15:41:15

Re: [Solved] startx not executed automatically at boot

#11 2020-03-08 15:49:07

Re: [Solved] startx not executed automatically at boot

#12 2020-03-08 17:01:36

Re: [Solved] startx not executed automatically at boot

#13 2020-03-08 22:10:47

Re: [Solved] startx not executed automatically at boot

Board footer