lxcfs-4.0.4: Startup fails with "undefined symbol: lxcfs_clone"

[ganto]

Since lxcfs-4.0.4 the startup fails with the following error on Fedora when using the RPM package build through COPR: ganto/lxc4:

Jul 05 23:08:14 host.example.com systemd[1]: Started FUSE filesystem for LXC.
Jul 05 23:08:14 host.example.com lxcfs[184173]: /usr/lib64/lxcfs/liblxcfs.so: undefined symbol: lxcfs_clone - Failed to open liblxcfs.so
Jul 05 23:08:14 host.example.com systemd[1]: lxcfs.service: Main process exited, code=exited, status=1/FAILURE

When checking the source code it seems that between lxcfs-4.0.3 and lxcfs-4.0.4 the implementation of lxcfs_clone() was replaced with lxcfs_raw_clone() in 0c525b4. However, cgroup_fuse.c still references lxcfs_clone() twice.

[stgraber]

@brauner

This is a bit odd, we'd have expected all our tests and users to fail on that too.

[grzsmp]

Hi. I have the same issue on redhat 7.8.

2020-07-05T22:27:45Z lxd.daemon[4898]: => Starting LXD
2020-07-05T22:27:45Z lxd.daemon[4898]: t=2020-07-06T00:27:45+0200 lvl=warn msg="AppArmor support has been disabled because of lack of kernel support"
2020-07-05T22:27:46Z lxd.daemon[4898]: => LXD is ready
2020-07-05T22:27:46Z lxd.activate[4897]: ===> System doesn't support socket activation, starting LXD now
2020-07-05T22:27:46Z systemd[1]: Started Service for snap application lxd.activate.
2020-07-05T22:29:16Z lxd.daemon[4898]: lxcfs: symbol lookup error: /snap/lxd/current/lib/liblxcfs.so: undefined symbol: lxcfs_clone
2020-07-05T22:29:18Z lxd.daemon[4898]: utils.c: 247: recv_creds: Timed out waiting for scm_cred: No such file or directory
2020-07-05T22:29:18Z lxd.daemon[4898]: lxcfs: symbol lookup error: /snap/lxd/current/lib/liblxcfs.so: undefined symbol: lxcfs_clone
2020-07-05T22:29:20Z lxd.daemon[4898]: utils.c: 284: send_creds: No such file or directory - Failed getting reply from server over socketpair: 2
2020-07-05T22:29:20Z lxd.daemon[4898]: lxcfs: symbol lookup error: /snap/lxd/current/lib/liblxcfs.so: undefined symbol: lxcfs_clone

[brauner]

I see the issue. Let me send a fix

@brauner

This is a bit odd, we'd have expected all our tests and users to fail on that too.

We use RTLD_LAZY which means that the symbol will only be tried to resolve on first use. What we should do is to use RTLD_NOW in the test-suite.

[ganto]

Thanks for the fix. Resolved the issue for me.

[toby63]

@stgraber
This problem also occurs in the newest arch package:
https://bugs.archlinux.org/task/67383?project=5&string=lxcfs

As this "breaks" functionality, could you release a new upstream version with the fix?