Container name autocomplete on snap package

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/

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


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
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:


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?


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.


Do I need to open an issue on Github or something?