Re: Dual Consoles: Is there any way to have the output of startup scripts to go to both?

On Tue, Aug 16, 2022 at 12:25 PM Dan Mahoney <freebsd@gushi.org> wrote:
>
>
>
> On Aug 16, 2022, at 15:01, Kyle Evans <kevans@freebsd.org> wrote:
>
> On Tue, Aug 16, 2022 at 11:34 AM Dan Mahoney <freebsd@gushi.org> wrote:
>
>
> Hey there all,
>
> At the day job we have dell idrac machines that also do serial consoles (this is super convenient because you can get a serial console by ssh'ing to the idrac), instead of firing up a browser and a VPN (and, earlier, Java...eww).
>
> So naturally, in /boot/loader.conf we set console=comconsole,vidconsole.
>
> We get dmesg output out both consoles.  We ultimately wind up with a login prompt on both consoles, but the output of boot scripts only go to one, and if the system craps the bed and drops to single-user mode, one console just "hangs" and the other one gives you useful output.
>
> It feels pretty trivial to have /etc/rc detect this unique condition, and perhaps put *some* output out to the inactive console, even if it's not capable of letting you do something interactive like an fsck from both.  Just something that hints "hey, go check the other line, there's things happening over there".
>
> How hard would this be?
>
>
> I have some WIP that will scattershot console output to all configured
> consoles, but right now there's not really a way to configure userland
> output to go to non-primary consoles.
>
>
> Dmesg at least seems to already do this.
>
> It looks like the thing that handles sending output to the console is actually "init" per the line at the top of /etc/rc.  Init sends to /dev/console, I'm guessing, and /dev/console can be only one device.
>
> Making rc bit detect and bit-bang unused consoles feels like asking for problems.
>

Right, I don't like that idea, either. My WIP throws a new tty behind
/dev/console that replicates messages to all configured consoles, so
that all of these userland things that write to /dev/console will just
DTRT.

Thanks,

Kyle Evans