interfaces: support D-Bus activation #6258

jhenstridge · 2018-12-04T07:49:59Z

This is a reworking of PR #2592, expanded to work for both system and session services. In addition to that generalisation, I've made a few changes to how things are handled:

The service activation files are now named after the bus names rather than snap names. This is required for system bus services, but it had the side effect of making it a lot easier to check for existing name ownership.
I renamed the new interface attribute from service to activatable. This was a suggested change on the old PR.
If the app associated with a dbus interface slot is a daemon, we add a SystemdService key to the service activation file, which causes the daemon to be launched via systemd. This currently only benefits system services, but it will be easy to generalise it to session services with PR wrappers: allow user mode systemd daemons #5822.

I do wonder whether it would make sense to limit activatable services to "daemons" and not "apps". Given that the snap needs to ask for activation support, there is no backward compatibility issue.

I'm still working through getting the spread tests ported forward, which is why I've marked this WIP.

interfaces/builtin/dbus.go

jhenstridge · 2018-12-06T08:06:04Z

This branch relies on changes to the test-snapd-dbus-service snap. Those changes have been merged to the bzr branch and the build recipe has run, but I think they're either stuck in manual review, or need manual review requested:

https://launchpad.net/~mvo/+snap/test-snapd-dbus-service

I can't see the dashboard for the snap.

jhenstridge · 2018-12-08T12:05:51Z

I've run into a few problems trying to get my spread tests running on Ubuntu 14.04. I get the following from the dbus-activation-system test:

+ echo 'Making a method call wakes the service'
Making a method call wakes the service
+ MATCH hello
+ dbus-send --system --print-reply --dest=io.snapcraft.SnapDbusService /io/snapcraft/SnapDbusService io.snapcraft.ExampleInterface.ExampleMethod
Error org.freedesktop.DBus.Error.Spawn.FailedToSetup: Failed to setup environment correctly
error: pattern not found, got:
-----
.

On 14.04, the system bus is run by Upstart so it is starting the service manually via the Exec line in the .service file rather than asking systemd to start the service. This is done via the dbus-daemon-launch-helper process, which is passed a D-Bus service name. It uses a simplified config file parser that seems to ignore include directives, so doesn't find service files I'm stashing in /var/lib/snapd/dbus/system-services.

