supervision - discussion about system services, daemon supervision, init, runlevel management, and tools such as s6 and runit
 help / color / mirror / Atom feed
From: Samuel Holland <>
To: Guillermo <>,
	Supervision <>
Subject: Re: s6 xinit replacement?
Date: Sat, 14 May 2022 21:44:43 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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:

> 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:

And X will try to do that at startup (after failing to play with process groups
because it is already group leader):

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].


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:

Hope that helps,

  parent reply	other threads:[~2022-05-15  2:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-11  3:36 dallinjdahl
2022-05-14  3:47 ` Guillermo
2022-05-14 23:45   ` dallinjdahl
2022-05-15  1:52     ` Laurent Bercot
2022-05-15 15:02       ` Guillermo
2022-05-17  4:10         ` Rio Liu
2022-05-15  2:44   ` Samuel Holland [this message]
2022-05-22 15:07     ` Guillermo
2022-05-22 16:33       ` Samuel Holland
2022-05-23 10:05       ` yianiris
2022-05-23 23:40         ` Guillermo
2022-05-27  2:04         ` Steve Litt
2022-05-28  4:07     ` Dallin Dahl
2022-05-28 17:15     ` Dallin Dahl
2022-05-28 19:43       ` Samuel Holland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).