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>
next in thread | previous in thread | raw e-mail | index | archive | help
--0000000000007c5a5d0631450680 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Mar 26, 2025 at 12:58=E2=80=AFPM Andriy Gapon <avg@freebsd.org> wro= te: > On 26/03/2025 6:54 pm, Warner Losh wrote: > > > > > > On Wed, Mar 26, 2025 at 10:23=E2=80=AFAM 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 b= y > > 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=3D285394 > > <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D285394>; > > (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 o= f > > /dev/console. The daemon needs the device for things like observin= g > 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 simila= r. > > 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 separate= d > > 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 --0000000000007c5a5d0631450680 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g= mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Mar 26,= 2025 at 12:58=E2=80=AFPM Andriy Gapon <<a href=3D"mailto:avg@freebsd.or= g">avg@freebsd.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote= " style=3D"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=E2=80=AFAM Andriy Gapon <<a href=3D"m= ailto:avg@freebsd.org" target=3D"_blank">avg@freebsd.org</a> <br> > <mailto:<a href=3D"mailto:avg@freebsd.org" target=3D"_blank">avg@fr= eebsd.org</a>>> wrote:<br> > <br> > <br> >=C2=A0 =C2=A0 =C2=A0Not sure what would be the best forum to talk about= this issue, so posting here.<br> > <br> >=C2=A0 =C2=A0 =C2=A0I observe a kind of unexpected problem related to /= dev/console.<br> >=C2=A0 =C2=A0 =C2=A0Here is my understanding of what is happening.<br> > <br> >=C2=A0 =C2=A0 =C2=A0Thanks to DTrace I was able to capture /dev/console= getting "revoked", its<br> >=C2=A0 =C2=A0 =C2=A0vnode<br> >=C2=A0 =C2=A0 =C2=A0getting recycled (at least, destroyed):<br> > <br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 15949=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0vgonel:entry<br> >=C2=A0 =C2=A0 =C2=A02025 Mar 25 21:45:33 vgone vnode fffff8000607b540, = console rdev by sh (21)<br> > <br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0kernel`vgone+0x2f<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0kernel`devfs_revoke+0x41<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0kernel`VOP_REVOKE_APV+0x71<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0kernel`killjobc+0x15a<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0kernel`exit1+0x707<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0kernel`0xffffffff808bd00d<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0kernel`amd64_syscall+0x189<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0kernel`0xffffffff80c4fbfb<br> > <br> >=C2=A0 =C2=A0 =C2=A0My understanding is that this is the rc shell proce= ss exiting.<br> > <br> >=C2=A0 =C2=A0 =C2=A0init forks a process that exec-s bin/sh (or alterna= tive init shell) to run<br> >=C2=A0 =C2=A0 =C2=A0/etc/rc (or alternative init script).<br> >=C2=A0 =C2=A0 =C2=A0The process sets up itself as a session leader and = /dev/console as its<br> >=C2=A0 =C2=A0 =C2=A0controlling terminal (as well as stdin, stdout and = stderr).<br> >=C2=A0 =C2=A0 =C2=A0It does that by calling login_tty() which internall= y uses setsid() and<br> >=C2=A0 =C2=A0 =C2=A0tcsetsid() to do the job.<br> >=C2=A0 =C2=A0 =C2=A0See runcom -> run_script -> execute_script -&= gt; open_console in sbin/init/init.c.<br> > <br> >=C2=A0 =C2=A0 =C2=A0I guess that this makes total sense given the natur= e of /etc/rc.<br> > <br> >=C2=A0 =C2=A0 =C2=A0When a session leader process exits, it revokes its= controlling terminal.<br> >=C2=A0 =C2=A0 =C2=A0That's the standard behavior.<br> >=C2=A0 =C2=A0 =C2=A0I guess that the idea is that any descendant proces= ses in the session get<br> >=C2=A0 =C2=A0 =C2=A0disassociated from the terminal.<br> > <br> >=C2=A0 =C2=A0 =C2=A0Both things make sense, but they lead to a problem = as well.<br> >=C2=A0 =C2=A0 =C2=A0The problem is that by the time /etc/rc finishes th= ere can be a daemon (so, not<br> >=C2=A0 =C2=A0 =C2=A0a member of the session) that opened /dev/console f= or its own needs.<br> >=C2=A0 =C2=A0 =C2=A0The daemon would then lose its /dev/console access = which it may not expect.<br> > <br> >=C2=A0 =C2=A0 =C2=A0One such daemon is console-kit-daemon.<br> >=C2=A0 =C2=A0 =C2=A0Here is how /dev/console descriptor looks afterward= s (as reported by<br> >=C2=A0 =C2=A0 =C2=A0procstat -f):<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0PID COMM=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 FD T V FLAGS=C2=A0 =C2=A0 REF=C2=A0 OFFSET PRO = NAME<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 3323 console-kit-daemon=C2=A0 =C2=A0 10 v x= r-------=C2=A0 10=C2=A0 =C2=A0 =C2=A0 =C2=A00 -=C2=A0 =C2=A0-<br> > <br> >=C2=A0 =C2=A0 =C2=A0More details here: <a href=3D"https://bugs.freebsd.= org/bugzilla/show_bug.cgi?id=3D285394" rel=3D"noreferrer" target=3D"_blank"= >https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D285394</a><br>; >=C2=A0 =C2=A0 =C2=A0<<a href=3D"https://bugs.freebsd.org/bugzilla/sh= ow_bug.cgi?id=3D285394" rel=3D"noreferrer" target=3D"_blank">https://bugs.f= reebsd.org/bugzilla/show_bug.cgi?id=3D285394</a>><br> >=C2=A0 =C2=A0 =C2=A0(Note that some earlier comments have incorrect inf= ormation and assumptions).<br> > <br> >=C2=A0 =C2=A0 =C2=A0Can we do something better here given the special n= ature of /dev/console?<br> >=C2=A0 =C2=A0 =C2=A0May something in FreeSBD?<br> > <br> >=C2=A0 =C2=A0 =C2=A0For console-kit-daemon I have an idea of using /dev= /ttyv0 instead of<br> >=C2=A0 =C2=A0 =C2=A0/dev/console.=C2=A0 The daemon needs the device for= things like observing VT<br> >=C2=A0 =C2=A0 =C2=A0switching and similar operations<br> > <br> > <br> > So what is it using /dev/console for? I think the answer to this quest= ion will help<br> > understand the right solution. What does console-kit think it can do w= ith /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 m= anual <br> pages.=C2=A0 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>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"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 conso= le.<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 t= o say you need a control device for the video subsystem.</div><div>Video co= nsole 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 purpos= e and is leading to</div><div>the confusion.</div><div>=C2=A0</div><blockqu= ote class=3D"gmail_quote" style=3D"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.=C2=A0 From the code I get an impression that any video console te= rminal <br> (ttyvX) should be suitable for that role.=C2=A0 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. vidco= ntrol 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 desi= gn, but one that</div><div>reflects what stty does. And one that was adequa= te enough in the early days that it</div><div>didn't change when we wen= t from syscons -> vt.</div><div><br></div><div>And you're right, the= re's no /dev/ttyv.ctl=C2=A0that can be used for this. Any of the ttyvX<= /div><div>gives effective ownership to all tttyvX=C2=A0if I'm reading t= hings right just now.=C2=A0</div><div><br></div><blockquote class=3D"gmail_= quote" style=3D"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 wron= g thing for it<br> > to be opening.<br> > <br> > Seems like<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0TIOCCONS int *on<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0If= on points to a non-zero integer, redirect kernel console<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ou= tput (kernel printf's) to this terminal.=C2=A0 If on points to a<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ze= ro integer, redirect kernel console output back to the<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0no= rmal console.=C2=A0 This is usually used on workstations to<br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0re= direct 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>= =C2=A0</div><blockquote class=3D"gmail_quote" style=3D"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>ope= n for people that actually login to ttyv0, though I guess in practice it wo= n't</div><div>be a big deal. It's likely the least wrong thing we h= ave today.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D= "margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le= ft:1ex"> > There's a couple of different notions of "the console" t= oday, 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 ke= rnel<br> > input.<br> > <br> > There's the "console" used for /etc/rc. This is /dev/con= sole. It's just an<br> > alias for the first tty device in the kernel console list (sometimes c= alled 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 l= ist.<br> > It's functionality is somewhat limited (and has been since phk sep= arated<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 syst= em</div><div>console except maybe it will be used as the system console. Bu= t 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 te= rminals 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> --0000000000007c5a5d0631450680--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqhuuqNc8_5jbUa24dHRQ4T_Ensgvmu-ojqVd0XHA%2Ba%2Bw>