[SOLVED] Xorg.wrap error

[vcmota]

I am trying to follow a tmux tutorial but whenever I run tmux in the terminal I get the following error message:

Code: Select all

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

Despite of this I am apparently inside tmux, but if I switch workspaces something simply crashes:

Code: Select all

/usr/libexec/Xorg.wrap: Only console users are allowed to run the X server
X connection to :0 broken (explicit kill or server shutdown).
~>

I read somewhere that this may be related with users access to xorg, and that a possible workaround would be to create the file /etc/X11/Xwrapper.config to include the line

Code: Select all

allowed_users=anybody

However, I also read that such an option would add security risks to my sistem, so that it would not be recommended.

It does not seems I have any issue with user access to xorg, since I can login normally and the output of loginctl is

Code: Select all

~> loginctl user-status
vinicius (1000)
           Since: Fri 2020-09-25 01:03:26 -03; 3 days ago
           State: active
        Sessions: *1
          Linger: no
            Unit: user-1000.slice

Anyway, I have a minimal install, using xorg and DWM jointly with other suckless tools such as st, dmenu and slock. I hove no login manager, and my xsession is started via the command

Code: Select all

~> cat .xinitrc
#!/bin/bash

barM &
setxkbmap br
feh --bg-scale /home/vinicius/mybackground/bw.jpg &
lpoptions -o Quality=600GrayscaleK


exec dbus-launch --exit-with-session dwm
~> 

written inside .xinitrc file located in my home folder.

Thank you all for your help!

[Hu]

Why is running a shell under tmux trying to run Xorg at all? Do you have a startup script (~/.bash_profile or similar) that tries to start X automatically?

[vcmota]

Why is running a shell under tmux trying to run Xorg at all? Do you have a startup script (~/.bash_profile or similar) that tries to start X automatically?

Thank yoy Hu for your reply. You are right, and I made a mistake in the description of the problem: I failed to recall that I had to change my setup a few months ago, here you can see the post I made here at that time. I am sorry for that. Now in order for X to properly load, I needed to add to .bash_profile the following lines:

Code: Select all

~> cat .bash_profile
# /etc/skel/.bash_profile

# This file is sourced by bash for login shells.  The following line
# runs your .bashrc and is recommended by the bash info pages.
if [[ -f ~/.bashrc ]] ; then
        . ~/.bashrc
fi

export PATH="$PATH:/home/vinicius/.local/share/applications/"

xinit .xinitrc -- /etc/X11/xinit/xserverrc
~>

otherwise the X session would not start. Beyond this I also have set .xinitrc to properly load DWM:

Code: Select all

~> cat .xinitrc
#!/bin/bash

barM &
setxkbmap br
feh --bg-scale /home/vinicius/mybackground/bw.jpg &
lpoptions -o Quality=600GrayscaleK


exec dbus-launch --exit-with-session dwm
~>

and everything seems to be correct regarding the X session:

Code: Select all

~> loginctl list-sessions
SESSION  UID USER     SEAT  TTY
      3 1000 vinicius seat0 tty1

1 sessions listed.
~> echo $XDG_VTNR
1
~>

Is some of those configurations the reason behind the issue at loading tmux?

Thank you again for your reply.

[Hu]

That ~/.bash_profile will try to start an X session out of every bash. This is almost certainly not what you want, and if you started any xterm or similar terminal emulators inside the session, the pre-rootless behavior would likely result in runaway spawning of more X servers, which would spawn more xterms, which would spawn more X servers, until you ran out of some resource. You are lucky that the current elogind requirement is inhibiting the spawning of more X servers.

I am doubtful of the correctness of that xinit line, but if you want to keep it, and you want X to auto-start, then you need to wrap the line in some test that will be true if, and only if, the bash is running directly on the Linux console - not in tmux, and not in an xterm.

[vcmota]

Thank you Hu for your reply.

That ~/.bash_profile will try to start an X session out of every bash. This is almost certainly not what you want, and if you started any xterm or similar terminal emulators inside the session, the pre-rootless behavior would likely result in runaway spawning of more X servers, which would spawn more xterms, which would spawn more X servers, until you ran out of some resource. You are lucky that the current elogind requirement is inhibiting the spawning of more X servers.

