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
