Persistent VTY history?

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Wed Oct 10 14:33:23 UTC 2018


On Wed, Oct 10, 2018 at 01:09:17PM +0200, Neels Hofmeyr wrote:
> when a telnet vty closes, append all history to
> $history_path/$program_name.history
> ok, simple enough.
> 
> Yet it adds potentially large I/O to the server process, which would block
> until the history is written. That might be undesirable...

you cannot do a blocking write.  The "history save procedure" would not be different
and should be written via non-blocking file writes using the select() loop abstraction.

> Could also flush the history to file every time it reaches a given size to make
> sure of light I/O load.

I don't expect the history of a human user at the VTY session every to reach a size
where one would have to worry about that.  We're talking about kilobytes here.

> I sometimes invoke the vty with 'watch', or otherwise scripted, to keep showing
> the lchan summary, for example. That would produce a history entry for every
> single invocation, cause disk I/O and spam the history file. Do we need to
> enable history explicitly in each vty session? Or a a "no history" command per
> vty-session?

I would say explicit "no history"

> A client-side impl is much simpler from that angle. It just keeps so much cruft
> out of the server process, and "all we need" is a readline() that knows vty
> special characters.

ACK.  And we already have a [special] telnet client for nanoBTSs around on git.osmocom.org
in http://git.osmocom.org/libtelnet/

I would currently argue more in favor of a client based solution

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



More information about the OpenBSC mailing list