[sysrepo-devel] Issues with sysrepo's persist file

[Jan Kundrát]

On středa 17. října 2018 16:48:28 CEST, Vladimir Georgiev wrote:
> Currently on our system "sysrepod" is disabled with "systemctl disable
> sysrepod" and is not started as daemon during boot. We did that because we
> experienced more often corruption of the persist file, when sysrepod is
> active. In taht case the persist file become corrupted on random basis and
> we did not catch reproducibility with exact steps. That was the reason
> first we to presume that it could be some conflict between library calls
> and sysrepod and to disable sysrepod.
>
> But corruption of the persist file continue to be present even after the
> deactivation of sysrepod. The difference is that now it is with
> reproducibility steps.

That sounds as if you now switched from a single systrepod instance managed 
by systemd to an approach where the sysrepo client library auto-starts a 
`sysrepod` process once it is first needed. That is not a correct path to 
take. In fact, I believe that this auto-starting should be disabled on the 
API level, or at least made explicit and to default to not fork the daemon 
in the background (see below for technical reasoning).

What I would try if I were you is the following:

- update to recent releases of the whole stack, including libyang, 
netopeer2-server, sysrepo, libnetconf2

- ensure that every user of sysrepod is managed by systemd, that it has a 
Requires=sysrepod.service and After=sysrepod.service stanzas in their 
respective .service/.unit files

- audit your code that you open all of your sysrepo client sessions with a 
flag SR_CONN_DAEMON_REQUIRED

That way you get determinism in the startup sequence, and you can be sure 
that no matter how badly the system behaves, the `sysrepod` process still 
runs with correct UID, ACLs, selinux labels (if applicable), Linux kernel 
namespace setup, sane environment, etc etc etc.

With kind regards,
Jan