> "der Mouse" <mouse@Rodents.Montreal.QC.CA> wrote:
>
> >>> And, very few have heads on them so dragging out a keyboard/monitor
> >>> just to preserve a dying (and REPLACEABLE!) resource seems too much
> >>> effort for me...
> >> Oh, heavens, I just use serial console for that stuff.
> > The damn "BREAK" detect makes this problematic for me.
> [...]
> > And, of course, the wonderful ambiguity of having to configure them
> > either to support a genuine console [...] ttys(5).
>
> Neither break-detect nor ttys(5) is relevant to using serial console to
> stop the machine's clock prior to mothballing it.

You missed the point.  I don't *use* serial consoles because THEY are
problematic (for these reasons).  So, turning off the oscillator in the
"clock chip"
means I have to drag out a device to act as a serial console *just* for
the purpose of shutting off the oscillator.

Assume that device is "very accessible", takes 0 time to boot, etc.
Perhaps I can have a serial console "up" in less than a minute?
And, perhaps type all the commands to shut down the oscillator in
another minute (they would be stenciled on the "console", of course,
for ease of memory)?  Then put the "console" away?  Aw, heck... let's
pretend I can do all of this (fetch, type, cleanup) in less than a minute...
So, if I do this 15 times in the next 10 years, I've broken even with the
time it takes me to add a battery onto a defective clock chip.

Well, I do it probably 4 or 5 times each *month*.  And I *know*
it would take far longer than 60 seconds "start to finish".  It takes
much longer than that just to dig the portable out of Mr. Whoopie's
closet... (No need for it to be very accessible since I only need
it when a system has *crashed*... not just to turn oscillators off!)

*And*, I have no fear about one of those times turning the SPARC
on and discovering that the inevitable has happened; the battery *has*
died and now I have to replace the chip *and* reprogram it.

>You're turning it
> off anyway, so you don't care if plugging it in drops into ddb or the

I *always* like to do a clean shutdown.  The possibility of
something in the filesystem crashing is not worth the time "saved"
by just yanking hte plug, etc.  If a machine is going to be off for
more than a few hours, there's no way I can remember *how*
I shut it down so best to always shut them down the same way.

> ROM monitor, and you aren't _booting_ it from serial console, so it
> doesn't matter what the OS thinks.

I want to be *able* to boot from a serial console for those times when
things misbehave.  E.g., power failure glitches something and the box
doesn't successfully get to multiuser mode (so none of the X Terminals
can be used to access it to see what is going on).

It would be nice if I could plug in a console (when it appears that this
has happened) and:
- not have that drop me to the ROM monitor (BREAK)
- have a login prompt waiting for me (ttys(5))
It would likewise be nice to be able to do this with a monitor/keyboard
without having ttya disappear.

Currently, I can use a serial console "safely" (i.e. without having to
consider how I connect/disconnect it to/from) on one box
with a "bag" attached to the back.  This is the machine that
I tend to have up most of the time, so I want to be able to
connect/disconnect without BREAKing.  And, the portable
that I use as the console device is smaller than a monitor/keyboard
so I have opted to configure ttys(5) to prefer a serial console
instead of the "real" console.

But, unless I build another "bag" for the other machines, this
solution (workaround) only works for that one machine.