Week 20 of 2017 in snapd

Hello all,

This week we’re starting a new series of weekly reports covering what happened to the project during the week. Please note that this is about the development process. The improvements and fixes discussed here are most likely not available into a stable release yet.

These were some of the topics receiving attention during week 20 of 2017 (May 14 to 20):

Content interface improvements

After months in development and step-by-step merging, the backend infrastructure which allows dynamic mount namespace changes was finally finished. The first visible outcome of this change is a major usability improvement in the content interface: connecting and disconnecting such plugs and slots now updates the snap filesystems in real time. In other words, directories visible to the snap are mounted and unmounted as existing snap processes run. This fixes a long standing issue where if an application is started before a content connection is in place it would not function normally even after the connection was made.

Fixes in gadget default configurations

The interaction of configuration defaults set in the gadget and first boot was fixed so that they work also for snaps installed at first boot (core, kernel, gadget itself and any required snaps by the model). More details here.

Improved hook execution ordering

A change was made so that only one hook of any particular snap will run at a time, which makes correct behavior much easier to achieve.

Use of snapctl out of hooks

More progress was made in the feature that enables the snapctl tool to be used out of hooks. Many upcoming features will benefit from this functionality, since it offers a general channel of communication between the snap and its controlling snapd. Review comments for the basic functionality have been addressed and the basic functionality should land soon.

Fix in snap enable

The snap enable command would ignore the flags set during install, which meant the snap might stop working when being re-enabled (for example, if it required devmode) and the state might also be inconsistent. This was fixed.

Fix in service startup behavior

If a snap with multiple services was installed but one of them failed during startup, the installation would be undone but the services that were successfully started would remain active. This was fixed.

Service management commands

Work was started to support service management commands via the snap tool. This is also an enabler for a snap’s hook doing the same thing via snapctl.

Test automation improvements

Some of the automated tests were tuned to work with the new snap store system that is going live this week, and some progress was also made on Jenkins jobs that talk to testflinger.

Interface metadata

Interfaces will soon expose more details about their purpose in a programmatic way, and a new snap interface command will allow observing such details and the overall system status from the perspective of a particular interface name or plug/slot name.

Release work

Version 2.26.3 of the core snap was validated and released into the beta channel, and 2.25 got validated and reached the candidate channel. Unfortunately a regression was detected into 2.25 and its released into the stable channel was blocked. This is being addressed, and 2.25 will probably be skipped while 2.26 will go through the validation process once that regression is addressed.

The versioning scheme of the core snap as shown in snap info core will also be slightly more reasonable for edge versions (git snapshots).

Progress on the exec kernel bug

There’s a bug in the kernel which causes file attributes such as the setuid bit to be dropped when a clone and an execv call happen concurrently. Progress was made on fixing this both in the kernel and in the Go compiler suite (belts and suspenders).

Hmmm. I don’t see it fixed in 16-2 (2314) 70MB -.
Disable/enable does not respect devmode.

23 in revision num is the week number 23 of 2017 I suppose? So shouldn’t it include week 20?

no, the revision numbers only iterate by one for each build, there is no relation to a date or anything …