On 5/28/22 12:15 PM, Dallin Dahl wrote: > It turns out I had the same issue as Rio, since my login shell was still > controlling my terminal. If I run: > > exec s6-setsid X :3 vt3 > > while logged into tty3, I get an X display. However, I still can't > seem to get it to work with s6-svscan. If I exec into s6-svscan from > my login shell, svscan then controls the tty. If I exec into s6-setsid > s6-svscan, it still seems attached to the tty. I thought that maybe > using the tiocnotty ioctl call would free the tty for X to pick up, > so I wrote the following wrapper program: > > #include <fcntl.h> > #include <sys/ioctl.h> > #include <stdio.h> > #include <unistd.h> > > int main(int argc, char **argv) { > int tty = open("/dev/tty", O_RDONLY);
This doesn't close the TTY. I don't know if that makes a difference. > int res = ioctl(tty, TIOCNOTTY); > if(!~res) perror("tiocnotty"); > argv++; > execvp(*argv, argv); > return 0; > } > > and tried to exec into that before s6-svscan, both with and without > s6-setsid. Unfortunately, the process immediately exits. I don't think > it's my wrapper program, since I can run other programs with it without > problems, and they do indeed show up in the output of ps aux without a > controlling terminal. > > So I guess the new question is how can I free the tty after login, > allowing X to open it and control it? Have you tried redirecting all three standard fds elsewhere (/dev/null or a file) when running s6-svscan? Possibly either s6-svscan or s6-supervise is doing some fd manipulation that steals control of the TTY before X can get it. You could also try running s6-supervise directly to narrow this down. Regards, Samuel