Michal Vasko

You do not understand, the instances will be completely separate. Example with 3 clients using repos `/etc/sysrepo1,2,3`: You run (also need to change the PID file path for more instances...

> Can we not have one instance of netopeer server and multiple instances of sysrepo ? In short, no. How should *netopeer2-server* know with which *sysrepo* instance to communicate? There...

Naturally, 2 processes cannot listen on a single port on one machine.

The reader limit will most likely be caused by some missing unlock because of invalid use of a session or something like that. I would need to see the source...

> Are there any rules that we can differentiate the trigger source? No and I do not understand why should it matter. You are simply supposed to provide the data...

Also, I believe in this case you should be getting a list of XPaths in the callback that should allow you to avoid collecting and returning most of the data.

The errors mean that you are not holding the read lock when you should. In this case it is the context lock so what could happen is that someone changes...

`ru-upgrade-success` is a `config false` leaf-list, which means it can have duplicate values so if you add it twice, there will be 2 instances. You can remove your previous changes...

My guess would rather be a deadlock caused by your code. What exactly is the architecture? What process/thread creates the first subscription?

What exactly are you doing in the callback for `sr_module_change_subscribe()`, are you calling some other subscribe function? If not, it may be an actual timeout, I have not noticed before...