I understood the issue and you are totally correct, this is not the behavior that I wanted. I thought that .bash_profile was only accessed during login, and that only .bashrc would be accessed after login into the Xsession. Since this is not the case, then this is surely not what I wanted.

I am doubtful of the correctness of that xinit line, but if you want to keep it, and you want X to auto-start, then you need to wrap the line in some test that will be true if, and only if, the bash is running directly on the Linux console - not in tmux, and not in an xterm.

That seems more like a workaround than a robust solution. I would certainly prefer a robust solution, since workarounds might eventually manifests themselves in the future in a form of a weird/hard-to-identify-bug, just like it is happening now. So, please let me ask you: what are my options now in your opinion? It seems to me that they are:

• Install a login manager, with the sole purpose of not needing to insert the xinit command into .bash_profile;
• Not using tmux, which would be the first time in many years that my minimal install would limit my capacity of using code that I want;

It would be perfect if there was a way of making xorg read and execute the commands withing .xinitrc within a minimal framework, i. e., without further code (a login manager) and without a buggy workaround (inserting xinit inside .bash_profile).

Thank you again!

[Hu]

~/.bash_profile is processed by any bash that is considered a login shell. Usually, a top-level interactive shell in a terminal is started as a login shell. Each tmux pane is its own terminal, and spawns its own login shell.

Personally, I don't like having Xorg start automatically, so my solution would be to remove the xinit line, replace it with nothing, and run startx when I log in if I want an Xorg session. This will run the commands in .xinitrc when requested, and not before.

[vcmota]

~/.bash_profile is processed by any bash that is considered a login shell. Usually, a top-level interactive shell in a terminal is started as a login shell. Each tmux pane is its own terminal, and spawns its own login shell.

Personally, I don't like having Xorg start automatically, so my solution would be to remove the xinit line, replace it with nothing, and run startx when I log in if I want an Xorg session. This will run the commands in .xinitrc when requested, and not before.

Thank you Hu for your reply.

I find it frustrating that there is not an automatic manner of sorting this out. The wiki offers some options, but all of them through IF statements into .bash_profile, therefore just workarounds. Anyway, since now I understand the cause of the problem I will consider this post as SOLVED.

Thank you again!.

[Hu]

Why is it a workaround to do a test inside ~/.bash_profile? Where would you expect to configure this for it not to be a workaround?

[vcmota]

Why is it a workaround to do a test inside ~/.bash_profile? Where would you expect to configure this for it not to be a workaround?

I dont understand why a code that runs at the users command, like tmux, has to automatically access at its discretion a file that is fundamental to the login process. And the other way around also bothers me: a file that must be read as you first login into a machine, and that contain code that is necessary to start the X session, should not be read by code that runs at the user discretion, at least not automatically. There should be a file that is read only for login purposes. There is a long time that I don't do it but, for example, as far as I can remember when you setup a login manager you don't need to invoke startx through .bash_profile, there are other files to do the job.

Another example: since our last interaction I managed to put forward the following IF statement that does the job automatically:

Code: Select all

~> cat .bash_profile
# /etc/skel/.bash_profile

# This file is sourced by bash for login shells.  The following line
# runs your .bashrc and is recommended by the bash info pages.
if [[ -f ~/.bashrc ]] ; then
        . ~/.bashrc
fi

export PATH="$PATH:/home/vinicius/.local/share/applications/"


if [[ ! ${DISPLAY} && ${XDG_VTNR} == 1 ]]; then
    xinit .xinitrc -- /etc/X11/xinit/xserverrc
fi


~>

So it basically reads DISPLAY in oder to allow or deny execution of xinit. But the wiki itself mentions that this is buggy prone: "the DISPLAY check is fairly fragile. Make sure it isn't influenced by side-effects from earlier in the login process." So it is likely that at some point in the future, when I will no longer remember that we had this conversation, a bug shows up that is related to that IF statement.

That is my point.