Closed gaborigloi closed 7 years ago
I have observed the exact same transient issues as above when I made the service path-activated by all these files:
[Path]
PathExists=/var/xapi/xapi
PathExists=/etc/xensource/xapi-ssl.pem
PathExists=/var/run/xapi_init_complete.cookie
Probably because these path conditions are ORed, not ANDed together.
Indeed, it seems that the path conditions are ORed together :( :
With this xapi-nbd.path
file, it started up without errors after reboot:
[Path]
PathExists=/var/run/xapi_init_complete.cookie
However, we cannot use this solution, because we need multiple paths to exist, we also need a path condition for the .pem
file, because that's created independently of xapi's startup sequence. And it's not safe to combine them, since they are ORed together. For some reason it worked, even when I removed the .pem
file and rebooted. However, I think it's not safe to assume that we have a management network & IP & have generated the .pem
file that xapi-nbd
needs by the time this file appears, because I've observed that these things happen a few seconds after xapi's startup sequence.
From https://github.com/xapi-project/xapi-nbd/pull/18 :
When I rebooted the machine, I got
ECONNREFUSED
, probably whenxapi-nbd
tried to connect to xapi's Unix domain socket:When I started it manually later, it worked, and it cleaned up the leaked VDIs properly. This issue happens consistently at startup: the NBD server will try to make XenAPI calls via the Unix domain socket and will fail.
Even if we make the server path-activated by both the unix domain socket of xapi and the
.pem
file, there are still transient errors:So it seems that xapi is not yet completely ready when its Unix domain socket is created (
Sep 28 21:42:46 localhost xapi-nbd[2778]: Server_error(INTERNAL_ERROR, [ missing table; host; ])
). So I'll just add a loop to the startup of xapi-nbd that will try logging in until it succeeds, up to a timeout, to ensure that xapi is up when we need it.