[SOLVED]xorg.wrap blocked. Can't connect to xserver since xorg 1.19.1

yhoyhoj · 2017-01-28 17:44:43

EDIT: the solution for me was to use an older kernel (I switched to kernel-lts)

Hello,

Since the last xorg update I can't access the display manager login screen when booting or accessing my window manager at all.
It blocks everything when I boot on the graphical target.
And it also blocks the shutdown after I try to start X with xinit.

I have the same problem when using xinit, it's the same error, copied (by hand) here :

..
..
..
xinit: giving up
xinit: unable to connect to X server: Connection refused

[ellypsis]

xinit: X server refuses to die.

I also get this message several times, after xinit stops :

INFO: task kworker/1:2:290 blocked for more than 120 seconds.
    Not tainted 4.9.6-1 ARCH #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
INFO: task Xorg.wrap:496 blocked for more than 120 seconds.
    Not tainted 4.9.6-1 ARCH #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

The Xorg log doesn't seem to report anything special. But I will try to transfer it to this computer so I can paste it here.
I don't really know what else to check, tell me what could help you.

Thanks !

EDIT: quote to code bloc

Last edited by yhoyhoj (2017-01-29 17:01:53)

WorMzy · 2017-01-28 18:11:54

What is "the display manager"? Which one are you using?

As well as the X log, please also post your journal from an affected session. Also, use code tags, not quote tags: https://wiki.archlinux.org/index.php/Co … s_and_code

Mod note: moving to NC.

yhoyhoj · 2017-01-28 18:48:15

Tahnks your your reply and sorry about the quote tags.
I am using LXDM but it has not been updated recently and worked perfectly since the last update.

Also sorry for the lack of details, I had to transfer the log to this computer to paste them somewhere. Here they are :
Xorg.log (/home/yho/.local/share/xorg/Xorg.0.log) : https://framabin.org/?364100902de4facd# … 3frnc6iRA=
The error is different from the last one. At least it stops by itself now.... (EDIT : new testing, the log file looks the same with the original problem)
Journal (since 30 mins) : https://framabin.org/?20503398898b1f23# … I+n2QgTKs=

Last edited by yhoyhoj (2017-01-28 19:53:19)

seth · 2017-01-28 21:46:22

parse_vt_settings: Cannot open /dev/tty0 (Permission denied)

Can you start X as root?
Do you attempt a rootless X (via lxdm??)

stat /dev/tty0
groups

yhoyhoj · 2017-01-28 22:04:13

I use the default configuration with LXDM installed by pacman. It's basically the setup of the Installation guide.
And I believe it's rootless.

I ran xinit only as a test, but yes without root.
I have now tested a 'sudo xinit' and it started correctly but it's not my usual configuration (old openbox setup that I may have applied to root as well as unprivileged user, instead of the i3 setup I currently use).
It seems to confirm that I normally use rootless X.

The cause doesn't seem to be LXDM but I should probably try another display manager.

stat /dev/tty0

  File: /dev/tty0
  Size: 0         	Blocks: 0          IO Block: 4096   character special file
Device: 6h/6d	Inode: 1037        Links: 1     Device type: 4,0
Access: (0620/crw--w----)  Uid: (    0/    root)   Gid: (    5/     tty)
Access: 2017-01-28 22:54:27.540103088 +0100
Modify: 2017-01-28 22:54:27.540103088 +0100
Change: 2017-01-28 22:54:27.540103088 +0100
 Birth: -

groups

lp wheel uucp games lock users yho sdkusers printadmin

seth · 2017-01-28 22:13:33

