On 2016-04-03 03:59, Guillermo wrote:
> Apparently, on Linux and the BSDs, if 'fd' is an open file descriptor
> to a terminal device, ioctl(fd, TIOCSCTTY, ...) (two or three
> arguments) sets it as the controlling terminal [1][2]. I've seen calls
> like that in sysvinit, agetty from util-linux and open-controlling-tty
> from nosh.
Oh, yes, I know what the ioctl does. It is the way tcsetpgrp() is
implemented on Linux, and apparently on BSD too.
http://pubs.opengroup.org/onlinepubs/9699919799/functions/tcsetpgrp.html
What I meant was, I have no idea why the supervisor would do that. Again,
I suspect that it's a historical artefact due to init being monolithic and
lacking a chain-loading program such as open-controlling-tty.
> From what I understand from the code, sysvinit tries several devices
> in order: the contents of the CONSOLE environment variable,
> /dev/console, /dev/tty0 and finally /dev/null if everything else
> failed.
Opening /dev/null as a controlling terminal, what a brilliant idea!
It's almost as brilliant as reopening /dev/initctl every 5 seconds.
> But it looks like it sets the controlling terminal for the
> processes it is configured to wait for until they end, and only when
> booting the machine (actions 'sysinit' and 'bootwait') or in
> single-user runlevel (runlevel 's'). It doesn't for processes with a
> 'respawn' action in normal runlevels, for example. The relevant part
> should be inside the spawn() function in the init.c file [3]. I get
> lost easily trying to read that code, though :)
OK, I get it: it's so you can interrupt rc.sysinit via a ^C. It
follows the logic of "we're doing complex stuff, so we need to provide
users with a way to debug interactively". It's not pretty, but it
makes sense in that context.
The important thing is that "respawn" lines, i.e. the processes that
sysvinit supervises, don't get a controlling terminal. And that's the
right thing, since getty will obviously allocate one itself.
> For completeness, the unit file directives involved here are
> StandardInput, StandardOutput and StandardError:
>
> <https://www.freedesktop.org/software/systemd/man/systemd.exec.html>
AIUI, those directives are necessary because systemd doesn't use
chain loading, and so the unit file format has to plan for *everything*.
The directives are only used for services that need it, and coupled
with a TTYPath directive; the default is null, which is sensible.
With a supervision system, you'd achieve the same thing via chain loading
in the run script, with open-controlling-tty or s6-setsid.
> Maybe. Honoring the expected behaviour of a 'StandardInput=tty'
> directive does seem to require setting the device stdin is connected
> to as a controlling terminal, according to that documentation. But
> surprisingly the unit file-to-bundle directory converter
> (system-control convert-systemd-units) doesn't support
> 'StandardOutput=tty' and 'StandardError=tty' directives and ignores
> them.
It makes sense. A controlling terminal is only worth it if it allows
you to... control, i.e. if you can actually send control commands to
the process. And the only way to do that is if stdin is a terminal;
stdout and stderr are irrelevant to the control aspect.
So I wouldn't call it a limitation so much as a design decision. But
you should ask Jonathan to be 100% sure. :)
> Supposedly, if supported, 'StandardOutput=tty' appearing alone
> in the unit file would make the service output to a terminal while
> keeping stdin connected to /dev/null, and not set a controlling
> terminal. That's why I said that in nosh's case I wasn't sure if the
> whole controlling terminal thing is because of this limitation.
In nosh, as in any supervision suite, you'd achieve the same thing
via a simple redirection. Maybe allocating a terminal first if you
don't have one; I've never needed it so s6 doesn't provide a terminal
allocation primitive, but maybe nosh does.
> I was undecided about where to post it, but ultimately since I was
> presenting it as a question about s6-rc, I chose the skaware ML.
Sure. I don't think it matters much either way. It's just that there
are a lot more people on the supervision list, and that's where I tend
to post when addressing issues related to supervision in general,
because that may interest them. I
--
Laurent
Received on Sun Apr 03 2016 - 11:52:27 UTC