snapd does not properly detect service/mount unit status

Bug #1623802 reported by Simon Fels
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Snappy
Fix Released
Undecided
Unassigned

Bug Description

On my system running the ubuntu-core snap

morphis@localhost:~$ snap list ubuntu-core
Name Version Rev Developer Notes
ubuntu-core 16.04.1 526 canonical -

with snapd/snap

morphis@localhost:~$ snap --version
snap 2.14.2~16.04+ppa224-1
snapd 2.14.2~16.04+ppa224-1
series 16

I see the following when I want to remove the openwrt snap I've installed with snap install --edge --devmode openwrt before:

morphis@localhost:~$ sudo snap remove openwrt
2016-09-15T06:52:31Z INFO Waiting for snap.openwrt.init.service to stop.
2016-09-15T06:52:50Z INFO Waiting for snap.openwrt.init.service to stop.
2016-09-15T06:53:00Z INFO snap.openwrt.init.service refused to stop, killing.
2016-09-15T06:53:12Z INFO Waiting for snap-openwrt-8.mount to stop.
2016-09-15T06:53:12Z ERROR cannot remove snap file "openwrt", will retry in 3 mins: snap-openwrt-8.mount failed to stop: timeout
2016-09-15T06:56:13Z ERROR cannot remove snap file "openwrt", will retry in 3 mins: umount: /snap/openwrt/8: not mounted
[-] Remove snap "openwrt" (8) from the system

The spinner seems to go forever. Looking at the actual status of both units

morphis@localhost:~$ sudo systemctl status snap.openwrt.init
● snap.openwrt.init.service - Service for snap application openwrt.init
   Loaded: loaded (/etc/systemd/system/snap.openwrt.init.service; enabled; vendor preset: enabled)
   Active: inactive (dead) (Result: exit-code) since Thu 2016-09-15 06:47:21 UTC; 5min ago
  Process: 2141 ExecStart=/usr/bin/snap run openwrt.init (code=exited, status=1/FAILURE)
 Main PID: 2141 (code=exited, status=1/FAILURE)

Sep 15 06:47:21 localhost.localdomain systemd[1]: snap.openwrt.init.service: Failed with result 'exit-code'.
Sep 15 06:47:21 localhost.localdomain systemd[1]: snap.openwrt.init.service: Service hold-off time over, scheduling restart.
Sep 15 06:47:21 localhost.localdomain systemd[1]: Stopped Service for snap application openwrt.init.
Sep 15 06:47:21 localhost.localdomain systemd[1]: snap.openwrt.init.service: Start request repeated too quickly.
Sep 15 06:47:21 localhost.localdomain systemd[1]: Failed to start Service for snap application openwrt.init.
Sep 15 06:52:30 localhost.localdomain systemd[1]: snap.openwrt.init.service: Trying to enqueue job snap.openwrt.init.service
Sep 15 06:52:30 localhost.localdomain systemd[1]: snap.openwrt.init.service: Installed new job snap.openwrt.init.service/sto
Sep 15 06:52:30 localhost.localdomain systemd[1]: snap.openwrt.init.service: Enqueued job snap.openwrt.init.service/stop as
Sep 15 06:52:30 localhost.localdomain systemd[1]: snap.openwrt.init.service: Job snap.openwrt.init.service/stop finished, re
Sep 15 06:52:30 localhost.localdomain systemd[1]: Stopped Service for snap application openwrt.init.
morphis@localhost:~$ sudo systemctl status snap-openwrt-8.mount
● snap-openwrt-8.mount - Mount unit for openwrt
   Loaded: loaded (/etc/systemd/system/snap-openwrt-8.mount; enabled; vendor preset: enabled)
   Active: inactive (dead) since Thu 2016-09-15 06:53:11 UTC; 14s ago
    Where: /snap/openwrt/8
     What: /var/lib/snapd/snaps/openwrt_8.snap

the snap.openwrt.init.service unit never started successfully (which is a problem with the snap itself) and is marked as dead. Also the mount unit is already inactive.

It looks like something is going wrong here with mapping the unit status from systemd to snapds internal process.

Please also note that this was discovered on a system running a 3.4 kernel which is not much supported by systemd itself. There could be a chance that there is a feature missing which contributes to this bug.

Simon Fels (morphis)
description: updated
Revision history for this message
John Lenton (chipaca) wrote :

I ... think this is fixed? Please let us know if not.

Changed in snappy:
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.