be more careful when dumping sysrepo configuration
I've seen one lab device with a zero-size JSON file, which obviously
cannot be restored. That's fishy and this should not happen, so let's
try to be a bit more robust when creating that file:
- do not overwrite in place (which might hit a FS race and cause an
empty file)
- check that sysrepocfg produced "some data" (if it crashed early
enough, it would previously still have been an empty file due to the
output redirection)
The actual writeout is a bit more involved than I would prefer, and
because I want locking (thanks, Tomas), I think it's easier to use two
scripts for this one.
Change-Id: I43fccd3a49cae77f88b282ccac07471453910c25
diff --git a/package/czechlight-cfg-fs/sysrepo-persistent-cfg.service b/package/czechlight-cfg-fs/sysrepo-persistent-cfg.service
index 25991f4..0c961e5 100644
--- a/package/czechlight-cfg-fs/sysrepo-persistent-cfg.service
+++ b/package/czechlight-cfg-fs/sysrepo-persistent-cfg.service
@@ -6,6 +6,6 @@
[Service]
Type=simple
UMask=0077
-ExecStartPre=/bin/sh -c 'mkdir -p /cfg/sysrepo/ && sysrepocfg -d startup -f json -X > /cfg/sysrepo/startup.json'
-ExecStart=/bin/sh -c 'while true; do inotifywait -e CLOSE_WRITE /etc/sysrepo/data/*.startup && sysrepocfg -d startup -f json -X > /cfg/sysrepo/startup.json; done'
+ExecStartPre=/bin/sh -c 'mkdir -p /cfg/sysrepo/ && cfg-save-sysrepo'
+ExecStart=/bin/sh -c 'while true; do inotifywait -e CLOSE_WRITE /etc/sysrepo/data/*.startup && cfg-save-sysrepo; done'
Group=sysrepo