Are there plans to support daemon aliases?

snapd
#1

Hi,

I’d like to be able to define daemon aliases. For example, instead of:

systemctl restart snap.app.daemon

I’d like to be able to define an alias that enables:

systemctl restart app-daemon

where:

apps:
  daemon:
    command: app-daemon
    daemon: simple
    aliases:
      - app-daemon
  command:
    command: app-command
    aliases:
     - app-command

This would be useful in transitioning from a deb to snap, where the service has traditionally gone by the name of app-daemon.

Are there any plans to support daemon aliases?

Thanks,
Corey

The snapd roadmap
#2

Hey Corey,

Yeah, in the recent sprint we actually agreed to do exactly that: if a daemon has an alias, it will become an alias for systemd as well. Note that the behavior of aliases is changing, though, so the aliases field inside the app itself will be dropped. The alias may be established by the user, or by the snap declaration, in both cases similarly but not completely the same as was done before.

1 Like
#3

Got it, sounds good. And thanks!

#4

Commenting on this based on a recent discussion with the snapd team.

A recent regression occurred with the Xenial netplan Debian package, where a patch got dropped which made netplan try both the snap service and standard upstream service names for NetworkManager when applying a new configuration. The original patch also stated that the patch should get dropped if/when snapd was fixed:

The ability to declare a daemon alias would allow us to finally drop the patch for good.

The bug is currently being worked on, but it’s unclear to me whether we really want to enable this behavior (i.e. make netplan try both names) for Bionic or not (the Bionic bug task is currently FixCommitted)?

Here’s a link to the forum post where the regression was first discovered: