xorg-server 1.16 issues

jjacky · 2014-08-12 19:16:08

Trilby wrote:

However, then the error output is banished never to be seen again.

Right, so about that... I tried to have a look into it, and here's what I ended up with:

Basicaly, when X starts, it tries to determine which tty it is running from. When running from the same as the vt it was asked to run in (i.e. from tty2 with vt02 as argument) it will auto-enable keeptty, which means it won't "detach from its controlling tty", which is rather important since otherwise some ioctl calls would fail with a permission error.
And in fact, when redirecting stderr the error I get is indeed a permission denied for VT_ACTIVATE, and it comes from having detached from the controlling tty. Whereas when I don't redirect, I get in the Xorg.log something that reads "controlling tty is VT number 2, auto-enabling KeepTty"

So here's for a quick workaround so you can start rootless X while still redirecting everything you want: simply specify server option -keeptty

Now as for why this fails, I wish I knew. What I'm seeing is that X will check if STDIN_FILENO, STDOUT_FILENO or STDERR_FILENO (in that order) are a tty. As soon as one is found, it'll use it to compare with the vt it is expected to run on. Now you'd think that stdin is indeed your tty, so that's a match and it should always work. But in fact, what I'm seeing is that only STDERR_FILENO is actually the stderr, which is why it is essential and cannot be redirected to a file.

I'm not sure what's up with the other two though, but if I check fileno(stdin), fileno(stdout) & fileno(stderr) then only the later works (2), the other two return -1, which means invalid stream. What does that actually mean, why it happens, I don't know. But indeed the fstat call on those fd does get some "odd" results, as in it doesn't fail but return info that aren't what you'd expect, e.g. for STDOUT_FILENO I get a socket apparently...

Trilby · 2014-08-12 19:43:51

Thanks, this works perfectly (so far):

... && exec xinit -- vt1 -keeptty > ~/.xorg.log 2>&1

(ellipsis for my case statement conditionals)

note: vt1 is used explicitly as one of the conditionals checks which tty it's on. For a more general case one should, of course, use vt$XDG_VTNR.

Last edited by Trilby (2014-08-12 19:45:08)

PReP · 2014-08-14 03:13:53

Stole the trilby intel which was borrowed and derived from jjacky. Thanks

jjacky · 2014-08-17 14:51:23

So for the record, I believe I figured out the reason of the odd results I observed: both stdin & stdout are actualy closed earlier on, so the code there doesn't do what was meant, except for stderr. I'm not sure how to fix this, but I've opened a bug report upstream: https://bugs.freedesktop.org/show_bug.cgi?id=82732

kamocat · 2014-08-21 05:12:54

So, from my understanding, we have a workaround for getting the stdout from Xorg, but we're waiting on a patch to be applied to xorg-server in order to run multiple sessions.
Is this correct?

jjacky · 2014-08-21 08:29:42

The workaround is to start a rootless X while redirecting stderr; The fix to run more than one rootless X is actually in systemd (logind), and is included in the upcoming 216.

Alad · 2014-08-27 04:28:16

Well, I've updated to 216 and while there was clearly some change in logind (I had to restart it, else ALSA would complain on missing permissions), I still can't seem to run more than one X server... at least as the same user.

Last edited by Alad (2014-08-27 04:28:49)

karol · 2014-08-28 08:33:19

Did you reboot after the update? How exactly are you starting X and what fails when trying to start the second X server as a user?

Alad · 2014-08-28 19:49:34

Found out the issue - I was using the xinit -keeptty workaround (which mentioned how X was already in use); with startx and systemd 216 both redirection and multiple instances work fine.

edit: after another reboot it seems startx > ~/.xorg.log 2>&1 fails with the same VT_ACTIVATE error.. so you either have redirection -or- multiple instances?

Last edited by Alad (2014-08-28 20:10:24)

jjacky · 2014-08-28 21:09:32

You still need to use -keeptty (e.g. in your ~/.xserverrc) if you want to use redirection of stderr, otherwise you'll get the permission denied error for VT_ACTIVATE.

Alad · 2014-08-29 00:57:00

startx -- -keeptty > ~/.xorg.log 2>&1

seems to work for both redirection and multiple instances. Thanks jjacky.

karol · 2014-09-05 19:20:57

If you start a couple X servers this way you should specify something other than just ~/.xorg.log as the log. What would be the best filename?

alias s="startx -- -keeptty > ~/.xorg-vt$XDG_VTNR-$(date +"%Y-%m-%d-%H:%M:%S").log 2>&1"

$ type s
s is aliased to `startx -- -keeptty > ~/.xorg-vt1-2014-09-05-21:14:06.log 2>&1'

I think it's time to properly fix https://wiki.archlinux.org/index.php/Start_X_at_Login

Does anyone else get a broken console after quiting X? Pressing 'Enter' produces a new prompt but on the same line etc. I have to blindly type 'exit' and re-log to get a usable console.

Trilby · 2014-09-05 19:30:57

karol wrote:

Does anyone else get a broken console after quiting X?

Yes. It's not broken, the standard streams have just been redirected. Personally I consider this a bug: if a program opts to redirect standard streams, that's fine, but it should reset them when it's done.

lolilolicon · 2014-09-05 21:13:08

karol wrote:

If you start a couple X servers this way you should specify something other than just ~/.xorg.log as the log. What would be the best filename?
alias s="startx -- -keeptty > ~/.xorg-vt$XDG_VTNR-$(date +"%Y-%m-%d-%H:%M:%S").log 2>&1"
$ type s
s is aliased to `startx -- -keeptty > ~/.xorg-vt1-2014-09-05-21:14:06.log 2>&1'

You want single quotes instead of double quotes when defining the alias, so the expansions are done later.
Personally I'd just use +%s as the date format.

Alad · 2014-09-06 10:35:41

Trilby wrote:

karol wrote:
Does anyone else get a broken console after quiting X?
Yes. It's not broken, the standard streams have just been redirected. Personally I consider this a bug: if a program opts to redirect standard streams, that's fine, but it should reset them when it's done.

If you put "exec" before startx in your alias, killing X (or exiting your WM) logs you out from the console, if you prefer. You can also return to a usable console by typing "reset".

Re redirection, I've come up with a more complex solution that filters duplicate lines and compresses the log if it gets too large:

http://pastie.org/9533549

should prevent 20 GB logs if things go AWOL.

edit: meh, blocks redirection after the first awk.

Last edited by Alad (2014-09-07 10:24:40)

tomgg · 2014-09-09 12:05:56

jasonwryan wrote:

...Fix for me:

Jasonwryan, does the rootless X server give you trouble when quitting, say, dwm?^{1} ...I'd elaborate but it would require a whole bunch of mindless rigmarole (reboot included).

--
1. I know that you use dwm.

EDIT; I should've read more that the first 7 posts in the thread.

Last edited by tomgg (2014-09-09 12:06:43)

karol · 2014-09-10 19:06:39

What exactly do you mean? What kind of trouble? Why would explaining require a reboot??

tomgg · 2014-09-22 00:40:58

karol wrote:

What exactly do you mean? What kind of trouble? Why would explaining require a reboot??

Sorry, I'd forgotten that this happened---I don't reboot too frequently.

Upon exiting dwm, I'll be issued a repeating sequence of---and I'm paraphrasing; I don't know where this is logged (Where is this logged?)---"sending KILL to all processes", "waiting on X", "could not close X", which doesn't appear to ever end.

Sorry I can't give a clearer picture. I can post that log if you know where it is. Meanwhile, I'll pay a bit more attention next time I replicate the issue, which is only an issue (for me) when I'm playing around with dwm patches.

funny · 2014-09-24 08:01:48

Hi, after my last update xserver often shutdown.
I see a error in my Xorg.0.log

 Backtrace:
[ 12121.882] (EE) 0: /usr/bin/Xorg.bin (xorg_backtrace+0x56) [0x593a46]
[ 12121.882] (EE) 1: /usr/bin/Xorg.bin (0x400000+0x197b99) [0x597b99]
[ 12121.882] (EE) 2: /usr/lib/libc.so.6 (0x7f9dfcf5a000+0x339f0) [0x7f9dfcf8d9f0]
[ 12121.882] (EE) 
[ 12121.882] (EE) Segmentation fault at address 0x0
[ 12121.882] (EE) 
Fatal server error:
[ 12121.882] (EE) Caught signal 11 (Segmentation fault). Server aborting

I use 64bit arch and xfce4

