I had the thought to start up all my personal services with s6, and it's going well. However, looking at the xinit source code, it appears to start the X server, wait until it's up, start a client program, wait until it shuts down, and then kill the X server. It seems to me that xinit is effectively performing process supervision on the X server and client program. I tried to run X under s6 with the following run file: ~~~ #!/usr/bin/execlineb backtick -E screen { pipeline { tty } sed s:/dev/tty:: } export DISPLAY :${screen} X :${screen} vt${screen} ~~~ Unfortunately, the server never starts up, although I can run those commands just fine from the tty. The last few lines of my Xorg log are the following: ~~~ (WW) xf86OpenConsole: VT_ACTIVATE failed: Operation not permitted (EE) Fatal server error: (EE) xf86OpenConsole: Switching VT failed (EE) (EE) Please consult the The X.Org Foundation support at http://wiki.x.org for help. (EE) Please also check the log file at (redacted) for additional information. (EE) (WW) xf86CloseConsole: KDSETMODE failed: Operation not permitted (WW) xf86CloseConsole: VT_SETMODE failed: Operation not permitted (EE) Server terminated with error (1). Closing log file. ~~~ Does anybody know anything about how s6-svscan and s6-supervise might change the environment so as to complicate running X? I've also checked to see if the tty got modified, but running the tty command under s6 from the tty console gives the same output as running it directly from the console. Thanks for your help! --Dallin
Hello,
El mié, 11 may 2022 a las 0:43, dallinjdahl escribió:
>
> I tried to run X under s6 with the following run file:
>
> ~~~
> #!/usr/bin/execlineb
> [...]
> X :${screen} vt${screen}
> ~~~
> [...]
> (WW) xf86OpenConsole: VT_ACTIVATE failed: Operation not permitted
> (EE)
> Fatal server error:
> (EE) xf86OpenConsole: Switching VT failed
> [...]
> Does anybody know anything about how s6-svscan and s6-supervise might
> change the environment so as to complicate running X?
If the Xorg process does not run as root, the tty specified in the vt
argument must be its controlling terminal. It works if you run X from
an interactive shell (perhaps indirectly through 'startx'), because it
inherits the shell's controlling terminal. It doesn't when run by
s6-supervise, because s6-supervise executes the 'run' file in a new
session, so there is no controlling terminal.
You can see Xorg fail in the same way if you do:
$ setsid startx
Using util-linux' setsid(1), or:
$ execlineb -Pc 'background { s6-setsid startx } exit'
G.
Hello,
Guillermo <gdiazhartusch@gmail.com> wrote:
> If the Xorg process does not run as root, the tty specified in the vt
> argument must be its controlling terminal. It works if you run X from
> an interactive shell (perhaps indirectly through 'startx'), because it
> inherits the shell's controlling terminal. It doesn't when run by
> s6-supervise, because s6-supervise executes the 'run' file in a new
> session, so there is no controlling terminal.
>
> You can see Xorg fail in the same way if you do:
>
> $ setsid startx
>
> Using util-linux' setsid(1), or:
>
> $ execlineb -Pc 'background { s6-setsid startx } exit'
>
> G.
Is the purpose of executing setsid() in s6-supervise to allow for the
services to continue beyond the termination of the supervision tree?
If that's the case, could there possibly be a flag to disable that,
with the understanding that something like nohup or even s6-setsid would
be necessary to replicate that behavior? That would enable a non-root
Xorg to be managed by s6.
I don't know if that has any other implications, other than the fact that
it would add a flag to s6-svscan, and maybe to s6-supervise? I don't
know if that cost is worth it, but I'm also not sure it warrants having
2 projects that duplicate the effort. Xinit seems to try to do what s6
does, but poorly.
Thanks!
--Dallin
>Is the purpose of executing setsid() in s6-supervise to allow for the >services to continue beyond the termination of the supervision tree? It's actually the opposite: it's to protect the supervision tree against misbehaved services. :) setsid() makes sure the service is isolated, and a killpg() or equivalent won't affect anything outside of it. Of course, it also protects *other* services running under the same supervision tree. >If that's the case, could there possibly be a flag to disable that, >with the understanding that something like nohup or even s6-setsid would >be necessary to replicate that behavior? That would enable a non-root >Xorg to be managed by s6. The direction s6 has taken is really the opposite: there was such a flag in earlier versions, but it was causing a lot of special cases and problems I definitely did not want to deal with. The real issue is that a supervision tree should not be run with a controlling terminal. It's not meant to be run from a logged-in user process, but as a background infrastructure that's always there. The whole point of s6 is to make your services *more reliable*; and there are few things less reliable than a whole tree of processes that can die on an accidental ^C. Because users insisted a lot, there are still accommodations for killing a whole supervision tree with ^C when s6-svscan has been launched in a terminal. It is a nice feature to have (and although it was by design that services persisted beyond the ^C, it was unintuitive to most users, so from a pure UI standpoint, killing the entire tree in one go was better). However, I'm not going back on the "each service runs in its own session" thing, because if there's a case for allowing the user who controls s6-svscan to kill the whole tree at once, there is just no case for allowing a service running under the tree to impact other services and the tree itself. Despite this, you're right that the pattern of xinit is similar to what s6 does, and it *is* possible to run Xorg under s6; several users are doing so, and I hope they will post their setup. (You may have more luck by asking in the IRC channel, but it would be nice for the setup to be documented on the mailing-list.) It does not involve running s6-svscan from your own VT; it involves having a supervision tree already running (as your user), and starting the Xorg service, e.g. with a s6-svc -u command, on a given VT, possibly passed to the run script via a file that your xinit emulation script would fill in with the output of `tty`. If you insist on doing hacky things, you could even probably get away with something that looks like: xinit emulation: #!/bin/sh tty | sed s:/dev/tty:: > /home/me/.screen-number s6-supervise /home/me/Xorg & # small race here that disappears when s6-supervise has already run once s6-svwait -U /home/me/Xorg your-X-client s6-svc -dx /home/me/Xorg /home/me/Xorg/notification-fd: 3 /home/me/Xorg/run: #!/bin/execlineb -P backtick -E screen { cat /home/me/.screen-number } export DISPLAY :$screen X -displayfd 3 :$screen vt$screen -displayfd is used as a notification mechanism, unblocking s6-svwait when the X server is ready. Hope this helps (and I hope users who actually have done something similar will share their experience), -- Laurent
On 5/13/22 10:47 PM, Guillermo wrote: > Hello, > > El mié, 11 may 2022 a las 0:43, dallinjdahl escribió: >> >> I tried to run X under s6 with the following run file: >> >> ~~~ >> #!/usr/bin/execlineb >> [...] >> X :${screen} vt${screen} >> ~~~ >> [...] >> (WW) xf86OpenConsole: VT_ACTIVATE failed: Operation not permitted >> (EE) >> Fatal server error: >> (EE) xf86OpenConsole: Switching VT failed >> [...] >> Does anybody know anything about how s6-svscan and s6-supervise might >> change the environment so as to complicate running X? > > If the Xorg process does not run as root, the tty specified in the vt > argument must be its controlling terminal. Yes, this is effectively the requirement. You can override it with a capability, but doing so is not necessary (see below). Here is the relevant kernel source for reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/tty/vt/vt_ioctl.c?h=v5.17#n744 > It works if you run X from > an interactive shell (perhaps indirectly through 'startx'), because it > inherits the shell's controlling terminal. It doesn't when run by > s6-supervise, because s6-supervise executes the 'run' file in a new > session, so there is no controlling terminal. It also works if X has permission to open the tty device read/write. Opening a tty as a session leader without a controlling terminal will set the controlling terminal to that tty. Relevant kernel code: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/tty/tty_jobctrl.c?h=v5.17#n129 And X will try to do that at startup (after failing to play with process groups because it is already group leader): https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xfree86/os-support/linux/lnx_init.c#L207 I use a udev rule to set the tty owner: $ cat /etc/udev/rules.d/99-tty.rules SUBSYSTEM=="tty", KERNEL=="tty1", OWNER="samuel", GROUP="samuel", MODE="0600" And everything Just Works. I am fine with hard coding the tty number because my systems are single-user. X is started at boot from my user supervision tree[1], which is started by the user-* services in my system supervision tree[2]. [1]: https://github.com/smaeul/rc-user [2]: https://github.com/smaeul/rc You could also set the tty permissions at login. Another option is to avoid the privileged IOCTLs by using the "-novtswitch" or "-sharevts" option. These set flags which affect the logic in the other file: https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xfree86/common/xf86Init.c#L1168 Hope that helps, Samuel
El sáb, 14 may 2022 a las 22:52, Laurent Bercot escribió:
>
> [...] it *is* possible to run Xorg under s6; several users are
> doing so, and I hope they will post their setup.
I actually don't run Xorg as a supervised process. I don't know what
systemd-based GNU/Linux distributions do, but on Gentoo with OpenRC,
Xorg is not started by the init system, it is started either by xinit,
or by a display manager, so I kept it that way.
When using startx from an interactive shell:
PID TT EUSER COMMAND
1 ? root s6-svscan -X3 -- /run/service
107 ? root s6-supervise agetty@tty1
515 tty1 root \_ /bin/login --
560 tty1 guiller+ \_ -bash
567 tty1 guiller+ \_ /bin/sh /usr/bin/startx
584 tty1 guiller+ \_ xinit /etc/X11/xinit/xinitrc
-- /etc/X11/xinit/xserverrc :0 -auth ...
585 tty1 guiller+ \_ /usr/bin/X ...
589 tty1 guiller+ \_ /bin/sh /etc/X11/Sessions/openbox
650 tty1 guiller+ \_ /usr/bin/openbox --startup ...
When using a display manager (SDDM here):
PID TT EUSER COMMAND
1 ? root s6-svscan -X3 -- /run/service
106 ? root s6-supervise sddm-daemon
702 ? root \_ sddm
704 tty7 root \_ /usr/bin/X ...
718 ? root \_ /usr/libexec/sddm-helper --socket ...
--start /usr/bin/openbox-session ...
719 ? guiller+ \_ /usr/bin/openbox --startup ...
So only the getty process and the display manager process are
supervised. I'm not sure if supervising Xorg is worth it. Say that
there is a transient event that makes Xorg crash. X11 clients would
likely die because they lost the connection to the X server, and then
xinit would exit, so the screen would just display a shell prompt
again, or the display manager would just spawn the greeter again, so a
graphical login screen would be displayed. If one is running Xorg, it
is likely because one is running a GUI, right? And if one is running a
GUI, it's probably because one is sitting right in front of the
computer, and one would notice the shell prompt / greeter screen, and
just type ''startx' / log in again. I mean, having a GUI on e.g. a
headless server does not seem very useful.
So I'd also be interested in what others think. (Maybe I should get
into this IRC thing :) , and I think I'll reply to Samuel's post
later).
G.
This thread has inspired me to move my desktop setup under s6 this weekend. Here's what I got: General flow: boot to tty1 -> login -> bash starts bashrc -> bashrc sets DISPLAY and TTY env vars then exec into s6-svscan -> s6-svscan starts xserver, window manager, and other desktop services. Reading Samuel's reply, I find the easiest way to get around the controlling terminal issue is to give Xorg capability: `setcap cap_sys_tty_config=+eip /usr/lib/Xorg`. (Considering Chromium has cap_sys_admin, letting Xorg control ttys doesn't seem that bad). Setting the owner of tty doesn't quite work in my case because of the login shell is attached to tty1 already. In my bashrc, I have some logic to check whether X should be started. Eventually, it runs this code: exec execlineb /dev/stdin << EOF s6-setsid -q piperw 4 3 background { fdclose 3 fdmove 0 4 foreground { redirfd -w 1 /dev/null cat } foreground { s6-rc-init -l "$S6/live" -c "$S6/compiled" "$S6/service" } s6-rc -l "$S6/live" -up change "$1" } fdclose 4 s6-svscan -d 3 "$S6/service" EOF And I have $HOME/.service/xserver-srv/run that replaces startx/sx: #!/usr/bin/execlineb -P fdmove -c 2 1 importas DISPLAY DISPLAY importas TTY TTY if { test -r /dev/dri/card0 } if { test -n "${DISPLAY}" } backtick -E cookie { xxd -l 16 -ps /dev/urandom } foreground { xauth add "${DISPLAY}" MIT-MAGIC-COOKIE-1 "${cookie}" } Xorg "${DISPLAY}" -displayfd 3 "vt${TTY}" With a finish file: #!/usr/bin/execlineb -P if { test -n "$DISPLAY" } xauth remove "$DISPLAY" The window manager, pulseaudio server, and a few other services are started together as well, using s6-rc to depend on xserver. This is what I ended up with: s6-supervise agetty-tty1 \_ login -- rio \_ s6-svscan -d 3 /tmp/rio/s6/1/service \_ s6-supervise xss-lock | \_ xss-lock -- s6-svc -1 /run/service/locker \_ s6-supervise xserver-srv | \_ /usr/lib/Xorg :1 -displayfd 3 vt1 \_ s6-supervise xserver-log | \_ s6-log -- n4 T /tmp/rio/s6/1/log/xserver \_ s6-supervise xbanish | \_ xbanish -i mod1 -i mod4 -i control \_ s6-supervise syndaemon | \_ syndaemon -tki 0.2 \_ s6-supervise pulseaudio-srv | \_ pulseaudio --exit-idle-time=-1 --daemonize=no | \_ /usr/lib/pulse/gsettings-helper \_ s6-supervise pulseaudio-log | \_ s6-log -- -system_bus_socket T /tmp/rio/s6/1/log/pulseaudio \_ s6-supervise gcin | \_ gcin \_ s6-supervise awesome | \_ awesome --no-argb \_ s6-supervise s6rc-fdholder | \_ s6-fdholderd -1 -i data/rules \_ s6-supervise s6rc-oneshot-runner Now there are probably issues here and there, as I just got it running. Suggestions welcome. Rio
Hello, Samuel.
El sáb, 14 may 2022 a las 23:44, Samuel Holland escribió:
>
> X is started at boot from my user supervision tree[1], which is started by the
> user-* services in my system supervision tree[2].
>
> [1]: https://github.com/smaeul/rc-user
> [2]: https://github.com/smaeul/rc
I had a look at your s6-rc service definitions, and it seems that you
don't have one for the system-wide message bus (D-Bus) and elogind.
That, in addition to having the tmpfs whose path is stored in
XDG_RUNTIME_DIR mounted by a "user-setup@<your user>" system service,
makes me think that you are not running those. On the other hand, IIUC
the Xorg process is part of a supervision tree that runs with your
(unprivileged) user and is launched by service "user-services@<your
user>", and I suppose that Xorg is not a suid binary, so unless you do
something else, your Xorg*.log file should contain something like:
(EE) systemd-logind: failed to get session: PID <Xorg's PID> does not
belong to any known session
...
(EE) open /dev/dri/card0: Permission denied
...
(EE) Screen(s) found, but none have a usable configuration.
So, what did you do? Did you also grant your user privileges for
opening the /dev/dri/card* character special files?
Thanks,
G.
On 5/22/22 10:07 AM, Guillermo wrote: > Hello, Samuel. > > El sáb, 14 may 2022 a las 23:44, Samuel Holland escribió: >> >> X is started at boot from my user supervision tree[1], which is started by the >> user-* services in my system supervision tree[2]. >> >> [1]: https://github.com/smaeul/rc-user >> [2]: https://github.com/smaeul/rc > > I had a look at your s6-rc service definitions, and it seems that you > don't have one for the system-wide message bus (D-Bus) and elogind. > That, in addition to having the tmpfs whose path is stored in > XDG_RUNTIME_DIR mounted by a "user-setup@<your user>" system service, > makes me think that you are not running those. On the other hand, IIUC > the Xorg process is part of a supervision tree that runs with your > (unprivileged) user and is launched by service "user-services@<your > user>", and I suppose that Xorg is not a suid binary, so unless you do Yes, all of those inferences are correct. > something else, your Xorg*.log file should contain something like: > > (EE) systemd-logind: failed to get session: PID <Xorg's PID> does not > belong to any known session > ... > (EE) open /dev/dri/card0: Permission denied > ... > (EE) Screen(s) found, but none have a usable configuration. > > So, what did you do? Did you also grant your user privileges for > opening the /dev/dri/card* character special files? Yes, I do that the "old-fashioned" way, by adding my user to the `video` group. There's a rule shipped by default with udev that changes the group of the DRM devices: SUBSYSTEM=="drm", KERNEL!="renderD*", GROUP="video" For multi-user systems, I would probably use something like seatd: https://git.sr.ht/~kennylevinsen/seatd Regards, Samuel
reply Guillermo: > Hello, Samuel. > > I had a look at your s6-rc service definitions, and it seems that you > don't have one for the system-wide message bus (D-Bus) and elogind. > That, in addition to having the tmpfs whose path is stored in > XDG_RUNTIME_DIR mounted by a "user-setup@<your user>" system service, > makes me think that you are not running those. Unbelievable, on this particular list, someone suggesting that dbus or systemd (elogind is the most invasive of all parts of systemd) is needed to run X, or wayland for that matter. > On the other hand, IIUC > the Xorg process is part of a supervision tree that runs with your > (unprivileged) user and is launched by service "user-services@<your > user>", and I suppose that Xorg is not a suid binary, so unless you do > something else, your Xorg*.log file should contain something like: If you have compiled X to require those, then it is your fault, and yes such trashy messaging should be recorded somewhere, maybe by journald. I apologize for the harshness of my reaction, but for years I've run (and thousands of others) without a trace of logind or dbus. My system is loosely based on Arch-testing (bleeding edge from 20000 upstream sources) and I have done the same in void as well. This implication that to run X,Y,Z logind/dbus is needed is dangerous and confusing as IBM propaganda, and we NEED to extinguish propaganda because we are where we are due to power of misinformation by the evil BlueChip. Just because it is easy and convenient for some distro developers to adopt the blackmail methods of IBM, this doesn't mean it is necessary. Having no direct evidence I could speculate that those the lead the decisions to adopt them have financial interests, but I can not speculate that far. You can, I can't. xorg 21.1.3 xorg-xinit 1.4.1 xorg-xwayland 22.1.1-1 wayland 1.20.0 s6 2.11.1.0 66 0.6.2.0 no logind no dbus 0 logind/dbus warning/error messages. Again, sorry Guillermo, this is not personal, it is "political".
Hello, yianiris / fungal-net El lun, 23 may 2022 a las 7:07, yianiris escribió: > > Unbelievable, on this particular list, someone suggesting that dbus or > systemd (elogind is the most invasive of all parts of systemd) is needed > to run X [...] Oh, I'm not suggesting it, I am stating it as a fact :) OK, now more seriously. This has come up some time ago in the Gentoo Forums when Gentoo's 'suid' USE flag changed to unset by default; the correct (although somewhat simplified for brevity) way to state that assertion is: the only *officialy supported* way to *not* run Xorg as root is by having it get open file descriptors from a "logind provider" (a process that implements the D-Bus org.freedesktop.login1 interface) using file descriptor passing, for /dev special files that would otherwise require a privileged open() call. Why? Because that is how Xorg is currently programmed. Technical details in this old version of a Gentoo Wiki article, if you are interested: * https://wiki.gentoo.org/index.php?title=Non_root_Xorg&oldid=884856#Supported_setups Personally, I don't mind D-Bus and elogind that much, because they combine well with an s6-based init system: PID COMMAND 1 s6-svscan -X3 -- /run/service 106 s6-supervise dbus-daemon 438 \_ dbus-daemon --system --nofork --nopidfile 480 elogind-daemon $ s6-rc-db type dbus-daemon longrun That said, I know that there are people who do not like D-Bus and / or elogind, and don't want them installed. That's OK, it's their choice. > no logind no dbus 0 logind/dbus warning/error messages. I hope you read the "I suppose that Xorg is not a suid binary" and "unless you do something else" parts of my previous e-mail. Setups without a suid Xorg binary, without D-Bus, and without a logind provider, need to work around the privileged open() situation: * AFAICT, Void and Obarun build Xorg with '-Dsuid_wrapper=true', so they install the Xorg suid wrapper, and configure it to never drop privileges by default. <https://github.com/void-linux/void-packages/blob/master/srcpkgs/xorg-server/template> <https://github.com/void-linux/void-packages/blob/master/srcpkgs/xorg-server/files/Xwrapper.config> <https://framagit.org/pkg/obextra/xorg-server/-/blob/master/trunk/PKGBUILD> <https://framagit.org/pkg/obextra/xorg-server/-/blob/master/trunk/Xwrapper.config> * Samuel adds his user to a group that allows processes to perform the required privileged open() calls. (What Rio's setup does with respect to /dev/dri/card* files has not been specified). All of these require some form of elevated privileges, including effectively running Xorg as root even if its binary might not be suid (its helper, Xorg.wrap, is). If your setup works in a way that does not involve elevated privileges, to be honest, I'd rather read about *that* instead of yet another systemd / RedHat / IBM rant. > Again, sorry Guillermo, this is not personal [...] No worries, no offense taken. G.
yianiris said on Mon, 23 May 2022 13:05:51 +0300 >Unbelievable, on this particular list, someone suggesting that dbus or >systemd (elogind is the most invasive of all parts of systemd) is >needed to run X, or wayland for that matter. [snip] >If you have compiled X to require those, then it is your fault, and yes >such trashy messaging should be recorded somewhere, maybe by journald. > >I apologize for the harshness of my reaction, Compiling X isn't like compiling fetchmail: It's a real slog. Compiling the right X version to fit with your existing stuff takes some trial and error. Having to recognize every time your distro updates X and recompile is a time sink, even if you have a shellscript do the whole thing. > >Again, sorry Guillermo, this is not personal, it is "political". Suggestion: Next time lead off with the preceding sentence. I think we all have a pretty good idea of motivations surrounding systemd, and those motivations are every bit as ugly as those of proprietary software. If it had been framed as "this sucks, but you need to compile X yourself to get out of this mess", I think it would have been more effective. And I'd like to congratulate you for running a dbus-less system. I know it's not easy --- I only succeeded in doing it once ( http://troubleshooters.com/linux/init/manjaro_experiments.htm#12232014_pure_runit_init_proof_of_concept ). If you're the type of person who likes giving presentations, it would be wonderful if you could present at one of our monthly GoLUG online Jitsi meetings. SteveT Steve Litt March 2022 featured book: Making Mental Models: Advanced Edition http://www.troubleshooters.com/mmm
Samuel Holland <samuel@sholland.org> wrote:
> It also works if X has permission to open the tty device read/write. Opening a
> tty as a session leader without a controlling terminal will set the controlling
> terminal to that tty. Relevant kernel code:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/tty/tty_jobctrl.c?h=v5.17#n129
>
> And X will try to do that at startup (after failing to play with process groups
> because it is already group leader):
>
> https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/hw/xfree86/os-support/linux/lnx_init.c#L207
>
> I use a udev rule to set the tty owner:
>
> $ cat /etc/udev/rules.d/99-tty.rules
> SUBSYSTEM=="tty", KERNEL=="tty1", OWNER="samuel", GROUP="samuel", MODE="0600"
>
> And everything Just Works.
I currently have my tty owned by me whenever I login, with the group
set to tty. The permissions are 600, so I would expect it to work
as long as I run X as my user, right? Unfortunately, I tried:
s6-setsid X :3 vt3
(on tty3), and had the same issue. It's still trying to switch the vt.
Would I have to switch the group as well? It seems that wouldn't
grant any additional privileges, especially since I am in the same
(supplementary) group as the tty?
It seems like a good option, I'm just unsure why it's not working?
Thanks!
--Dallin
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); 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? Thanks so much for your help! --Dallin
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