Try this one: show | compare rollback 1
Also this situation may rise in case when you change value(option), then in the same session revert this changed value to previous state. < This is my mention, not confirmed by the documentation.
First a quick note (even though it might not be terribly relevant for you) /var/rundb/private
and /var/run/db/private
are symlinked.
I digress, /var/run/db/private
is a directory used to manage configuration state for configure private
mode. You can delete the contents, but DO NOT delete the actual directory structure. Before doing so, I would double check that there is no one actively on the system trying to configure things in private mode.
These files should be deleted when a user exits configure private
for any reason (commit, disconnect, exit, etc.) I can't say for sure why the files are stuck there, it might just be that the device I'm looking at handles the deletion of those files better since it's newer, couldn't say for sure. But, to reiterate, yes you can delete the contents.
Here's a quick example, this is output from two concurrent CLI sessions to show how the files are propagated against the config session.
# Session 2 starts watching file list output
jhead@MX> file list /var/run/db/private/ | refresh 1
# Session 1 enters configure private
jhead@MX> configure private
Aug 23 07:29:15
warning: uncommitted changes will be discarded on exit
Entering configuration mode
# Session 2 file list output
/var/run/db/private/:
juniper-88600.conf.gz
juniper-88600.db
juniper-88600.save
---(refreshed at 2021-08-23 07:29:17 PDT)---
# Session 1 exits
[edit]
jhead@MX# exit
Aug 23 07:29:17
Exiting configuration mode
# Session 2 sees empty directory after exit
/var/run/db/private/:
---(refreshed at 2021-08-23 07:29:19 PDT)---
Best Answer
I'm not aware of an official way using the CLI/API, unless you want to populate a table of routing-engine part numbers and map those to CPU architecture.
Another method likely to work is run
uname -a
and match on ppc or amd64: