When removing a snap with aliases fails, aliases are not cleaned up, leaving the snap in a bad state

Bug #1680592 reported by Thomi Richards on 2017-04-06
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
snapd
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.daemon.service] failed with exit status 1: Failed to enable: No such file or directory.
)
- Remove security profile for snap "lxd" (1743) (cannot find installed snap "lxd" at revision 1743)
- Remove data for snap "lxd" (976) (remove /var/snap/lxd/common/lxd/storage-pools/lxd/containers/snapdeltaservice: device or resource busy)
```

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

Michael Vogt (mvo) on 2018-11-15
Changed in snapd:
importance: Undecided → Medium
Changed in snapd:
status: New → Triaged
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers