Created attachment 544738 [details, diff] lxd-3.4_ebuild-inject-rpath-into-lxd.patch Basically a symptom of go's usurpation of normal build-system and packaging in favor of the ridiculous "go" command-line toy and magical thinking. OK,... so, now that that's out of my system... on my systemd ~amd64 box, lxd recently started failing to "d" like so: Aug 23 10:45:08 moneypit systemd[1]: Started Container hypervisor based on LXC. Aug 23 10:45:08 moneypit systemd[1]: lxd.service: Main process exited, code=exited, status=127/n/a Aug 23 10:45:08 moneypit systemd[1]: lxd.service: Failed with result 'exit-code'. Aug 23 10:45:09 moneypit systemd[1]: lxd.service: Service RestartSec=100ms expired, scheduling restart. Aug 23 10:45:09 moneypit systemd[1]: lxd.service: Scheduled restart job, restart counter is at 4. Aug 23 10:45:09 moneypit systemd[1]: Stopped Container hypervisor based on LXC. Aug 23 10:45:09 moneypit lxd[20998]: /usr/sbin/lxd: error while loading shared libraries: libdqlite.so.0: cannot open shared object file: No such file or directory Note the last line which clarifies the actual problem. Sure enough, ldd confirms that /usr/sbin/lxd is linked against libdqlite.so.0 which ain't there. Turns out it is there, but its in /usr/lib/lxd/ (*). Other distributions are solving this by wrapping lxd and/or injecting LD_LIBRARY_PATH into the global environment (see: https://github.com/lxc/lxd/issues/4913), which seems like a shockingly inelegant best-practice guideline... :) Again probably more a symptom of upstreaming drinking the go cool-aid (since, AFAICT there is not as yet any clean way to tell go to apply an rpath to a single link). We could put an LD_LIBRARY_PATH into the openrc/systemd scripts, I guess, but I'd prefer to see Gentoo shove a runpath linker flag down go's throat as in the attached patch, which avoids the need to fool around with LD_LIBRARY_PATH hacks entirely. One other nit-picky note: as currently implemented, the lxd ebuild will keep all those CGO_*FLAGS variables around and exported if the "daemon" use-flag is active. That seems like somewhat side-effect prone behavior (notably, it would be more so, after my patch was applied, as the runpath would now affect all the "tools" USE-conditional executable builds, when "use daemon && use tools". A quick-and-dirty way to avoid that might be to simply reverse the order of the "if use tools ... fi" and "if use daemon ... fi" clauses in the ebuild. However in the interest of readability, I did not include such a change in my patch. -- * I kinda feel like maybe it should really be in /usr/lib64/lxd/? But, (a) meh, w/e and (b) that's an orthogonal issue/question.
Thanks for catching this. I inject LD_LIBRARY_PATH in the openrc script but I missed the systemd unit. Since I don't have a systemd system live right now, and you do, can you confirm that it's fixed by adding into lxd.service: [Service] ... Environment=LD_LIBRARY_PATH=/usr/lib/lxd ? If it works I'll push the fix promptly.
Confirm with the suggestion it works ● lxd.service - Container hypervisor based on LXC Loaded: loaded (/lib/systemd/system/lxd.service; enabled; vendor preset: disabled) Active: active (running) since Fri 2018-08-31 02:45:55 EDT; 7s ago Main PID: 29555 (lxd) Tasks: 24 (limit: 4915) Memory: 33.0M CGroup: /system.slice/lxd.service ├─29555 /usr/sbin/lxd --group lxd └─29665 dnsmasq --strict-order --bind-interfaces --pid-file=/var/lib/lxd/networks/lxdbr0/dnsmasq.pid --except->
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=466f357db24e56349ca2f09e05a4b406087d62c0 commit 466f357db24e56349ca2f09e05a4b406087d62c0 Author: Erik Mackdanz <stasibear@gentoo.org> AuthorDate: 2018-09-09 22:49:53 +0000 Commit: Erik Mackdanz <stasibear@gentoo.org> CommitDate: 2018-09-09 22:50:43 +0000 app-emulation/lxd: Fix missing dep, fix bad linking Closes: https://bugs.gentoo.org/664394 Closes: https://bugs.gentoo.org/664990 Package-Manager: Portage-2.3.46, Repoman-2.3.10 app-emulation/lxd/lxd-3.4-r1.ebuild | 233 ++++++++++++++++++++++++++++++++++++ 1 file changed, 233 insertions(+)
After studying your patch, it's much more elegant than LD_LIBRARY_PATH. Thanks for proposing that!
