Issues with X after update

knuck · 2014-08-30 08:21:54

I hadn't updated my system for about 4 days. Today I updated, and X no longer starts as non-root user. It fails with the following text:

Command line argument number 4 contains unprintable characters
(EE) 
Fatal server error:
(EE) X server aborted because of unsafe environment
(EE) 
(EE) 
Please consult the The X.Org Foundation support 
	 at http://wiki.x.org
 for help. 
(EE) 
xinit: giving up
xinit: unable to connect to X server: Connection refused
xinit: unexpected signal 2

Running it as root simply works.
Running /usr/bin/Xorg.bin as non-root gets me to the desktop, but the computer freezes.

Using nvidia proprietary driver.

jasonwryan · 2014-08-30 08:23:48

https://www.archlinux.org/news/xorg-ser … available/

Not a Sysadmin issue, moving to NC...

knuck · 2014-08-30 08:53:54

As per another thread with similar issues, the following command works as non-root.

startx -- -nolisten tcp vt1

Before marking this issue as solved, could anyone please explain what those arguments are possibly overriding? Is it because startx can't somehow figure out what vt it's running from?

EDIT: and what would I need to do so I wouldn't need to type those arguments each time I want to run X?

Last edited by knuck (2014-08-30 08:54:57)

karol · 2014-08-30 09:48:31

knuck wrote:

EDIT: and what would I need to do so I wouldn't need to type those arguments each time I want to run X?

Have you tried using an alias

alias s="startx -- -nolisten tcp vt1"

rebootl · 2014-08-30 12:07:09

That's a workaround, but it shouldn't be necessary, 'startx' without arguments should work.

Command line argument number 4 contains unprintable characters

This looks suspicious.

