Date: Wed, 26 Mar 2025 14:52:59 -0600 From: Warner Losh <imp@bsdimp.com> To: Andriy Gapon <avg@freebsd.org> Cc: arch@freebsd.org Subject: Re: revocation of /dev/console at the end of rc sequence Message-ID: <CANCZdfqhuuqNc8_5jbUa24dHRQ4T_Ensgvmu-ojqVd0XHA%2Ba%2Bw@mail.gmail.com> In-Reply-To: <ba21c008-2b40-4992-b1a5-9d41a9a06390@freebsd.org> References: <a59cca2f-5826-427e-9276-2cff8541992f@FreeBSD.org> <CANCZdfrtxRsn5aod6K9okGBjoUg89-Rqz4bhVyHWWRpz9utRDg@mail.gmail.com> <ba21c008-2b40-4992-b1a5-9d41a9a06390@freebsd.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] 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 [-- Attachment #2 --] <div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Mar 26, 2025 at 12:58 PM Andriy Gapon <<a href="mailto:avg@freebsd.org">avg@freebsd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 26/03/2025 6:54 pm, Warner Losh wrote:<br> > <br> > <br> > On Wed, Mar 26, 2025 at 10:23 AM Andriy Gapon <<a href="mailto:avg@freebsd.org" target="_blank">avg@freebsd.org</a> <br> > <mailto:<a href="mailto:avg@freebsd.org" target="_blank">avg@freebsd.org</a>>> wrote:<br> > <br> > <br> > Not sure what would be the best forum to talk about this issue, so posting here.<br> > <br> > I observe a kind of unexpected problem related to /dev/console.<br> > Here is my understanding of what is happening.<br> > <br> > Thanks to DTrace I was able to capture /dev/console getting "revoked", its<br> > vnode<br> > getting recycled (at least, destroyed):<br> > <br> > 1 15949 vgonel:entry<br> > 2025 Mar 25 21:45:33 vgone vnode fffff8000607b540, console rdev by sh (21)<br> > <br> > kernel`vgone+0x2f<br> > kernel`devfs_revoke+0x41<br> > kernel`VOP_REVOKE_APV+0x71<br> > kernel`killjobc+0x15a<br> > kernel`exit1+0x707<br> > kernel`0xffffffff808bd00d<br> > kernel`amd64_syscall+0x189<br> > kernel`0xffffffff80c4fbfb<br> > <br> > My understanding is that this is the rc shell process exiting.<br> > <br> > init forks a process that exec-s bin/sh (or alternative init shell) to run<br> > /etc/rc (or alternative init script).<br> > The process sets up itself as a session leader and /dev/console as its<br> > controlling terminal (as well as stdin, stdout and stderr).<br> > It does that by calling login_tty() which internally uses setsid() and<br> > tcsetsid() to do the job.<br> > See runcom -> run_script -> execute_script -> open_console in sbin/init/init.c.<br> > <br> > I guess that this makes total sense given the nature of /etc/rc.<br> > <br> > When a session leader process exits, it revokes its controlling terminal.<br> > That's the standard behavior.<br> > I guess that the idea is that any descendant processes in the session get<br> > disassociated from the terminal.<br> > <br> > Both things make sense, but they lead to a problem as well.<br> > The problem is that by the time /etc/rc finishes there can be a daemon (so, not<br> > a member of the session) that opened /dev/console for its own needs.<br> > The daemon would then lose its /dev/console access which it may not expect.<br> > <br> > One such daemon is console-kit-daemon.<br> > Here is how /dev/console descriptor looks afterwards (as reported by<br> > procstat -f):<br> > PID COMM FD T V FLAGS REF OFFSET PRO NAME<br> > 3323 console-kit-daemon 10 v x r------- 10 0 - -<br> > <br> > More details here: <a href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285394" rel="noreferrer" target="_blank">https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285394</a><br>; > <<a href="https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285394" rel="noreferrer" target="_blank">https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285394</a>><br>; > (Note that some earlier comments have incorrect information and assumptions).<br> > <br> > Can we do something better here given the special nature of /dev/console?<br> > May something in FreeSBD?<br> > <br> > For console-kit-daemon I have an idea of using /dev/ttyv0 instead of<br> > /dev/console. The daemon needs the device for things like observing VT<br> > switching and similar operations<br> > <br> > <br> > So what is it using /dev/console for? I think the answer to this question will help<br> > understand the right solution. What does console-kit think it can do with /dev/ <br> > console?<br> <br> I guess I should have expanded on "things like observing VT switching and <br> similar operations".<br> So, console-kit issues ioctl-s like VT_WAITACTIVE, VT_ACTIVATE and similar.<br> <br> I also would like to mention that those ioctl-s are not documented in the manual <br> pages. Perhaps, screen(4) would have been a good place for that.<br></blockquote><div><br></div><div>vt(4) maybe? screen(4) doesn't look to be the right place since it's describing</div><div>something else.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I guess I could say that console-kit needs a control device for video console.<br> It presently uses /dev/console for that role and it works but it may not be the <br> best choice.<br></blockquote><div><br></div><div>So it would be more fair to say you need a control device for the video subsystem.</div><div>Video console is an overloaded term and only tangentially related to /dev/console</div><div>which I don't think should have ever been used for this purpose and is leading to</div><div>the confusion.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> I do not think that we have an explicitly designed control device for video <br> consoles. From the code I get an impression that any video console terminal <br> (ttyvX) should be suitable for that role. E.g., vidcontrol just uses whatever <br> device happens to be its stdin.<br> But maybe that's not so.<br></blockquote><div><br></div><div>Yes. vidcontrol was designed more for interactive use than other use. You proved</div><div>you could access it by passing things through stdin. Not a great design, but one that</div><div>reflects what stty does. And one that was adequate enough in the early days that it</div><div>didn't change when we went from syscons -> vt.</div><div><br></div><div>And you're right, there's no /dev/ttyv.ctl that can be used for this. Any of the ttyvX</div><div>gives effective ownership to all tttyvX if I'm reading things right just now. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> > /dev/console, even if we didn't do the revoke, seems like the wrong thing for it<br> > to be opening.<br> > <br> > Seems like<br> > TIOCCONS int *on<br> > If on points to a non-zero integer, redirect kernel console<br> > output (kernel printf's) to this terminal. If on points to a<br> > zero integer, redirect kernel console output back to the<br> > normal console. This is usually used on workstations to<br> > redirect kernel messages to a particular window.<br> > is what it should be doing.<br> > Is the standard way to redirect / scrape the console.<br> <br> I guess that this not useful at all for console-kit.<br></blockquote><div><br></div><div>Yea. I thought it did something else entirely...</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> > Also, ttyv0 is always wrong to hard-code. It might have nothing at all<br> > to do with the console.<br> <br> Given what console-kit actually does, it might not be so wrong.<br> But I am not sure.<br></blockquote><div><br></div><div>Yea. I'm coming around to this point of view, but I worry about keeping ttyv0</div><div>open for people that actually login to ttyv0, though I guess in practice it won't</div><div>be a big deal. It's likely the least wrong thing we have today.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> > There's a couple of different notions of "the console" today, and they<br> > are a bit poorly defined. There's the "console" for the kernel. And it's really<br> > a collection of devices that get kernel output and are prompted for kernel<br> > input.<br> > <br> > There's the "console" used for /etc/rc. This is /dev/console. It's just an<br> > alias for the first tty device in the kernel console list (sometimes called the<br> > primary console). there's little special beyond that, though Kyle and I<br> > keep threatening to make it a mux of all the kernel consoles on that list.<br> > It's functionality is somewhat limited (and has been since phk separated<br> > it out from the tty that underlies it around FreeBSD 2 or 3).<br> > <br> > So what is it that console-kit-daemon is wanting to do?<br> <br> So, just for the sake of quoting, console-kit-daemon needs a control device for <br> video console (video terminals).<br></blockquote><div><br></div><div>It's a control daemon for the video subsystem, which is unrelated to the system</div><div>console except maybe it will be used as the system console. But console-kit-daemon</div><div>doesn't care, if I understand, about the system console: it just wants to control which</div><div>of the virtual terminals are current then? Is that a more precise way of saying what it</div><div>does avoiding overloaded terms?</div><div><br></div><div>Warner</div></div></div>help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqhuuqNc8_5jbUa24dHRQ4T_Ensgvmu-ojqVd0XHA%2Ba%2Bw>