Last edited by funny (2014-09-24 08:02:35)

lolilolicon · 2014-09-24 08:09:20

@funny, the error message is not very helpful. You should probably open another thread for this, but prepare more background and info, becaue it will be needed for anyone to get a clue where to start.

olive · 2014-09-24 10:37:26

I think it is related to the message

xorg-server has now the ability to run without root rights with
the help of systemd-logind. xserver will fail to run if not launched
from the same virtual terminal as was used to log in.
Without root rights, log files will be in ~/.local/share/xorg/ directory.
 
Old behavior can be restored through Xorg.wrap config file.
See Xorg.wrap man page (man xorg.wrap).

that we had when we have upgraded xorg-server. For some reason, you are not on a physical console when you use an alias. I guess that it will work if you "restore the old behavior". Even if I am right, it is strange that using an alias or running the command directly can make a difference. What happens if you use a shell script instead of an alias?

Last edited by olive (2014-09-24 10:38:14)

karol · 2014-12-02 03:46:21

Before I mark this as solved, I'd like to check if anyone got a fix or an even better workaround for the broken tty after quiting X: https://bbs.archlinux.org/viewtopic.php … 7#p1453977
I've added '; reset' to my alias:

$ type s
s is aliased to `startx -- -keeptty > ~/temp/.xorg-vt$XDG_VTNR-$(date +"%Y-%m-%d-%H:%M:%S").log 2>&1; reset'

Works for me ...

Trilby · 2014-12-02 12:23:02

I don't know when it happened, but this was 'fixed' for my in one of the updates shortly after 1.16. I can startx/xinit, then when I quite I am back at a working tty.

karol · 2014-12-02 12:24:20

How exactly are you starting X? I'm using the alias I posted. Any black magic in your ~/.xinitrc?

Trilby · 2014-12-02 12:27:43

Nope. In my bashrc

if [[ -z $DISPLAY && $XDG_VTNR -eq 1 ]]; then
	read -s -n 1 -t 0.25 key
	[[ $? -eq 142 ]] && exec xinit -- vt1 -nolisten tcp
fi

But I will also frequently hit a key to prevent this from running to be able to work in the tty - then I use 'xinit -- vt1' and if/when I exit that session I'm also back at a workting tty.

Arch Linux

#51 2014-08-12 19:16:08

Re: xorg-server 1.16 issues

#52 2014-08-12 19:43:51

Re: xorg-server 1.16 issues

#53 2014-08-14 03:13:53

Re: xorg-server 1.16 issues

#54 2014-08-17 14:51:23

Re: xorg-server 1.16 issues

#55 2014-08-21 05:12:54

Re: xorg-server 1.16 issues

#56 2014-08-21 08:29:42

Re: xorg-server 1.16 issues

#57 2014-08-27 04:28:16

Re: xorg-server 1.16 issues

#58 2014-08-28 08:33:19

Re: xorg-server 1.16 issues

#59 2014-08-28 19:49:34

Re: xorg-server 1.16 issues

#60 2014-08-28 21:09:32

Re: xorg-server 1.16 issues

#61 2014-08-29 00:57:00

Re: xorg-server 1.16 issues

#62 2014-09-05 19:20:57

Re: xorg-server 1.16 issues

#63 2014-09-05 19:30:57

Re: xorg-server 1.16 issues

#64 2014-09-05 21:13:08

Re: xorg-server 1.16 issues

#65 2014-09-06 10:35:41

Re: xorg-server 1.16 issues

#66 2014-09-09 12:05:56

Re: xorg-server 1.16 issues

#67 2014-09-10 19:06:39

Re: xorg-server 1.16 issues

#68 2014-09-22 00:40:58

Re: xorg-server 1.16 issues

#69 2014-09-24 08:01:48

Re: xorg-server 1.16 issues

#70 2014-09-24 08:09:20

Re: xorg-server 1.16 issues

#71 2014-09-24 10:37:26

Re: xorg-server 1.16 issues

#72 2014-12-02 03:46:21

Re: xorg-server 1.16 issues

#73 2014-12-02 12:23:02

Re: xorg-server 1.16 issues

#74 2014-12-02 12:24:20

Re: xorg-server 1.16 issues

#75 2014-12-02 12:27:43

Re: xorg-server 1.16 issues

Board footer