You are not logged in.
Is it reproducible?
Yes. Occurs on both my laptop (Intel + Nvidia GPU) and my PC (AMD GPU)
How to reproduce?
1. login as my normal user on tty2 (I run Xorg without root priviledges)
2. start xinit like this:
xinit /usr/bin/bspwm -- ~/.config/xorg/xserverrc :1 -nolisten tcp vt2
~/.config/xorg/xserverrc
#!/bin/zsh
exec Xorg $@
What happens on screen?
Xorg server starts and prints out the usual information until it just freezes. I can still see my terminal (vt2) and the output of the Xorg Server, but I can neither change to a different terminal via alt+ctrl+f[1-6], nor can I use Ctrl+C or other keybindings. But the Kernel seems to run, since the SysRq Keybindings still work.
What I was able to find out:
Everything works normal again (Xorg starts normal and I have my Desktop) if I just use bash or dash for my xserverrc like this:
~/.config/xorg/xserverrc
#!/bin/bash
exec Xorg $@
The problem does however occur, if I use the fish or zsh.
I did an strace of Xorg and found out that Xorg gets an SIGTTOU Signal from the Kernel while trying to change the terminal settings of /dev/tty2:
openat(AT_FDCWD, "/dev/vc/2", O_RDWR|O_NONBLOCK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/dev/tty2", O_RDWR|O_NONBLOCK) = 9
ioctl(9, VBG_IOCTL_VMMDEV_REQUEST_BIG or VT_GETSTATE, 0x7ffed9e780b2) = 0
ioctl(9, VT_ACTIVATE, 0x2) = 0
ioctl(9, VT_WAITACTIVE, 0x2) = 0
ioctl(9, VT_GETMODE, 0x7ffed9e780b8) = 0
rt_sigaction(SIGUSR1, {sa_handler=0x55d72beef4e0, sa_mask=[USR1], sa_flags=SA_RESTORER, sa_restorer=0x7fa111cbf960}, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7fa111cbf960}, 8) = 0
ioctl(9, VT_SETMODE, 0x7ffed9e780b8) = 0
ioctl(9, KDSETMODE, KD_GRAPHICS) = 0
ioctl(9, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(9, KDGKBMODE, [K_UNICODE]) = 0
ioctl(9, KDSKBMODE, K_OFF) = 0
ioctl(9, SNDCTL_TMR_START or TCSETS, {B0 -opost -isig -icanon -echo ...}) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGTTOU {si_signo=SIGTTOU, si_code=SI_KERNEL} ---
--- stopped by SIGTTOU ---
strace: Process 3064 detached
I did another strace but with bash instead of zsh for the shabang in xserverrc. Here it does not get the SIGTTOU from the kernel, while trying to change terminal settings of /dev/tty2.
openat(AT_FDCWD, "/dev/vc/2", O_RDWR|O_NONBLOCK) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/dev/tty2", O_RDWR|O_NONBLOCK) = 9
ioctl(9, VBG_IOCTL_VMMDEV_REQUEST_BIG or VT_GETSTATE, 0x7ffcc2b40df2) = 0
ioctl(9, VT_ACTIVATE, 0x2) = 0
ioctl(9, VT_WAITACTIVE, 0x2) = 0
ioctl(9, VT_GETMODE, 0x7ffcc2b40df8) = 0
rt_sigaction(SIGUSR1, {sa_handler=0x5647033ff4e0, sa_mask=[USR1], sa_flags=SA_RESTORER, sa_restorer=0x7efcc2138960}, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7efcc2138960}, 8) = 0
ioctl(9, VT_SETMODE, 0x7ffcc2b40df8) = 0
ioctl(9, KDSETMODE, KD_GRAPHICS) = 0
ioctl(9, TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(9, KDGKBMODE, [K_UNICODE]) = 0
ioctl(9, KDSKBMODE, K_OFF) = 0
ioctl(9, SNDCTL_TMR_START or TCSETS, {B0 -opost -isig -icanon -echo ...}) = 0
ioperm(0, 0x400, 1) = -1 EPERM (Operation not permitted)
...
I did a little research and found out that SIGTTOU gets signaled by the kernel, if one is not in the foreground process group and still tries to change the terminal settings of a terminal.
Now to my real Question. I can't find out the source of this problem. I know that bash and zsh are not compatible, but the only thing I did was exec a simple binary in my xserverrc. I just don't understand what these two shells do different here (Note: fish and zsh got this problem, but dash and bash works).
Hope someone can help me understand.
Last edited by CodingVoid (2021-12-09 15:10:14)
Offline
Welcome to the forums
Well, zsh has some quirks that make it non-quite a Bash replacement. Is there a reason you want to run xserverrc has a zsh script? You can (and probably should) configure your user to use zsh as your interactive shell, but still run system scripts in Bash (or sh, or csh, or whetever they were tested with). Just because you want to use zsh is your interactive shell, does not mean that scripts that have a crunch-bang on the first line need to be changed.
Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday
Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing
---
How to Ask Questions the Smart Way
Offline
I actually have no problem using /bin/bash for my shell scripts. I was just so puzzled that a simple shell script like this could lead to such differences between these shells. And I wanted to ask the community before I read through the source code of dash/zsh/bash/fish. My Question is just for educational purposes (I want to know why).
Edit:
I did some testing and looked through the source code of the dash and zsh.
It turns out that zsh actively changes the signal action of the Signals SIGTTOU, SIGTTIN, SIGSTP to the default value (which is stopping/suspending the process), if job control is off (which is the case for non interactive shells aka scripts).
If job control is on, zsh ignores these signals.
dash (and I guess bash too) do not change the actions of these signals, if job control is turned off.
If job control is on, dash ignores these signals just like zsh.
And the only reason that Xorg receives theses signals is because xinit creates a new process group for the Xorg Server (for whatever reason...) and therefore finds itself in a background process group.
Last edited by CodingVoid (2021-12-09 15:06:59)
Offline