For some reason, this isn’t working, which mostly isn’t a big deal but does make maintenance tasks go by more quickly. General lxc commands autocomplete, i.e. typing ‘st’[tab] yields ‘start’ ‘stop’ and ‘storage’. It’s just the container names it seems. I don’t recall having this issue when I installed from the ganto/lxc3 COPR repo.
Any ideas on this?
Seems to be working here, though note that lxc start <tab> will show your local files if no match is found (that is, there are no containers currently stopped).
Does it depend on anything in particular to work? How is it fetching the names normally?
For example, I’m most typically using lxc shell <container> and such. And it does as you say, it shows the local files.
for lxc start, it looks for lxc list --format=csv --columns=ns | grep -E 'STOPPED$' | cut -d, -f1
Hrm. Running the front part of that command returns what looks like the valid information. So it doesn’t seem to be an issue with lxc itself. I guess I’ll go spelunking the completions file and see what I can see.
Hmm. In /usr/share/bash-completion/completions/ is a set of symlinks that just points (eventually) at /var/lib/snapd/snap/snapd/current/usr/lib/snapd/complete.sh
That file seems to not really have anything explicitly to do with lxc per se. Looks like it builds a command for snap run near the end.
Feels like I’m going down the wrong path.
I believe we also directly inject a symlink in /etc/bash_completion.d/lxc
Interesting.
jon@akane $ file /etc/bash_completion.d/lxc
/etc/bash_completion.d/lxc: broken symbolic link to /snap/lxd/current/etc/bash_completion.d/snap.lxd.lxc`
The actual extant file there is just lxd.lxc.
Guess I’ll go ahead and try to fix the symlink.
Ah, nevermind, I misread the path. I don’t have a /snap in the root of my disk. Hrm.
Deleting the symlink and issuing snap restart lxd recreates the broken symlink.
Oh right, looks like we have this badly handle for distros that don’t use /snap.
If I manually set the symlink to
/var/lib/snapd/snap/lxd/17320/etc/bash_completion.d/snap.lxd.lxc
and then source the /etc/bash_completion.d/lxc file, I get working resolution of the container names. The only issue is that the
WARNING: cgroup v2 is not fully supported yet, proceeding with partial confinement gets injected into the [tab] when I push it. Kinda annoying.
Hmm, so our logic for the symlink uses the env variables we’re provided by snapd, so it’s not a wrong hardcoded path on our side… that’s going to make fixing this a bit more challenging.
Do you know what the /snap equivalent is on Fedora?
Not sure what /snap on a debian-based distro is for. Is it just where all of the snap stuff is installed? Seems to be /var/lib/snap as far as I can tell.
Is there something I can run that will dump the env vars you need to see from snapd?
Running snap run --shell lxd.lxc and then env I get:
SNAP_REVISION=17320
SNAP_ARCH=amd64
SNAP_INSTANCE_KEY=
SUDO_COMMAND=/bin/bash
SNAP_USER_COMMON=/root/snap/lxd/common
USER=root
HOME=/root/snap/lxd/17320
SNAP=/snap/lxd/17320
SNAP_COMMON=/var/snap/lxd/common
SNAP_NAME=lxd
XDG_DATA_DIRS=/usr/local/share:/usr/share:/var/lib/snapd/desktop
SNAP_INSTANCE_NAME=lxd
SNAP_DATA=/var/snap/lxd/17320
Ok, so you have things in /var/lib/snap/lxd/current/lxd/?
Path wasn’t quite like that. There is no /var/lib/snap
[root@akane jon]# ll /var/lib/snapd/snap/lxd/current/
total 0
drwxr-xr-x. 2 root root 2090 Sep 18 23:17 bin
drwxr-xr-x. 2 root root 232 Sep 18 23:17 commands
drwxr-xr-x. 2 root root 27 Sep 18 23:17 criu
drwxr-xr-x. 2 root root 29 Sep 18 23:17 empty
drwxr-xr-x. 4 root root 156 Sep 18 23:17 etc
drwxr-xr-x. 5 root root 1309 Sep 18 23:17 lib
drwxr-xr-x. 4 root root 42 Sep 18 23:10 lxc
drwxr-xr-x. 2 root root 60 Sep 18 23:16 lxcfs
drwxr-xr-x. 3 root root 45 Sep 18 23:17 meta
drwxr-xr-x. 5 root root 70 Sep 18 23:16 share
drwxr-xr-x. 4 root root 92 Sep 18 23:17 snap
drwxr-xr-x. 3 root root 28 Sep 18 23:16 usr
drwxr-xr-x. 2 root root 71 Sep 18 23:17 wrappers
drwxr-xr-x. 4 root root 37 Sep 18 23:17 zfs-0.6
drwxr-xr-x. 4 root root 37 Sep 18 23:17 zfs-0.7
drwxr-xr-x. 4 root root 37 Sep 18 23:17 zfs-0.8
This means that there is a system-wide /snap/ directory, no?
Nope!
jon@akane $ ll /
total 16K
lrwxrwxrwx. 1 root root 7 Jan 28 2020 bin -> usr/bin
dr-xr-xr-x. 5 root root 4.0K Sep 4 16:37 boot
drwxr-xr-x. 22 root root 4.1K Sep 25 22:09 dev
drwxr-xr-x. 90 root root 8.0K Sep 4 16:37 etc
drwxr-xr-x. 3 root root 17 Jul 12 12:10 home
lrwxrwxrwx. 1 root root 7 Jan 28 2020 lib -> usr/lib
lrwxrwxrwx. 1 root root 9 Jan 28 2020 lib64 -> usr/lib64
drwxr-xr-x. 2 root root 6 Jan 28 2020 media
drwxr-xr-x. 3 root root 18 Aug 1 16:01 mnt
drwxr-xr-x. 2 root root 6 Jan 28 2020 opt
dr-xr-xr-x. 357 root root 0 Sep 25 22:08 proc
dr-xr-x---. 5 root root 190 Sep 25 21:17 root
drwxr-xr-x. 29 root root 1000 Sep 25 22:09 run
lrwxrwxrwx. 1 root root 8 Jan 28 2020 sbin -> usr/sbin
drwxr-xr-x. 6 root root 71 Aug 2 14:13 srv
dr-xr-xr-x. 13 root root 0 Sep 25 22:08 sys
drwxrwxrwt. 13 root root 260 Sep 26 12:27 tmp
drwxr-xr-x. 12 root root 144 Jul 12 12:08 usr
drwxr-xr-x. 20 root root 278 Sep 4 16:33 var
/snap is valid inside the snap’s own mount namespace but isn’t valid on the host system.
That’s usually not an issue except for this very particular case where the snap creates a symlink on the host system to a file contained in the snap.
Basically our script sees the file at /snap/lxd/… and so creates the symlink on the host to that, but that results in a broken symlink as the host does not see a /snap/lxd/… but has that same tree under /var/lib/snapd/snap/… instead.
What we’ll need to do is have the snap check if we’re in a situation where the host system has no /snap but has /var/lib/snapd/snap and if that’s the case, alter the symlink’s target. The symlink will appear to be broken from what the snap sees but it will be functional on the host where we care about it.
Interesting.
Do I need to open an issue on Github or something?