/dev/tty0 is ok, rootless LXDM afaik won't work (nor should be the default), so the permission error likely stems from your xinit attempt and does not reflect the lxdm driven issue.
Check the xorg log after a fruitless lxdm approach (watch the timestamp to ensure it's really an up to date log) and maybe try another DM (xdm, lightdm, whatever)

yhoyhoj · 2017-01-28 22:37:28

For a moment I thought it was working, I even started this message with "Thank you it works" but apparently it doesn't....

What I did is :
'pacman -Syu' prior to 'pacman -S xorg-xdm'.
I enabled xdm. And I could log into i3. As usual, excepting the fact that it is a different display manager.
I enabled LXDM for a test and it worked too.

But I tried to reboot to confirm everything was ok and I have this blocking message during boot, again :

INFO: task kworker/3:2:284 blocked for more than 120 seconds.
    Not tainted 4.9.6-1 ARCH #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
INFO: task Xorg.wrap:438 blocked for more than 120 seconds.
    Not tainted 4.9.6-1 ARCH #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

(only some numbers changed)

After some new tries, xdm seems to not work more reliably. It defaults to default target instead of blocking the boot process completely but it blocks shutdown like LXDM.

Last edited by yhoyhoj (2017-01-28 22:47:17)

seth · 2017-01-29 00:51:47

So what's the xorg log after such failure?
If the log is unspecific, strace Xorg.wrap and check what resource it's apparently waiting for.

yhoyhoj · 2017-01-29 11:41:08

Thank you for your help.
I tried again this morning with xdm enabled and have linked the logs below.
Apparently the files are from yesterday. I was also booting with xdm then, though.

If you want to have a look :
/home/yho/.local/share/xorg/Xorg.0.log
https://framabin.org/?6bbd5b9f429c5639# … 32832A3T0=
/var/log/Xorg.0.log
https://framabin.org/?93731c31ee67fba2# … 9QcAuE1Q0=

I also extracted the boot message from the journal but it is too terse to help (see around Jan 29 12:24 for xdm failure)
https://framabin.org/?b674cdef9c209bd6# … XlzFsVL74=

I tried

strace -p 'pid of xorg.wrap'

It didn't display anything and refused to detach with Ctrl-C and couldn't be killed with 'kill' either.

I also tried to reinstall all the packages which have "xorg" in their name but it didn't help.

seth · 2017-01-29 13:45:59

First log is terribly dated (look at the xorg version) and the second one is from a perfectly successful Xorg session.

You'll have to "strace /usr/lib/xorg-server/Xorg.wrap 2>&1 | tee ~/xorg.strace" - the server is probably waiting in some kernel call (marked "D")
Also notice the spelling (upcase Xorg.wrap) when choosing a PID.

yhoyhoj · 2017-01-29 14:49:11

I had not noticed the very old version numbers in the first log. In don't know how I found this one. There is a new one now but it looks exactly like one I linked before (after running xinit), and it was after running the strace below.
But yes according to 'ps' the process is waiting for a kernel call.

When I try to strace a running Xorg.wrap with "strace -p 410 2>&1 | tee ~/xorg2.strace", nothing is displayed.

I then tried with the command you gave me, here is the file xorg.strace :

execve("/usr/lib/xorg-server/Xorg.wrap", ["/usr/lib/xorg-server/Xorg.wrap"], [/* 15 vars */]) = 0
brk(NULL)                               = 0xb9f000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=296218, ...}) = 0
mmap(NULL, 296218, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fa0102de000
close(3)                                = 0
open("/usr/lib/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\320`\0\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=143432, ...}) = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa0102dc000
mmap(NULL, 2212880, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa00fee8000
mprotect(0x7fa00ff00000, 2093056, PROT_NONE) = 0
mmap(0x7fa0100ff000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x17000) = 0x7fa0100ff000
mmap(0x7fa010101000, 13328, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fa010101000
close(3)                                = 0
open("/usr/lib/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260\3\2\0\0\0\0\0"..., 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=1951744, ...}) = 0
mmap(NULL, 3791152, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fa00fb4a000
mprotect(0x7fa00fcdf000, 2093056, PROT_NONE) = 0
mmap(0x7fa00fede000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x194000) = 0x7fa00fede000
mmap(0x7fa00fee4000, 14640, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fa00fee4000
close(3)                                = 0
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa0102da000
arch_prctl(ARCH_SET_FS, 0x7fa0102da700) = 0
mprotect(0x7fa00fede000, 16384, PROT_READ) = 0
mprotect(0x7fa0100ff000, 4096, PROT_READ) = 0
mprotect(0x601000, 4096, PROT_READ)     = 0
mprotect(0x7fa010327000, 4096, PROT_READ) = 0
munmap(0x7fa0102de000, 296218)          = 0
set_tid_address(0x7fa0102da9d0)         = 465
set_robust_list(0x7fa0102da9e0, 24)     = 0
rt_sigaction(SIGRTMIN, {sa_handler=0x7fa00feedb70, sa_mask=[], sa_flags=SA_RESTORER|SA_SIGINFO, sa_restorer=0x7fa00fef9080}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {sa_handler=0x7fa00feedc00, sa_mask=[], sa_flags=SA_RESTORER|SA_RESTART|SA_SIGINFO, sa_restorer=0x7fa00fef9080}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM64_INFINITY}) = 0
brk(NULL)                               = 0xb9f000
brk(0xbc0000)                           = 0xbc0000
open("/etc/X11/Xwrapper.config", O_RDONLY) = -1 ENOENT (No such file or directory)
getuid()                                = 0
open("/dev/dri/card0", O_RDWR

It was blocked at this point and I had to kill it from another tty. No closing parenthesis at the end.
The file /dev/dri/card0 is not missing, the permission rules are the same than for the other files in /dev/dri/.

In case it helps I use the 'nouveau' driver and my computer has a Geforce GT630M.
The Ubuntu wiki links /dev/dri/card0 with the i915 module but I see it running when using : "lsmod | grep i915".

I tried to do "udevadm info -a -n /dev/dri/card0".
It gave some info on the device but it then hang when trying to display the parent device which has no recognizable name.
And now that I try to save the output to a file it doesn't work anymore... But it could be because other instances are running, they still appear in "ps" despite killing them.

(edit:typo)

Last edited by yhoyhoj (2017-01-29 15:10:25)

pensnarik · 2017-01-29 15:08:13

Have the same issue. I use XFCE and slim.

seth · 2017-01-29 15:33:36

Is this an optimus system (ie. do you have an intel and nvidia chip)?
If so, which approach do you take on it (apparently not bumblebee ;-)

ppirrip · 2017-01-29 15:35:51

I had the same issue since the update last Sat. Took me a while but I resolved this by downgrading from linux-4.9.6-1-x86_64.pkg.tar.xz back to linux-4.8.13-1-x86_64.pkg.tar.xz. After that my system back to normal.

This is what I have:
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
01:00.0 VGA compatible controller: NVIDIA Corporation GK107M [GeForce GT 640M] (rev a1)

I installed the nvidia and nvidia-libgl this morning, then even the linux 4.9.6 works after reboot.

yhoyhoj · 2017-01-29 17:01:15

So, it seems the real culprit was the linux kernel update and not the x-server update.

I have switched to linux-lts kernel for now as I don't have much more time to lose.
I also don't want to have an outdated package.
And at least it works.

I hope I am not missing on too much new features. I will certainly try to go back to the stable branch when I have more time.

Thank you very much for your time, seth ! Your help was very valuable, and I have learned some new things thanks to you.
Thanks ppirrip for suggesting a kernel change.

I put solved in the title.
@Pensnarik you should probably open a new thread if you want to fix this problem with the last kernel. I am not sure but I think the title is not right and the culprit is the kernel.
If it's not the right solution, I let the mods remove the [Solved] tag from the title.

EDIT:
Just in case it could help others pinpoint the source of the problem, I have this :
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
01:00.0 VGA compatible controller: NVIDIA Corporation GF108M [GeForce GT 630M] (rev a1)
without special nouveau config.

Last edited by yhoyhoj (2017-01-29 17:07:40)

Arch Linux

#1 2017-01-28 17:44:43

[SOLVED]xorg.wrap blocked. Can't connect to xserver since xorg 1.19.1

#2 2017-01-28 18:11:54

Re: [SOLVED]xorg.wrap blocked. Can't connect to xserver since xorg 1.19.1

#3 2017-01-28 18:48:15

Re: [SOLVED]xorg.wrap blocked. Can't connect to xserver since xorg 1.19.1

#4 2017-01-28 21:46:22

Re: [SOLVED]xorg.wrap blocked. Can't connect to xserver since xorg 1.19.1

#5 2017-01-28 22:04:13

Re: [SOLVED]xorg.wrap blocked. Can't connect to xserver since xorg 1.19.1

#6 2017-01-28 22:13:33

Re: [SOLVED]xorg.wrap blocked. Can't connect to xserver since xorg 1.19.1

#7 2017-01-28 22:37:28

Re: [SOLVED]xorg.wrap blocked. Can't connect to xserver since xorg 1.19.1

#8 2017-01-29 00:51:47

Re: [SOLVED]xorg.wrap blocked. Can't connect to xserver since xorg 1.19.1

#9 2017-01-29 11:41:08

Re: [SOLVED]xorg.wrap blocked. Can't connect to xserver since xorg 1.19.1

#10 2017-01-29 13:45:59

Re: [SOLVED]xorg.wrap blocked. Can't connect to xserver since xorg 1.19.1

#11 2017-01-29 14:49:11

Re: [SOLVED]xorg.wrap blocked. Can't connect to xserver since xorg 1.19.1

#12 2017-01-29 15:08:13

Re: [SOLVED]xorg.wrap blocked. Can't connect to xserver since xorg 1.19.1

#13 2017-01-29 15:33:36

Re: [SOLVED]xorg.wrap blocked. Can't connect to xserver since xorg 1.19.1

#14 2017-01-29 15:35:51

Re: [SOLVED]xorg.wrap blocked. Can't connect to xserver since xorg 1.19.1

#15 2017-01-29 17:01:15

Re: [SOLVED]xorg.wrap blocked. Can't connect to xserver since xorg 1.19.1

Board footer