A stop job running for user manager uid 1000 while using WM and not DE

arch181 · 2021-03-04 16:08:45

Scimmia wrote:

Is that a paste error or do you really have exactly that output from loginctl? That's a real problem if that's what you get.

Why is that??? Can you please help me and tell whats wrong or how to solve it ?? @Scimmia

Last edited by arch181 (2021-03-05 04:44:01)

arch181 · 2021-03-04 16:32:58

Should I just switch to sway (wayland) so you guys save all the time, effort and i wont bother you anymore with this stupid problem??

Last edited by arch181 (2021-03-04 16:33:21)

Ferdinand · 2021-03-04 18:11:41

Don't despair, arch181 - confusion is a frustrating road to knowledge, but there will be knowledge

I can't solve this one, but I can maybe remove a bit of frustration.

The reason Scimmia doesn't like your ./.autostart.sh & is that you're using a relative path, i.e. you're running a file named .autostart.sh in whatever directory you're in when you type startx.
What you probably want to do is ~/.autostart.sh &, which will run the file .autostart.sh in your home directory.

Also, it is unclear how i3 gets started, because your initial .xinitrc contained this:

#Executions
exec picom -G &
./.autostart.sh &

#Window manager
exec i3

And the thing is exec replaces the current shell with the command you exec. I.e. .xinitrc will cease to exist from that first exec, and as a result none of the following commands will be executed.

Your new .xinitrc looks a lot better:

#Executions
picom -G &
##./.autostart.sh &

#Window manager
exec i3

Now your exec is the last command in the script, which is brilliant.

The stuff about bumping just means that if you have more information to add after your last post, before anybody else has replied, then it's preferable to edit your last post, rather than make a new

And to make sure you provide the exact output from loginctl session-status, as per Scimmias request, do this and share the resulting URL:

loginctl session-status |& curl -F 'f:1=<-' ix.io

The method is explained in the Wiki.

arch181 · 2021-03-04 18:40:56

Ferdinand wrote:

Don't despair, arch181 - confusion is a frustrating road to knowledge, but there will be knowledge
I can't solve this one, but I can maybe remove a bit of frustration.
The reason Scimmia doesn't like your ./.autostart.sh & is that you're using a relative path, i.e. you're running a file named .autostart.sh in whatever directory you're in when you type startx.
What you probably want to do is ~/.autostart.sh &, which will run the file .autostart.sh in your home directory.
Also, it is unclear how i3 gets started, because your initial .xinitrc contained this:
#Executions
exec picom -G &
./.autostart.sh &

#Window manager
exec i3
And the thing is exec replaces the current shell with the command you exec. I.e. .xinitrc will cease to exist from that first exec, and as a result none of the following commands will be executed.
Your new .xinitrc looks a lot better:
#Executions
picom -G &
##./.autostart.sh &

#Window manager
exec i3
Now your exec is the last command in the script, which is brilliant.
The stuff about bumping just means that if you have more information to add after your last post, before anybody else has replied, then it's preferable to edit your last post, rather than make a new
And to make sure you provide the exact output from loginctl session-status, as per Scimmias request, do this and share the resulting URL:
loginctl session-status |& curl -F 'f:1=<-' ix.io
The method is explained in the Wiki.

Thank you so much for the encouragement you really gave me motivation to keep finding for solutions no matter what. Thanks a lot appreciate it @Ferdinand

Last edited by arch181 (2021-03-05 04:43:38)

seth · 2021-03-04 22:21:33

Your OP states that it doesn't matter if you terminate the i3 session and reboot from the console.
a) If you don't start the i3 session, does the issue manfest nevertheless?
b) check what processes are still running for your user after terminating the i3 session

@Ferdinand, the forked exec "exec foo &" does not replace the shell process, you fork the exec and that (pseudo) subshell then gets replaced by the foo process.
You can try this in bash, just run eg. "exec xterm &" - it'll simply get you a new xterm that you can close w/o affecting the starting shell. Running "exec xterm" will get you an xterm as well, but if you close it, so will the parenting shell.

arch181 · 2021-03-05 05:15:37

If I dont start the x session which executes the i3 and just stays in the tty1 the problem wasnt there.
How can I check what process are still running after ending the session?
Note: I already removed the xorg server and I decided that ill switch to sway so ill just save you all this time and effort to try to solve this problem and for me too. thats ok for me because I intended to do that someday and this problem with my xsession gave me a good reason to start the switching process.
Thank you so much guys for all the help its not taken for granted so I really appreciate it

Last edited by arch181 (2021-03-05 08:21:13)

Arch Linux

#26 2021-03-04 16:08:45

Re: A stop job running for user manager uid 1000 while using WM and not DE

#27 2021-03-04 16:32:58

Re: A stop job running for user manager uid 1000 while using WM and not DE

#28 2021-03-04 18:11:41

Re: A stop job running for user manager uid 1000 while using WM and not DE

#29 2021-03-04 18:40:56

Re: A stop job running for user manager uid 1000 while using WM and not DE

#30 2021-03-04 22:21:33

Re: A stop job running for user manager uid 1000 while using WM and not DE

#31 2021-03-05 05:15:37

Re: A stop job running for user manager uid 1000 while using WM and not DE

Board footer