[note that session services work fine, since it doesn't use dbus-daemon-launch-helper to start them].

I suspect the same will happen on newer distros for system services presented as "apps" rather than "daemons" in snap.yaml. There are two ways I can see forward:

Consider 14.04 a lost cause. We are 4 months away from it's end of life after all.
Refactor the code to put service files in /usr/share/dbus-1/system-services along with non-snapd services. This would likely require making the directories writeable on Ubuntu Core systems, and I'm not sure what effect it would have on upgrades.

jhenstridge · 2018-12-10T11:07:01Z

There's currently a few failures in the spread tests:

2018-12-10 10:48:16 Failed tasks: 5
    - google:centos-7-64:tests/main/dbus-activation-system
    - google:ubuntu-14.04-64:tests/main/dbus-activation-system
    - google:ubuntu-core-16-64:tests/main/dbus-activation-system
    - google:ubuntu-core-18-64:tests/main/dbus-activation-system
2018-12-10 10:48:16 Failed project prepare: 4
    - google:opensuse-42.3-64:project
    - google:opensuse-42.3-64:project
    - google:opensuse-42.3-64:project
    - google:opensuse-42.3-64:project

It's not clear that the opensuse failures have anything to do with my branch: it looks like the Go compiler is being invoked with -std=something (a flag intended for gcc) and blowing up.

The ubuntu-14.04-64 failure is the one I mentioned in the previous comment: activating system services via dbus-daemon-launch-helper fails, and 14.04 does not configure the system bus to use systemd activation.

The ubuntu-core-16-64 failure is due to the test trying to talk to the dbus service from an unconfined context, which does not work on core systems. Updating the test to use a client snap with the interfaces connected should make it work on core+classic.

The ubuntu-core-18-64 failure is a ServiceUnknown error. I think the dbus-daemon config fragments I introduce in this PR aren't present on a core18 system. I'm not quite sure how it's meant to be exposed.

The centos-7-64 failure also reports ServiceUnknown. I'm not quite sure of the root cause here yet: there's no failure on Fedora or Amazon, which are using the same spec file.

jhenstridge · 2018-12-11T08:38:33Z

With the test modified to use a confined D-Bus client, I'm seeing failures on 18.04 and 18.10: when the service is inactive, the AppArmor rules block the method call before activation can occur. It's fine on 16.04, so I suspect there is something different in the kernel or dbus-daemon.

jhenstridge · 2018-12-11T12:36:18Z

From what I can tell, dbus-daemon passes an empty destination security label to the kernel when checking a method call to a not-yet-activated service. Manually adjusting the rule to

# allow connected snaps to io.snapcraft.SnapDbusService
dbus (receive, send)
    bus=session
    peer=(name=io.snapcraft.SnapDbusService, label="{snap.test-snapd-dbus-service.session,}"),

... seems to allow the client to activate the service. That doesn't seem to allow communication with unconfined peers, or activation of names other than the one specified in the rule. @jdstrand: can you think of any problems with this change to the rule?

jhenstridge · 2018-12-12T05:59:38Z

With the changes to the AppArmor rule, we're down to two failures:

2018-12-12 05:18:01 Failed tasks: 2
    - google:ubuntu-14.04-64:tests/main/dbus-activation-system
    - google:ubuntu-core-18-64:tests/main/dbus-activation-system

The 14.04 failure is the dbus-daemon-launch-helper issue, and core-18 failure is due to missing the configuration needed to point at the service files I'm writing. Perhaps adding some symlinks to the core18 snap would be the most appropriate option.

I've got no idea why centos-7-64 is now working. I wouldn't have thought any of the changes I made would affect that.

jdstrand

See previous comment for a way to assign a label to the activated service.

interfaces/builtin/dbus.go

my key point was about AssumedAppArmorLabel, which was addressed. I've not reviewed the remaining PR to block on it

jhenstridge · 2018-12-19T07:03:13Z

I realised that with some small changes, my code for managing service files could be made to avoid service files not managed by snapd. The last commit on this branch makes use of this to place system services to /usr/share/dbus-1/system-services on Ubuntu 14.04. With that, the tests are passing everywhere except Ubuntu Core 18 (which snapcore/core18#98 should solve).

However, this does introduce a potential problem with upgrades. What if I install a snap providing an activatable system service on 14.04, then upgrade the host to xenial or bionic? It will likely leave a stale .service file in /usr. I can see three options here:

back out the change and simply document that activatable system services are not supported on 14.04.
Have snapd clear out services from /usr if dirs.SnapDBusSystemServicesDir is not under /usr.
Have all classic distros put services under /usr, and only use /var/lib/snapd/dbus/... on core.

I'm not sure which option is best.

zyga · 2020-05-21T07:25:31Z

interfaces/dbus/backend.go

@@ -55,6 +56,27 @@ func (b *Backend) Name() interfaces.SecuritySystem {
 	return "dbus"
 }

+// setupHostDBusConf will ensure that we have a dbus configuration


In the case of other similar files we create we the trigger point is installation of either core or snapd. I wonder if we could behave similarly there, so that at least all that code is in one place.

what's the relation of this code vs the one in wrappers/core18.go ? the latter will be used only core, this one is for all systems, but wondering what are the various scenarios, will the files not be there early enough in some cases? also should we share code between the two paths?

I'd written this code way back before the wrappers/core18.go code. The intention was the same as the code installing user'd service activation files: ensure things work on a system with an old .deb installed snapd functions if it receives a new version via the core snap.

If we don't need that any more, then I guess we can remove this. I wasn't sure the wrappers/core18.go code did anything on systems without the snapd snap.

yes, wrappers/core18.go is for core >= 18 only, but maybe there's a way to have a helper in wrappers.go that is used in both cases

zyga · 2020-05-21T07:26:03Z

interfaces/dbus/backend.go

+		"session.d/snapd.session-services.conf",
+		"system.d/snapd.system-services.conf",
+	} {
+		dst := filepath.Join("/usr/share/dbus-1/", conf)


This is not using the root directory from dirs.go so it will be harder to test.

zyga

Partial review. Will continue after the call today.

zyga · 2020-05-21T07:28:52Z

interfaces/dbus/backend.go

+	case "system":
+		servicesDir = dirs.SnapDBusSystemServicesDir
+	default:
+		panic(bus)


Perhaps we could just return an error here.

zyga · 2020-05-21T07:31:27Z

wrappers/services.go

+	if appInfo.Daemon == "dbus" && len(appInfo.ActivatesOn) > 0 {
+		slot := appInfo.Slots[appInfo.ActivatesOn[len(appInfo.ActivatesOn)-1]]
+		if err := slot.Attr("name", &busName); err != nil {
+			logger.Noticef("could not get 'name' attribute of dbus slot %q: %v", slot.Name, err)


Suggested change

logger.Noticef("could not get 'name' attribute of dbus slot %q: %v", slot.Name, err)

logger.Noticef("Cannot get 'name' attribute of dbus slot %q: %v", slot.Name, err)

Should this be validated earlier and essentially impossible here?

zyga · 2020-05-21T07:33:41Z

tests/main/dbus-activation-session-legacy/task.yaml

@@ -0,0 +1,39 @@
+summary: D-Bus session services support activation without a user of instance systemd


Is this meant to test how this behaves on Ubuntu 16.04?

Yes. Ubuntu 16.04, CentOS 7, and anything else where the session bus is not managed by systemd.

zyga · 2020-05-21T07:35:12Z

tests/main/dbus-activation-session-legacy/task.yaml

+    . "$TESTSLIB"/snaps.sh
+
+    echo "Set up a private D-Bus session bus"
+    eval "$(dbus-launch --sh-syntax)"


I'm not super fond of seeing this code. Could we run it in a systemd service so that, at least, we can reliably shut it down, along with all children?

Having gone through the exercise I would like you to do something like this instead: https://github.com/zyga/snapd/blob/tweak/detect-stray-dbus-daemon/tests/main/invariant-tool/task.yaml#L64

zyga · 2020-05-21T07:35:53Z

tests/main/dbus-activation-session/task.yaml

+    snap set system experimental.dbus-activation=true
+    #shellcheck source=tests/lib/pkgdb.sh
+    . "$TESTSLIB"/pkgdb.sh
+    distro_install_package dbus-user-session


This is now preinstalled in all systems. I think you can drop it.
In addition, the restore side is missing.

zyga · 2020-05-21T07:45:08Z

wrappers/core18.go

@@ -485,6 +490,53 @@ func undoSnapdUserServicesOnCore(s *snap.Info, inter interacter) error {
 	return nil
 }

+func writeSnapdDbusConfigOnCore(s *snap.Info) error {


Is this similar to setupHostDBusConf?

zyga · 2020-05-21T07:54:15Z

snap/info_snap_yaml.go

@@ -355,7 +355,7 @@ func setAppsFromSnapYaml(y snapYaml, snap *Info, strk *scopedTracker) error {
 			PostStopCommand: yApp.PostStopCommand,
 			RestartCond:     yApp.RestartCond,
 			RestartDelay:    yApp.RestartDelay,
-			BusName:         yApp.BusName,
+			ActivatesOn:     yApp.ActivatesOn,


It looks like this is still pending

zyga · 2020-05-21T07:57:09Z

packaging/ubuntu-14.04/snapd.links

@@ -1,2 +1,4 @@
 ../../usr/lib/snapd/snap-device-helper  /lib/udev/snappy-app-dev
 usr/lib/snapd/snapctl usr/bin/snapctl
+usr/share/dbus-1/session.d/snapd.session-services.conf etc/dbus-1/session.d/snapd.session-services.conf
+usr/share/dbus-1/system.d/snapd.system-services.conf etc/dbus-1/system.d/snapd.system-services.conf


Should we not ship this on 14.04?

And a related question, if we choose not to ship it on 14.04 - should we make it so that on re-exec, this feature is not supported?

Perhaps we should add a function to the each feature, that checks if this is supported by the running system? Not sure

zyga · 2020-05-21T07:58:06Z

interfaces/dbus/backend_test.go

+	}
+}
+
+func (s *backendSuite) _TestUpdatingSnapToOneWithMoreServices(c *C) {


What's the idea with _Test?

pedronis

I did a first pass, some initial comments/questions mostly concentrating on the snap package, but also with some questions about other bits.

pedronis · 2020-05-27T15:57:35Z

dirs/dirs.go

@@ -288,6 +292,10 @@ func SetRootDir(rootdir string) {
 	// freedesktop.org specifications
 	SnapDesktopFilesDir = filepath.Join(rootdir, snappyDir, "desktop", "applications")
 	SnapDesktopIconsDir = filepath.Join(rootdir, snappyDir, "desktop", "icons")
+	// Use 'dbus/services' and `dbus/system-services' to mirror
+	// '/usr/share/dbus-1' hierarchy.
+	SnapDBusSessionServicesDir = filepath.Join(rootdir, snappyDir, "dbus", "services")


will there be dbus-2 ? should this be dbus-1? or no chance of that being an issue?

I think this was some forward thinking by DBus authors. There might be dbus-2 eventually or never, depending on how things evolve.

pedronis · 2020-05-27T16:01:48Z

interfaces/dbus/backend.go

@@ -55,6 +56,27 @@ func (b *Backend) Name() interfaces.SecuritySystem {
 	return "dbus"
 }

+// setupHostDBusConf will ensure that we have a dbus configuration


what's the relation of this code vs the one in wrappers/core18.go ? the latter will be used only core, this one is for all systems, but wondering what are the various scenarios, will the files not be there early enough in some cases? also should we share code between the two paths?

pedronis · 2020-05-27T16:02:59Z

snap/info.go

-	// things vs refactor
-	// https://github.com/snapcore/snapd/pull/794#discussion_r58688496
-	BusName string
+	ActivatesOn []string


this should be close to the definition of Sockets I think, also I would kind of expect ti to be a ActivatesOn []*SlotInfo

pedronis · 2020-05-27T16:03:18Z

snap/info_snap_yaml.go

@@ -90,8 +90,8 @@ type appYaml struct {
 	SlotNames    []string         `yaml:"slots,omitempty"`
 	PlugNames    []string         `yaml:"plugs,omitempty"`

-	BusName  string `yaml:"bus-name,omitempty"`
-	CommonID string `yaml:"common-id,omitempty"`
+	ActivatesOn []string `yaml:"activates-on,omitempty"`


this should go close to sockets stuff

pedronis · 2020-05-27T16:05:27Z

snap/info_snap_yaml.go

@@ -355,7 +355,7 @@ func setAppsFromSnapYaml(y snapYaml, snap *Info, strk *scopedTracker) error {
 			PostStopCommand: yApp.PostStopCommand,
 			RestartCond:     yApp.RestartCond,
 			RestartDelay:    yApp.RestartDelay,
-			BusName:         yApp.BusName,
+			ActivatesOn:     yApp.ActivatesOn,


if Info.ActivatesOn is a []*SlotInfo then this should be probably be setup close to where we set AppInfo.Slots.

As we discussed we should make activates-on imply these slots as being listed as if they were in the "slots" field for the app. Repetition between the two should be ok though.

pedronis · 2020-05-27T16:06:56Z

snap/validate.go

@@ -666,6 +665,15 @@ func ValidateApp(app *AppInfo) error {
 		}
 	}

+	// ActivatesOn is a list of slot names that use the "dbus" type
+	for _, slotName := range app.ActivatesOn {


shouldn't we check somehow that the app is a daemon: dbus or is that orthogonal?

pedronis · 2020-05-27T16:09:55Z

snap/validate.go

+		if slot, ok := app.Slots[slotName]; !ok {
+			return fmt.Errorf("invalid activates-on value %q: slot not found", slotName)
+		} else if slot.Interface != "dbus" {
+			return fmt.Errorf("invalid activates-on value %q: slot does not use dbus interface", slotName)


perhaps:

"..: slot interface is not of the currently supported type (dbus) for activation"

there's a chance will add more types that are supported in activates-on

zyga · 2020-05-28T07:26:54Z

interfaces/builtin/dbus.go

+	if len(apps) == 1 {
+		app := apps[0]
+		if !app.IsService() {
+			return fmt.Errorf("only daemons can be activatable D-Bus services")


This made me realize that the proper spelling is indeed D-Bus and not DBus. We could later do a pass and make the tree consistent.

zyga · 2020-05-28T07:27:45Z

interfaces/builtin/dbus.go

+		}
+		switch app.DaemonScope {
+		case snap.SystemDaemon:
+			if bus != "system" {


Should this be a constant in dbusutil somewhere? Might avoid some chance of typos.

zyga · 2020-05-28T07:29:50Z

interfaces/builtin/dbus_test.go

@@ -37,6 +42,8 @@ type DbusInterfaceSuite struct {
 	testutil.BaseTest
 	iface interfaces.Interface

+	RootDir string


Is this really used in practice?

zyga · 2020-05-28T07:30:53Z

interfaces/builtin/dbus.go

+			return fmt.Errorf("only daemons can be activatable D-Bus services")
+		}
+		switch app.DaemonScope {
+		case snap.SystemDaemon:


Should all of this not be done by validation in the snap package instead?

zyga

A more complete pass.

My main worry: using non-state disk files in interfaces/backend/dbus
Minor comments throughout the code, on validation, 14.04 support, some testing.

zyga · 2020-05-28T07:32:31Z

interfaces/builtin/dbus_test.go

+apps:
+  app-dbus-slot:
+    daemon: simple
+    daemon-scope: user


Super late design nitpick time: could we use daemon-scope: user to derive that a snap uses the session bus? Is there a valid reason for a user session app to grab a name on the system bus?

zyga · 2020-05-28T07:33:22Z

interfaces/builtin/dbus_test.go

+	info := snaptest.MockInfo(c, mockSnapYaml, nil)
+	slot := info.Slots["dbus-service-slot"]
+	err := interfaces.BeforePrepareSlot(s.iface, slot)
+	c.Check(err, ErrorMatches, "only daemons can be activatable D-Bus services")


This highlights my suggestion to handle this via snap validation. It would come up early (at snapcraft time) and does not require any dynamic connection state to determine.

zyga · 2020-05-28T07:36:48Z

interfaces/builtin/dbus_test.go

+
+	err := os.MkdirAll(dirs.SnapDBusSystemServicesDir, 0755)
+	c.Assert(err, IsNil)
+	err = ioutil.WriteFile(filepath.Join(dirs.SnapDBusSystemServicesDir, "org.dbus-snap.system.service"), []byte(`[D-BUS Service]


Hmm, this makes me somewhat worried we are duplicating state facilities. Instead of looking at the disk snapd should determine this via the state. This also frees us from parsing D-Bus service files as a authoritative source of information.

This also probably suggests that bus names should be something snapd models with regards to name clashes, similar to aliases and eventually man pages. I'm not sure how to structure this yet, though.

zyga · 2020-05-28T07:39:50Z

interfaces/dbus/backend.go

@@ -104,10 +126,24 @@ func (b *Backend) Setup(snapInfo *snap.Info, opts interfaces.ConfinementOptions,
 		if err := setupDbusServiceForUserd(snapInfo); err != nil {
 			logger.Noticef("cannot create host `snap userd` dbus service file: %s", err)
 		}
+		if err := setupHostDBusConf(snapInfo); err != nil {
+			logger.Noticef("cannot create host dbus config: %s", err)


Should this be a snap warning instead?

zyga · 2020-05-28T07:40:29Z

interfaces/dbus/backend.go

+	}
+	if err := b.removeServiceActivation(snapName); err != nil {
+		return err
+	}


Do we need to tell DBus daemon that something has changed or is it entirely based on file system notification? Similar question for the case above, where we alter content.

There is a ReloadConfig method on the bus, but dbus-daemon also performs an inotify watch on its config and service directories and automatically reload.

Debian packaging currently issues a ReloadConfig method call to the system bus when installing/removing services. It leaves session buses to fend for themselves though. At this point, it could all be seen as hold over from pre-inotify Linux systems, or to support Debian's non-Linux ports.

zyga · 2020-05-28T07:50:09Z

wrappers/services.go

+	if appInfo.Daemon == "dbus" && len(appInfo.ActivatesOn) > 0 {
+		slot := appInfo.Slots[appInfo.ActivatesOn[len(appInfo.ActivatesOn)-1]]
+		if err := slot.Attr("name", &busName); err != nil {
+			logger.Noticef("could not get 'name' attribute of dbus slot %q: %v", slot.Name, err)


Should this be validated earlier and essentially impossible here?

zyga · 2020-05-28T07:52:57Z

tests/main/dbus-activation-session/task.yaml

+    session-tool -u test systemctl --user is-active snap.test-snapd-dbus-service.session.service
+
+    echo "Removing the snap also removes the service activation file"
+    snap remove test-snapd-dbus-service


We've since learned that removing user session service keeps that service in the memory of systemd --user, while the test user is managed automatically, I wonder if snapd should orchestrate communication with snapd.session-agent.service of each user to ensure this happens.

zyga · 2020-05-28T07:53:26Z

tests/main/dbus-activation-session/task.yaml

+    . "$TESTSLIB"/snaps.sh
+
+    echo "Install a snap containing an activatable D-Bus session service"
+    snap install --edge test-snapd-dbus-service


Does the snap need to come from the store for some assertions?

The snap is a Python daemon making use of packages not included in the base snap, so couldn't simply be built with snap pack. So it is instead built with Snapcraft and the result published to the store.

zyga · 2020-05-28T07:53:43Z

tests/main/dbus-activation-session/task.yaml

+
+systems:
+    # Ubuntu Core does not contain the D-Bus user session systemd units
+    - -ubuntu-core-*


I think you could expand that to support core20 now.

In PR #8943, I've made this test conditional on tests.session has-session-systemd-and-dbus.

zyga · 2020-05-28T07:55:33Z

tests/main/dbus-activation-session-legacy/task.yaml

+    . "$TESTSLIB"/snaps.sh
+
+    echo "Set up a private D-Bus session bus"
+    eval "$(dbus-launch --sh-syntax)"


Having gone through the exercise I would like you to do something like this instead: https://github.com/zyga/snapd/blob/tweak/detect-stray-dbus-daemon/tests/main/invariant-tool/task.yaml#L64

Also implicitly bind the named slot to the app.

* Apps with an activates-on clause must be daemons * The slot's bus must match the daemon scope * The slot must only be activatable on a single app Corresponding checks removed from the dbus interface's BeforePrepareSlot implementation.

zyga · 2020-06-04T15:13:51Z

tests/main/dbus-activation-session/task.yaml

+    [ -f /var/lib/snapd/dbus/services/io.snapcraft.SnapDbusService.service ]
+
+    echo "The service is not initially running"
+    not session-tool -u test systemctl --user is-active snap.test-snapd-dbus-service.session.service


Could you please update the spread test to the new command syntax:

session-tool --prepare => tests.session prepare
session-tool <cmd> => tests.session exec <cmd>
session-tool --restore => tests.session restore

snapcore/snapd#6258 (comment)

…ble D-Bus names

jhenstridge · 2020-06-09T01:06:53Z

I've created PR #8837 that splits out the yaml changes from this branch as a first step towards merging this.

jhenstridge · 2020-06-15T09:36:31Z

I've split more code out from this PR: PR #8860 includes the logic to prevent installing snaps with conflicting activatable D-Bus services, and PR #8861 includes the changes to the D-Bus bus configuration to extend the activation file search paths.

jhenstridge · 2020-11-24T11:54:52Z

After #8943 was merged to master, and I merged master into this old branch, the remaining changes are:

The old interfaces/dbus.Specification.AddService method of adding service files, which is obsoleted by the newer approach in wrappers.
Removal of the AppInfo.BusName field. I didn't bother with this in the newer PR, since there are legitimate reasons why a service not using dbus activation might want to use daemon: dbus. NetworkManager is an obvious example, where it needs to be running from boot, but could use ownership of the bus name to signal that it has started (as the upstream systemd unit does).
Some Ubuntu 14.04 packaging changes that we decided not to bother with after it became clear that system dbus activatable services would not function correctly on that distro.

So I'm marking this PR as closed.

jhenstridge force-pushed the dbus-activation branch from 094458f to 28e83b3 Compare December 4, 2018 07:53

zyga reviewed Dec 4, 2018

View reviewed changes

interfaces/builtin/dbus.go Outdated Show resolved Hide resolved

jhenstridge force-pushed the dbus-activation branch 3 times, most recently from 1bd1a83 to a5a59f7 Compare December 5, 2018 12:04

jhenstridge changed the title ~~WIP: interfaces: support D-Bus activation~~ interfaces: support D-Bus activation Dec 10, 2018

jhenstridge force-pushed the dbus-activation branch 2 times, most recently from 5de375a to 990033d Compare December 10, 2018 09:57

jhenstridge mentioned this pull request Dec 12, 2018

hooks: add symlinks for snapd's D-Bus configuration files snapcore/core18#98

Closed

jdstrand previously requested changes Dec 12, 2018

View reviewed changes

interfaces/builtin/dbus.go Outdated Show resolved Hide resolved

jhenstridge force-pushed the dbus-activation branch 2 times, most recently from 2a5d3c3 to 91dda01 Compare December 15, 2018 07:14

jhenstridge force-pushed the dbus-activation branch 5 times, most recently from 1398dbb to a606b1c Compare December 19, 2018 05:52

pedronis self-requested a review December 20, 2018 10:32

jhenstridge force-pushed the dbus-activation branch 3 times, most recently from 0aeb093 to 0d16b43 Compare December 21, 2018 09:29

jhenstridge force-pushed the dbus-activation branch from 0d16b43 to 6cc6092 Compare January 2, 2019 02:35

zyga reviewed May 21, 2020

View reviewed changes

pedronis reviewed May 27, 2020

View reviewed changes

Merge remote-tracking branch 'upstream/master' into dbus-activation

1c5533b

zyga reviewed May 28, 2020

View reviewed changes

jdstrand added the Needs security review Can only be merged once security gave a :+1: label May 28, 2020

jhenstridge added 2 commits June 2, 2020 11:43

interfaces: improvements to error messages

9c307da

snap: make AppInfo.ActivatesOn a slice of SlotInfos

f2f3485

Also implicitly bind the named slot to the app.

jhenstridge force-pushed the dbus-activation branch from cdfb1a2 to f2f3485 Compare June 3, 2020 01:16

zyga reviewed Jun 4, 2020

View reviewed changes

anonymouse64 pushed a commit to anonymouse64/review-tools that referenced this pull request Jun 4, 2020

support "activates-on" syntax, but don't yet do any checking

386c62c

snapcore/snapd#6258 (comment)

overlord/snapstate: refuse to install snaps with conflicting activata…

44ea334

…ble D-Bus names

jhenstridge mentioned this pull request Jun 9, 2020

snap: add an activates-on property to apps for D-Bus activation #8837

Merged

Merge remote-tracking branch 'upstream/master' into dbus-activation

dc3a065

This was referenced Jun 15, 2020

overlord: refuse to install snaps whose activatable D-Bus services conflict with installed snaps #8860

Merged

data,packaging,wrappers: extend D-Bus service activation search path #8861

Merged

jhenstridge mentioned this pull request Jun 30, 2020

wrappers: generate D-Bus service activation files #8943

Merged

jhenstridge added 3 commits July 6, 2020 09:42

Merge remote-tracking branch 'upstream/master' into dbus-activation

61dbfe8

Merge remote-tracking branch 'upstream/master' into dbus-activation

c8283a7

Merge remote-tracking branch 'upstream/master' into dbus-activation

90d6838

jhenstridge closed this Nov 24, 2020

	logger.Noticef("could not get 'name' attribute of dbus slot %q: %v", slot.Name, err)
	logger.Noticef("Cannot get 'name' attribute of dbus slot %q: %v", slot.Name, err)

		@@ -0,0 +1,39 @@
		summary: D-Bus session services support activation without a user of instance systemd

interfaces: support D-Bus activation #6258

interfaces: support D-Bus activation #6258

Conversation

jhenstridge commented Dec 4, 2018

jhenstridge commented Dec 6, 2018

jhenstridge commented Dec 8, 2018

jhenstridge commented Dec 10, 2018

jhenstridge commented Dec 11, 2018

jhenstridge commented Dec 11, 2018

jhenstridge commented Dec 12, 2018 • edited

jdstrand left a comment

Choose a reason for hiding this comment

jhenstridge commented Dec 19, 2018

Choose a reason for hiding this comment

pedronis May 27, 2020 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zyga left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pedronis left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pedronis May 27, 2020 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

zyga left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jhenstridge commented Jun 9, 2020

jhenstridge commented Jun 15, 2020

jhenstridge commented Nov 24, 2020

jhenstridge commented Dec 12, 2018 •

edited

pedronis May 27, 2020 •

edited

pedronis May 27, 2020 •

edited