[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [XEN PATCH] tools/xenstore: Log xenstored build ID on startup
On 13.11.20 18:23, Edwin Torok wrote: CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. On Fri, 2020-11-13 at 17:13 +0000, Andrew Cooper wrote:On 13/11/2020 16:56, Bjoern Doebel wrote:On 13.11.20 16:36, Jürgen Groß wrote:On 13.11.20 15:18, Bjoern Doebel wrote:Right now we do not have a mechanism to determine the version of the currently running xenstored at runtime. As xenstored runs throughout the lifetime of a Xen host, this may lead to problems when newer user space builds are staged. Then, the running xenstored will no longer match the version of the installed xenstored. To allow users to always identify the running version of xenstored, add a linker-generated unique build ID to every xenstored build. Add functionality to log this build ID into a file upon service startup. Signed-off-by: Bjoern Doebel <doebel@xxxxxxxxx> Reviewed-by: Martin Mazein <amazein@xxxxxxxxx> Reviewed-by: Paul Durrant <pdurrant@xxxxxxxxxxxx>No support for oxenstored or xenstore-stubdom?Your suggestion further down will apparently help for stubdom. I do not speak ocaml at all - how do we address this?CC'ing Edwin and Christian who have done the bulk of the oxenstored recently. It sounds like it might not be possible right now, but would be possible with a future plan to switch the Ocaml build system over to dune (the new/preferred Ocaml upstream toolchain).See here what is possible with Dune: https://dune.readthedocs.io/en/stable/dune-libs.html#build-info Would the output of 'git describe --always --dirty' (perhaps combined with a build date) serve as a useful build ID? The point of the build ID is to verify something like "binary-equivalence" of two builds. * a git hash is not sufficient because different git hashes may result in the same binary to be created (i.e., if there is no code change in the target binary in between those two builds) * a time stamp is counter-productive, because then you'd have to recreate this timestamp every time you want to re-create a build GNU ld's --build-id claims to perform a checksumming of the "normative parts of the output contents". Whatever that means. ;) If it does end up being an XS_CONTROL sub-op, we can implement it at a future point when we can usefully answer the question.Wouldn't using readelf on /proc/<pid>/exe give you the running buildid? readelf -a /usr/sbin/oxenstored /proc/$(pidof oxenstored)/exe | grep 'Build ID' Build ID: bdd5304c8984ed22570d51308ae8717d03fe60ae Build ID: bdd5304c8984ed22570d51308ae8717d03fe60ae readelf -a /usr/sbin/oxenstored /proc/$(pidof oxenstored)/exe | grep 'Build ID' Build ID: b44ff99b216db7526e3ee7841068d584cc9c2b95 Build ID: bdd5304c8984ed22570d51308ae8717d03fe60ae When you're inside a stubdom it is probably not so easy though. Interesting. I had not considered that because after upgrading xenstored to a different version, the running xenstored's /proc/$PID/exe shows as # ls -l /proc/$(pgrep xenstored)/exelrwxrwxrwx 1 root root 0 Nov 9 14:06 /proc/3528/exe -> /usr/sbin/xenstored (deleted) But you are right, one can still read that procfs file. Nice! Bjoern Amazon Development Center Germany GmbH Krausenstr. 38 10117 Berlin Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B Sitz: Berlin Ust-ID: DE 289 237 879
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |