Bug #6440
openVTY: 'write file' breaks 'show startup-config'
0%
Description
In my understanding, show startup-config is supposed to show the initial config file that was loaded during the process startup. However, saving the current configuration by doing write file [FILE] currently breaks show startup-config:
$ ./tests/vty/vty_transcript_test -c ./tests/vty/vty_transcript_test.cfg <0000> telnet_interface.c:88 Available via telnet 127.0.0.1 42042 $ telnet localhost 42042 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Welcome to the vty_transcript_test VTY interface vty_transcript_test> en vty_transcript_test# show startup-config line vty no login vty_transcript_test# write file /tmp/backup.cfg Configuration saved to /tmp/backup.cfg vty_transcript_test# show startup-config ! ! vty_transcript_test (1.9.0.195-f2ea) configuration saved from vty !! ! line vty no login !
It gets even worse if saving the configuration fails for whatever reason:
vty_transcript_test# write file /dev/null Can't open configuration file /dev/null.ul7SbU. vty_transcript_test# show startup-config vty_transcript_test#
Updated by fixeria 12 days ago
- Status changed from New to Feedback
Here is a simple patch fixing the problem for me:
https://gerrit.osmocom.org/c/libosmocore/+/36617 vty: fix 'write file FILE' breaking 'show startup-config' [NEW]
However, we still have more things to consider:
show startup-configsimply read()s the file (path stored inhost.config), doing fopen()/fclose()- so this actually reflects the current state of the config file, not the startup state
- any changes made to the config file after the startup will be shown
- this command will fail if the config file gets removed
- we could probably keep the file open (linux would keep a "frozen" copy for us)?
- in osmo-bsc.git, we have CTRL commands for loading config snippets
- AFAICS, those commands also change
host.configand thus breakshow startup-config
- AFAICS, those commands also change
Updated by neels 8 days ago
I didn't even know that 'show startup-config' existed. It would be fine with me to simply remove it.
same for me.
I often use 'show running-config', i.e. showing the VTY as modified by the
current VTY session. Even that is ambiguous, it is not necessarily showing the
config that is in actual running use, for items that require a service restart.
(How does 'show startup-config' even work, do we cache the full cfg file contents?)