How exactly did you try to start X in the first place ? Do you have a .xserverrc in your home directory (note: hidden file by . at the beginning, use 'ls -a ~' to see it' ? Or a modified /etc/X11/xinit/xserverrc ?

These would by overriden by your command.

As per another thread with similar issues

For future, it may be helpful to have it linked here.

Thanks

Edit: Sorry I meant .xserverrc not .xinitrc, corrected above.

Last edited by rebootl (2014-08-30 16:47:49)

knuck · 2014-08-30 16:21:15

karol wrote:

Have you tried using an alias

I did not try an alias because, from what I've read, running startx from a different path might not work in xorg 1.16. Also, as rebootl said, it's a workaround. I'm trying to fix it for real

rebootl wrote:

That's a workaround, but it shouldn't be necessary, 'startx' without arguments should work.
Command line argument number 4 contains unprintable characters
This looks suspicious.
How exactly did you try to start X in the first place ? Do you have a .xserverrc in your home directory (note: hidden file by . at the beginning, use 'ls -a ~' to see it' ? Or a modified /etc/X11/xinit/xserverrc ?

I've been starting X the same way I've always did it on Arch: login to VT, run startx. I don't have a .xserverrc in my ~ (never had, AFAIK) and the contents of /etc/X11/xinit/xserverrc are:

#!/bin/sh
if [ -z "$XDG_VTNR" ]; then
  exec /usr/bin/X -nolisten tcp "$@"
else
  exec /usr/bin/X -nolisten tcp "$@" vt$XDG_VTNR
fi

For future, it may be helpful to have it linked here.

I'll try to find it again and edit here (was running under root and without sleep for a good while).

Contents of my startx
Contents of my .xinitrc

Last edited by knuck (2014-08-30 16:24:29)

rebootl · 2014-08-30 16:39:37

Ok, your files look fine to me.

Because of the "suspicios" output mentioned above I think there's something wrong with your $XDG_VTNR variable. That would be the fourth argument used by /etc/X11/xinit/xserverrc. Something wrong with that would lead to your behaviour.

Can you tell the output of 'env |grep XDG' and 'loginctl show-session $XDG_SESSION_ID' on the _console_ (before starting X or on an other VT). Also check if you have failed units etc. And re-check the pacman.log from the update that introduced the problem. Were there any messages overseen, maybe .pacnew files not handled etc.

Edit: The $XDG_VTNR variable should contain the number of the VT you are on. I'm not perfectly sure what should set this, I think systemd, respectively logind...

Edit: Sorry it's $XDG_VTNR not $XDG_VT, corrected above.

Last edited by rebootl (2014-08-30 16:46:20)

knuck · 2014-08-30 16:58:26

rebootl wrote:

Ok, your files look fine to me.
Because of the "suspicios" output mentioned above I think there's something wrong with your $XDG_VTNR variable. That would be the fourth argument used by /etc/X11/xinit/xserverrc. Something wrong with that would lead to your behaviour.
Can you tell the output of 'env |grep XDG' and 'loginctl show-session $XDG_SESSION_ID' on the _console_ (before starting X or on an other VT). Also check if you have failed units etc. And re-check the pacman.log from the update that introduced the problem. Were there any messages overseen, maybe .pacnew files not handled etc.

$XDG_VTNR seems to be storing the correct VT.

pacman.log

env |grep XDG:

XDG_VTNR=2
XDG_SESSION_ID=c2
XDG_SEAT=seat0
XDG_RUNTIME_DIR=/run/user/1000

loginctl show-session $XDG_SESSION_ID:

Id=c2
Name=knuck
Timestamp=Sat 2014-08-30 06:14:17 BRT
TimestampMonotonic=1982502489
VTNr=2
TTY=tty2
Remote=no
Service=login
Scope=session-c2.scope
Leader=1312
Audit=0
Type=tty
Class=user
Active=yes
State=active
IdleHint=no
IdleSinceHint=1409417600532016
IdleSinceHintMonotonic=29525423530

rebootl · 2014-08-30 18:38:44

Yeah, that all looks allright, so it wasn't that.
Currently I don't see what the problem might be...
What's the output of 'type startx'.

... Ok, forget about it. I should've been more skeptical when you said 'my startx'.

Unless I did something wrong when comparing to mine (unmodified), Edit: See the last edit. ~~I can see that it's not the default one and that's likely the problem. I can see that it says in the source:~~

# Site administrators are STRONGLY urged to write nicer versions.

~~but I don't think that's really necessary. I didn't even know it was a shell script...~~

~~So what's that thing ? Why not use the default ? And moreover why not telling us that you changed it ? If you don't know or don't remember give the output asked above.~~

Edit: punctuation, wording

Edit: ~~At least you gave us it's content (startx). So, must've been aware that it might have something to do with it .~~

Edit: Ok, I did wrong, sorry, my system wasn't up-to-date...
Could you please downgrade xorg-xinit and see if that fixes it.
And to be on safe side the output asked above.

Last edited by rebootl (2014-08-30 19:02:18)

loqs · 2014-08-30 19:02:30

Looking at the linked startx http://pastebin.com/jNedFwuB vs /usr/bin/startx seems there is some whitespace after the lastline on the pastebin version (compare done using meld)

diff -w raw.php /usr/bin/startx

diff ignoring the whitespace matches (my version xorg-xinit 1.3.3-4)
Edit: spelling
Edit2: perhaps you need Xorg.wrap see man Xorg.wrap and the needs_root_rights option set to yes

Last edited by loqs (2014-08-30 19:10:29)

rebootl · 2014-08-30 19:03:14

Yeah, sorry for this, see my edit above. *shame*

Edit: However, if downgrading fixes it, it looks as if there may be a bug in xorg-xinit/startx ?!? Or am I completely off now ... ?
(At least the file has changed with the last update.)

Edit: This is the diff I got to the previous version:

$ diff startx-user /usr/bin/startx 
18a19
> 
28d28
< vtarg=""
40d39
< 
89a89,94
> 
> 
> 
> 
> 
> 
103,113d107
< 
<     # When starting the defaultserver start X on the current tty to avoid
<     # the startx session being seen as inactive:
<     # https:
<     tty=$(tty)
<     if expr match "$tty" '^/dev/tty[0-9]\+$' > /dev/null; then
<         tty_num=$(echo "$tty" | grep -oE '[0-9]+$')
<         vtarg="vt$tty_num"
<     fi
< 
< 
129,139d122
< # if no vt is specified add vtarg (which may be empty)
< have_vtarg="no"
< for i in $serverargs; do
<     if expr match "$i" '^vt[0-9]\+$' > /dev/null; then
<         have_vtarg="yes"
<     fi
< done
< if [ "$have_vtarg" = "no" ]; then
<     serverargs="$serverargs $vtarg"
< fi
< 
214a198
> xinit "$client" $clientargs -- "$server" $display $serverargs
218,220d201
< 
< xinit "$client" $clientargs -- "$server" $display $serverargs
< 
230,237d210
< fi
< 
< 
< 
< 
< 
< if command -v deallocvt > /dev/null 2>&1; then
<     deallocvt

Edit: I played a bit with the commands in that change but I don't see what could be causing this. Again, sorry for insulting/accusing you.

Last edited by rebootl (2014-08-30 20:10:46)

ssri · 2014-09-29 05:44:06

Anyone resolved this issue? I made my beef about this known in a separate catch-all thread. A reply stated that there were some upstream patches that were applied. One of which passes vtX unless the user specifies one. I wonder if the wrong value of vtX gets passed that results in X being unable to start with simply 'startx'. Anyways, 'startx' still doesn't start X unless one includes the arguments from post #3. Quite the change from the past several years of starting X from CLI! Also, can anyone link the discussion mentioned in post #3?

Last edited by ssri (2014-09-29 05:48:49)

berbae · 2014-09-29 09:24:48

The problem to resolve is probably on your installation, because startx works without any argument on a normal configuration.
The default '/etc/X11/xinit/xserverrc' is used then:

#!/bin/sh
if [ -z "$XDG_VTNR" ]; then
  exec /usr/bin/X -nolisten tcp "$@"
else
  exec /usr/bin/X -nolisten tcp "$@" vt$XDG_VTNR
fi

The variable XDG_VTNR is set by systemd-logind and its value is the tty where the user logged in.
If XDG_VTNR is not set for you (as this seems to be the case), this is not normal, as this is done by logind at login time.

ssri · 2014-09-29 15:26:35

berbae wrote:

The problem to resolve is probably on your installation, because startx works without any argument on a normal configuration.
The default '/etc/X11/xinit/xserverrc' is used then:
#!/bin/sh
if [ -z "$XDG_VTNR" ]; then
  exec /usr/bin/X -nolisten tcp "$@"
else
  exec /usr/bin/X -nolisten tcp "$@" vt$XDG_VTNR
fi
The variable XDG_VTNR is set by systemd-logind and its value is the tty where the user logged in.
If XDG_VTNR is not set for you (as this seems to be the case), this is not normal, as this is done by logind at login time.

Nope

$cat /etc/X11/xinit/xserverrc 
#!/bin/sh
if [ -z "$XDG_VTNR" ]; then
  exec /usr/bin/X -nolisten tcp "$@"
else
  exec /usr/bin/X -nolisten tcp "$@" vt$XDG_VTNR
fi

$cat /etc/X11/xinit/xserverrc 
#!/bin/sh
#
# ~/.xinitrc
#
# Executed by startx (run your window manager from here)

if [ -d /etc/X11/xinit/xinitrc.d ]; then
  for f in /etc/X11/xinit/xinitrc.d/*; do
    [ -x "$f" ] && . "$f"
  done
  unset f
fi

# exec enlightenment_start
# exec gnome-session
exec startkde
# exec startxfce4
# ...or the Window Manager of your choice
# exec awesome

$cat /etc/X11/Xwrapper.config
allowed_users = console
needs_root_rights = yes

No xorg.conf, nothing. On my laptop setup (nvidia optimus), I try to keep the basic config vanilla.

Checking the $XDG_VTNR variable in tty2:

$env | grep XDG
XDG_VTNR=2
XDG_SESSION_ID=c2
XDG_SEAT=seat0
XDG_RUNTIME_DIR=/run/user/1000

$loginctl show-session $XDG_SESSION_ID
Id=c2
Name=me
Timestamp=Mon 2014-09-29 08:30:52 PDT
TimestampMonotonic=875352628
VTNr=2
TTY=tty2
Remote=no
Service=login
Scope=session-c2.scope
Leader=23369
Audit=0
Type=tty
Class=user
Active=yes
State=active
IdleHint=no
IdleSinceHint=1412005040158747
IdleSinceHintMonotonic=1262690650

Last edited by ssri (2014-09-29 15:40:47)

rebootl · 2014-09-29 16:11:46

Are you sure that you _don't_ have a .xserverrc in your home directory (hidden file by dot at the beginning) ?

If you don't have this, we/you'd have to figure out if the xorg-xinit is the culprint. I remember that from the time the topic was opened and from the description in post #1 I came to the conclusion that xorg-xinit could be the problem. You'd have to downgrade this to previous versions to find out. (As I asked above, but didn't got any reply anymore.)

Finally if it's not your config then it may be your "hardware specific setup". Meaning you say it's optimus, I assume some config was necessary to get this working. I don't know this, and I don't know what this all did...

ssri · 2014-09-29 17:53:08

There's no ~/.xserverrc, never has been.

Downgrading xorg-xinit to xorg-xinit-1.3.3-3-x86_64.pkg.tar.xz (courtesy of ARM) is a workaround (now X can start with simply 'startx').

Could be a regression (follow-up link to the upstream patches link I provided earlier): Upstream Bug #1111684 - startx doesn't add -nolisten tcp by default

Like the bug submitter, my systemd is configured for multi-user.target. Unlike the bug submitter, in addition I have to pass vtx despite the purported ability of startx correctly detecting which vt the user is on and launch from there.

Last edited by ssri (2014-09-29 18:25:47)

rebootl · 2014-09-29 18:13:04

Ok, I think you may be right about the regression. Just to be sure, there were no other packages downgraded at the same time ?

If we are sure that xorg-xinit is the culprint, I believe the next sane step would be to try to figure out whether it's a bug in the arch package or upstream, and then report to the appropriate place.

My above debugging trys were a failure, so I'd have to re-look at that, but I can't do it just right now... additionally what makes it a bit harder to debug here is that this bug is not triggered here, 'startx' just works...

Edit: If you can't figure it out you may report a bug on the Arch bugtracker (search it for this bug first). Maybe the Arch packager of xorg-xinit has some insight as well. Maybe we could also get a second opinion here ...

Last edited by rebootl (2014-09-29 18:20:22)

ssri · 2014-09-29 18:23:35

Actually xorg-xinit-git still displays the same issue. Interestingly, after reading the bug report, I realized that the correct vtx is still unable to pass. The -nolisten tcp issue either has been patched out or was inapplicable to me, but the vtx issue remains. 'startx -- vt1' works in both git and extra versions of xorg-xinit for, but that was unnecessary in xorg-xinit-1.3.3-3-x86_64.pkg.tar.xz.

Last edited by ssri (2014-09-29 18:25:03)

rebootl · 2014-09-29 18:33:17

When using the -git version, respectively git you may be able to bisect, to find the exact commit that has caused your issue.

Bisecting using makepkg is somewhat tedious but you can adapt the PKGBUILD to use a specific commit. You can use a separately cloned repo (using git) where you do the bisect (keep it in your home, only bisect but don't install anything from there) and use the adapted -git package to build, install and test the respective commits you get from the bisect.

There surely are other/better ways to do it as well...

Edit: clarify

Edit: Note, you don't have to do this. You might as well simply bugreport it, I think it might be an upstream issue. Maybe I can have another look at this tomorrow.
Regards

Last edited by rebootl (2014-09-29 20:57:45)

rebootl · 2014-09-30 18:23:11

- sigh

All this is somehow messy... No solution yet, however some findings below.

'startx' already creates the correct vt number but in the default xserverrc we use $XDG_VTNR so I get:

$ ps ax|grep Xorg
 7184 pts/5    S+     0:00 grep Xorg
27394 tty1     S<l   23:20 /usr/bin/Xorg.bin -nolisten tcp :0 vt1 -auth /tmp/serverauth.ZrrB9zAcQ9 vt1

Note the double vt... maybe there's a reason to do it this way ~~(?)~~[^*].

But that's not really the problem I think.

Please also verify your binaries/links:

$ ls -l /usr/bin/X
lrwxrwxrwx 1 root root 4 Sep 21 12:54 /usr/bin/X -> Xorg
$ ls -l /usr/bin/Xorg*
-rwxr-xr-x 1 root root     277 Sep 21 12:54 /usr/bin/Xorg
-rwxr-xr-x 1 root root 2245240 Sep 21 12:54 /usr/bin/Xorg.bin
-rwsr-xr-x 1 root root   10488 Sep 21 12:54 /usr/bin/Xorg.wrap

I played a bit with the startx script but I can't see something obvious. I commentented out the xauth and the final call parts, and inserted some echo's that output the variables that are created by startx, e.g.:

xinit debug output
------------------
client: /home/cem/.xinitrc
clientargs: 
--
server: /etc/X11/xinit/xserverrc
display: :1
serverargs:

This output is from inside X but when called from the console it creates the correct arguments here e.g. "serverargs: vt2" .

Maybe you want to test on your system, I think it's fine to place it in your home and call from there (call from console, it doesn't start X).
Maybe you can adapt it to debug further... (add more echos or so)
Adapted code: http://pastebin.com/03nPBYmv

Regards (Edit: + good luck)

Edit: [^*]: Probably the reason was because this was done _before_ the xorg-xinit update, that creates the correct options, came.

Edit: Maybe your issue has to do with: https://bugs.archlinux.org/task/41776 + do you get the 'suspicious' error from above as well ? I think this could be the cause of this error.

Edit: I reported the vt issue: https://bugs.archlinux.org/task/42193

Last edited by rebootl (2014-09-30 18:52:02)

berbae · 2014-10-01 09:48:48

After looking into the startx script since the xorg-xinit 1.3.3-4 update, I agree with Rebootl's analyze in the bug ticket he opened.
There is a problem when startx is run without any arguments, which results in two vtX parameters passed to the Xorg.bin command line.
One is determined inside startx using the 'tty' command, and the other comes from the default '/etc/X11/xinit/xserverrc' and is set to vt$XDG_VTNR .
So the ssri's problem comes probably from that, as everything seems rightly configured. I didn't notice the changes before seeing that thread, so I thought everything worked as before.
I don't know how the Xorg.bin binary acts when there are two vtX parameters; on my machine there is no incidence and the two vtX are the same.
But it seems that may not be the case in every cases. I will look into the Xorg binary to find how the vtX parameter is used, and what happens when there are two different vtX in the command line.

rebootl · 2014-10-01 20:32:25

Okay, as for the very initial issue in this thread with the, by me called, 'suspicious' error. I just tested and the problem is effectively the one explained in the first bug report I linked above (the one about colored grep, not the one with the double vt).
Using export GREP_OPTIONS='--color=always' I can reproduce the error exactly. I reported this upstream: https://bugs.freedesktop.org/show_bug.cgi?id=84532
However, it's still in discussion, whether they want to accept this as a bug or not...

Edit: punctuation

Edit: As for the vt issue, by testing I get the impression that the last vt argument given to X is the one that get's used.
E.g.:

$ X :1 vt5 vt1
(X starts on vt1)
$ X :1 vt1 vt5
(X starts on vt5)

That would be the one specified by $XDG_VTNR. It should be correct, the one created by tty should also be correct. At least here, X seems to start in any case. So, maybe it's just a cosmetic issue...

Edit: Btw. Thanks for your efforts/opinions so far, berbae, ssri.

Last edited by rebootl (2014-10-01 22:16:36)

ssri · 2014-10-02 01:16:50

rebootl wrote:

Okay, as for the very initial issue in this thread with the, by me called, 'suspicious' error. I just tested and the problem is effectively the one explained in the first bug report I linked above (the one about colored grep, not the one with the double vt).
Using export GREP_OPTIONS='--color=always' I can reproduce the error exactly. I reported this upstream: https://bugs.freedesktop.org/show_bug.cgi?id=84532
However, it's still in discussion, whether they want to accept this as a bug or not...

Thanks rebootl for looking into this issue more deeply. Sorry for the lack of response, but I've been in transit the past two days. Yes, I have the GREP_OPTIONS environment variable set to the above. I'm going to set it to auto now that I've looked into how evil --color=always is with respect to grep outputs. And if it is teh evils, then someone should put in a request to depreciate the 'always' option.

Last edited by ssri (2014-10-02 01:18:00)

Arch Linux

#1 2014-08-30 08:21:54

Issues with X after update

#2 2014-08-30 08:23:48

Re: Issues with X after update

#3 2014-08-30 08:53:54

Re: Issues with X after update

#4 2014-08-30 09:48:31

Re: Issues with X after update

#5 2014-08-30 12:07:09

Re: Issues with X after update

#6 2014-08-30 16:21:15

Re: Issues with X after update

#7 2014-08-30 16:39:37

Re: Issues with X after update

#8 2014-08-30 16:58:26

Re: Issues with X after update

#9 2014-08-30 18:38:44

Re: Issues with X after update

#10 2014-08-30 19:02:30

Re: Issues with X after update

#11 2014-08-30 19:03:14

Re: Issues with X after update

#12 2014-09-29 05:44:06

Re: Issues with X after update

#13 2014-09-29 09:24:48

Re: Issues with X after update

#14 2014-09-29 15:26:35

Re: Issues with X after update

#15 2014-09-29 16:11:46

Re: Issues with X after update

#16 2014-09-29 17:53:08

Re: Issues with X after update

#17 2014-09-29 18:13:04

Re: Issues with X after update

#18 2014-09-29 18:23:35

Re: Issues with X after update

#19 2014-09-29 18:33:17

Re: Issues with X after update

#20 2014-09-30 18:23:11

Re: Issues with X after update

#21 2014-10-01 09:48:48

Re: Issues with X after update

#22 2014-10-01 20:32:25

Re: Issues with X after update

#23 2014-10-02 01:16:50

Re: Issues with X after update

Board footer