[sysrepo-devel] ?==?utf-8?q? Issues with sysrepo's persist file

Michal Vaško mvasko at cesnet.cz
Wed Oct 17 14:09:05 UTC 2018


Hi Vladimir, 

On Wednesday, October 17, 2018 10:37 CEST, Vladimir Georgiev <vladimir.georgiev at telco.com> wrote: 
 
> Hi,
> I am writing to you, because we have problem using sysrepo.
> We are trying to use sysrepo as a database for machine configuration.
> We wrote several subscribers on Python that are services, started via
> systemd. During their start they subscribe itself to sysrepo.
> When all services/subscribers are subscribed and when there are some
> changes in sysrepo, all corresponding subscribers are called, as expected
> to be.
> 
> The problem become visible on the next restart. The subscribers are unable
> to subscribe itself. Every request for subscribing raise exception
> "Sysrepo-internal error"
> After some investigations we saw that the persist file (in
> /etc/sysrepo/data) that is for corresponding root yang file, where is
> stored data of subscribers, socket, priority and etc. is broken (It is
> filled partially).
> It become in broken state during restart. The only fix, that we found for
> the situation, is removal of that file. But that is untill next changes in
> sysrepo and calling of subscribers, so after restart.

We have not experienced anything like you described. My first advice is to update sysrepo and libyang to most up-to-date versions, it would be difficult to help you further without that. Now, what do you mean by restart, you simply terminate sysrepod and execute it again? You checked the persist file right after sysrepod restarted and it was corrupted? Was it already corrupted after sysrepod was terminated?

> I presume that the problem could be connected with simultaneous starting of
> services that lead to simultaneous subscribing requests/calls.

Perhaps, but each of these persist files should be file-system-locked for this not to be an issue.

> Another thing is that the persist file is created with permissions 644 (all
> others persist files are 666), on the same time in sysrepo corresponding
> yang file is imported with permissions 666 (I do not know is there is a
> connection between both, but I do that remark, just in case)

That is definitely suspicious and you should try to find out how is this file created if you can. sysrepoctl should set 0666 permissions on all the files it creates.

I am not able to help you more, maybe someone else from sysrepo members can? Maybe the python bindings are to blame?

Regards,
Michal


More information about the sysrepo-devel mailing list