When removing a snap with aliases fails, aliases are not cleaned up, leaving the snap in a bad state
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
snapd |
Triaged
|
Medium
|
Unassigned |
Bug Description
I recently attempted to remove the 'lxd' snap:
```
$ snap remove lxd
error: cannot perform the following tasks:
- Stop snap "lxd" services ([--root / enable snap.lxd.
)
- Remove security profile for snap "lxd" (1743) (cannot find installed snap "lxd" at revision 1743)
- Remove data for snap "lxd" (976) (remove /var/snap/
```
I've already filed a bug against lxd about the removal failing. After the removal failed, the snap was in the 'disabled' state:
```
$ snap list
Name Version Rev Developer Notes
core 16-2 1577 canonical -
lxd 2.8 976 canonical disabled
```
In an attempt to fix the first failure, I went to enable it:
```
snap enable lxd
error: cannot perform the following tasks:
- Setup snap "lxd" aliases (cannot create alias symlink: symlink lxd.lxc /snap/bin/lxc: file exists)
```
...and indeed the alias symlink exists, but it's dangling:
```
$ ls /snap/bin/
lxc
$ ls /snap/bin/lxc -l
lrwxrwxrwx 1 root root 7 Apr 6 17:57 /snap/bin/lxc -> lxd.lxc
```
manually removing the symlink and re-enabling the snap works.
I guess that if the 'snap remove' process encounters an error, snapd should attempt to clean up aliases before putting the snap into the 'disabled' state.
The output of 'snap --version' is:
```
snap unknown
snapd 2.23.6
series 16
ubuntu 16.10
```
Changed in snapd: | |
importance: | Undecided → Medium |
Changed in snapd: | |
status: | New → Triaged |