snapd eats 100% CPU for about 5 minutes on first boot causing a load of >2.0

Bug #1638537 reported by Oliver Grawert on 2016-11-02
This bug affects 1 person
Affects Status Importance Assigned to Milestone
snapd (Ubuntu)

Bug Description

during first boot it takes very long for the "please press eneter" message to come up on screen.
booting a pi image with systemd.debug-shell added to /boot/cmdline.txt one can watch top and syslog during that time. obviously snapd is doing the initial snap setup at this point and eats 100% CPU and causes extreme I/O for about 5 minutes where the board nearly does not react at all. has the output of
grep -E '(snapd|mount)' /var/log/syslog

Oliver Grawert (ogra) wrote :

seems the last lines are most interesting here:

Nov 2 11:52:26 localhost /usr/lib/snapd/snapd[1128]: taskrunner.go:353: DEBUG: Running task 21 on Do: Run configure hook of "pi3" snap if present
Nov 2 11:56:19 localhost /usr/lib/snapd/snapd[1128]: taskrunner.go:353: DEBUG: Running task 24 on Do: Request device serial

there are 4minutes between these two steps ...


trying to watch snap changes takes very long to return anything at that point, eventually it shows "initialize system" ... then on a second run "initialize device", both take minutes to return.

Changed in snappy:
importance: Undecided → High
Changed in snapd (Ubuntu):
importance: Undecided → High
summary: snapd eats 100% CPU for about 5 minutes on first boot causing a load of
- >2.0c
+ >2.0
Simon Fels (morphis) wrote :

I see this as well on various arm based devices. Any more ideas what could be the reason or a possible fix?

Kyle Fazzari (kyrofa) wrote :

From the moment I entered my SSO email and hit "go" to the moment it returned telling me how to SSH in was about 7 minutes on the dragonboard.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers