Re: revocation of /dev/console at the end of rc sequence

On Wed, Mar 26, 2025 at 12:58 PM Andriy Gapon <avg@freebsd.org> wrote:

> On 26/03/2025 6:54 pm, Warner Losh wrote:
> >
> >
> > On Wed, Mar 26, 2025 at 10:23 AM Andriy Gapon <avg@freebsd.org
> > <mailto:avg@freebsd.org>> wrote:
> >
> >
> >     Not sure what would be the best forum to talk about this issue, so
> posting here.
> >
> >     I observe a kind of unexpected problem related to /dev/console.
> >     Here is my understanding of what is happening.
> >
> >     Thanks to DTrace I was able to capture /dev/console getting
> "revoked", its
> >     vnode
> >     getting recycled (at least, destroyed):
> >
> >         1  15949                     vgonel:entry
> >     2025 Mar 25 21:45:33 vgone vnode fffff8000607b540, console rdev by
> sh (21)
> >
> >                     kernel`vgone+0x2f
> >                     kernel`devfs_revoke+0x41
> >                     kernel`VOP_REVOKE_APV+0x71
> >                     kernel`killjobc+0x15a
> >                     kernel`exit1+0x707
> >                     kernel`0xffffffff808bd00d
> >                     kernel`amd64_syscall+0x189
> >                     kernel`0xffffffff80c4fbfb
> >
> >     My understanding is that this is the rc shell process exiting.
> >
> >     init forks a process that exec-s bin/sh (or alternative init shell)
> to run
> >     /etc/rc (or alternative init script).
> >     The process sets up itself as a session leader and /dev/console as
> its
> >     controlling terminal (as well as stdin, stdout and stderr).
> >     It does that by calling login_tty() which internally uses setsid()
> and
> >     tcsetsid() to do the job.
> >     See runcom -> run_script -> execute_script -> open_console in
> sbin/init/init.c.
> >
> >     I guess that this makes total sense given the nature of /etc/rc.
> >
> >     When a session leader process exits, it revokes its controlling
> terminal.
> >     That's the standard behavior.
> >     I guess that the idea is that any descendant processes in the
> session get
> >     disassociated from the terminal.
> >
> >     Both things make sense, but they lead to a problem as well.
> >     The problem is that by the time /etc/rc finishes there can be a
> daemon (so, not
> >     a member of the session) that opened /dev/console for its own needs.
> >     The daemon would then lose its /dev/console access which it may not
> expect.
> >
> >     One such daemon is console-kit-daemon.
> >     Here is how /dev/console descriptor looks afterwards (as reported by
> >     procstat -f):
> >         PID COMM                FD T V FLAGS    REF  OFFSET PRO NAME
> >        3323 console-kit-daemon    10 v x r-------  10       0 -   -
> >
> >     More details here:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285394
> >     <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285394>
> >     (Note that some earlier comments have incorrect information and
> assumptions).
> >
> >     Can we do something better here given the special nature of
> /dev/console?
> >     May something in FreeSBD?
> >
> >     For console-kit-daemon I have an idea of using /dev/ttyv0 instead of
> >     /dev/console.  The daemon needs the device for things like observing
> VT
> >     switching and similar operations
> >
> >
> > So what is it using /dev/console for? I think the answer to this
> question will help
> > understand the right solution. What does console-kit think it can do
> with /dev/
> > console?
>
> I guess I should have expanded on "things like observing VT switching and
> similar operations".
> So, console-kit issues ioctl-s like VT_WAITACTIVE, VT_ACTIVATE and similar.
>
> I also would like to mention that those ioctl-s are not documented in the
> manual
> pages.  Perhaps, screen(4) would have been a good place for that.
>

vt(4) maybe? screen(4) doesn't look to be the right place since it's
describing
something else.


> I guess I could say that console-kit needs a control device for video
> console.
> It presently uses /dev/console for that role and it works but it may not
> be the
> best choice.
>

So it would be more fair to say you need a control device for the video
subsystem.
Video console is an overloaded term and only tangentially related to
/dev/console
which I don't think should have ever been used for this purpose and is
leading to
the confusion.


> I do not think that we have an explicitly designed control device for
> video
> consoles.  From the code I get an impression that any video console
> terminal
> (ttyvX) should be suitable for that role.  E.g., vidcontrol just uses
> whatever
> device happens to be its stdin.
> But maybe that's not so.
>

Yes. vidcontrol was designed more for interactive use than other use. You
proved
you could access it by passing things through stdin. Not a great design,
but one that
reflects what stty does. And one that was adequate enough in the early days
that it
didn't change when we went from syscons -> vt.

And you're right, there's no /dev/ttyv.ctl that can be used for this. Any
of the ttyvX
gives effective ownership to all tttyvX if I'm reading things right just
now.

> /dev/console, even if we didn't do the revoke, seems like the wrong thing
> for it
> > to be opening.
> >
> > Seems like
> >       TIOCCONS int *on
> >                   If on points to a non-zero integer, redirect kernel
> console
> >                   output (kernel printf's) to this terminal.  If on
> points to a
> >                   zero integer, redirect kernel console output back to
> the
> >                   normal console.  This is usually used on workstations
> to
> >                   redirect kernel messages to a particular window.
> > is what it should be doing.
> > Is the standard way to redirect / scrape the console.
>
> I guess that this not useful at all for console-kit.
>

Yea. I thought it did something else entirely...


> > Also, ttyv0 is always wrong to hard-code. It might have nothing at all
> > to do with the console.
>
> Given what console-kit actually does, it might not be so wrong.
> But I am not sure.
>

Yea. I'm coming around to this point of view, but I worry about keeping
ttyv0
open for people that actually login to ttyv0, though I guess in practice it
won't
be a big deal. It's likely the least wrong thing we have today.


> > There's a couple of different notions of "the console" today, and they
> > are a bit poorly defined. There's the "console" for the kernel. And it's
> really
> > a collection of devices that get kernel output and are prompted for
> kernel
> > input.
> >
> > There's the "console" used for /etc/rc. This is /dev/console. It's just
> an
> > alias for the first tty device in the kernel console list (sometimes
> called the
> > primary console). there's little special beyond that, though Kyle and I
> > keep threatening to make it a mux of all the kernel consoles on that
> list.
> > It's functionality is somewhat limited (and has been since phk separated
> > it out from the tty that underlies it around FreeBSD 2 or 3).
> >
> > So what is it that console-kit-daemon is wanting to do?
>
> So, just for the sake of quoting, console-kit-daemon needs a control
> device for
> video console (video terminals).
>

It's a control daemon for the video subsystem, which is unrelated to the
system
console except maybe it will be used as the system console. But
console-kit-daemon
doesn't care, if I understand, about the system console: it just wants to
control which
of the virtual terminals are current then? Is that a more precise way of
saying what it
does avoiding overloaded terms?

Warner