ttymon (getty) on ttya, ttyb?

ttymon (getty) on ttya, ttyb?

[Gordon Ross]

Could someone please write up how to arrange for a getty to run on all of:
 wscons, ttya, ttyb (regardless of which is the "console").
I think SmartOS did that.  Maybe a pointer to that change is sufficient?
It would be nice to have the service instances defined (at least) even
if disabled by default.

Thanks!

Re: [developer] ttymon (getty) on ttya, ttyb?

[Joshua M. Clulow]

On Sat, 14 Jan 2023 at 19:18, Gordon Ross <gordon.w.ross@gmail.com> wrote:
> Could someone please write up how to arrange for a getty to run on all of:
>  wscons, ttya, ttyb (regardless of which is the "console").

This is not really something we have good out-of-the-box support for,
today.  It's architecturally somewhat complex because the system
console redirector, /dev/console, sits on top of the primary nominated
system console device (whichever that is).  The
svc:/system/console-login:default service instance is expected to use
that special redirection device and to always be online, or the system
goes into a maintenance state.  Opening the underlying device would at
best result in EBUSY and at worst result in two ttymons trying to
provide service on the same physical device.

Various other software is also sensitive to whether you're using
/dev/console or not; e.g., "mdb -K".

If you commit to a statically chosen console device, which I would
recommend to be whatever serial device is remotely accessible, then it
is a little easier.  You can create new instances of the
"svc:/system/console-login" service for the devices _other_ than the
system console; e.g., you might create
"svc:/system/console-login:wscons" for the framebuffer console.  You
can choose which ttydefs(5)/ttyadm(8) entry to use for serial
settings, what the prompt should be, etc, using the "ttymon" property
group in the instance you create.

> I think SmartOS did that.  Maybe a pointer to that change is sufficient?
> It would be nice to have the service instances defined (at least) even
> if disabled by default.

SmartOS certainly did make some changes to the default shipped service
instances and method scripts for the console-login services that have
not always been quite right.  For example, the "console-login:default"
instance is hard-wired to use the "/dev/wscons" device, which is
definitely not correct for a system that is using a serial device for
its console.  Not every system even _has_ a framebuffer console.

    # bootparams console | grep console
    console=ttyb
    # svcprop -p ttymon/device console-login:default
    /dev/wscons
    # svcprop -p ttymon/device console-login:ttyb
    /dev/term/b

We have a second mechanism for managing non-console serial port logins
as well: sac(8); see also sacadm(8), pmadm(8), etc.  This subsystem is
a bit of a relic and dates to an era where people were still more
commonly using some combination of dial-up and local serial terminals
on larger multi-user systems.

If you want the world you're describing, where we are able to
correctly and dynamically provide the right kind of login in the face
of an arbitrary console device chosen at boot, while still correctly
maintaining the parts of SMF that bring the system to a maintenance
state when the console login service is not working, I believe we
would need to provide a new facility.  Ideally it would be a new
daemon in a single service instance that could provide a more flexible
umbrella console (or ancilliary ttymon login) service correctly over a
set of serial or framebuffer (or paravirtualised) devices.


Cheers.

-- 
Joshua M. Clulow
http://blog.sysmgr.org