Why does snap need to wrap systemd?

snapd
1

Let me apologize in advance: I’m new to using snap (but I have a bit of experience programming and using systemd) so…

This is probably a silly question but I’m wondering why snap needs to wrap systemd services at all? Couldn’t users just put systemd files in the snap and put a (making this up) run-snap-command: systemctl start all_the_things.service in the snapcraft.yaml file? Or perhaps the default behavior (if no such field was found in the .yaml) would be to start a specifically named systemd target. Then users could make the services they need to start PartOf that target.

The reason I’m asking is because wrapping the entire (massive and complex) systemd interface seems unreasonable, however exposing a sub-set of the functionality seems based on the faulty assumption that users don’t need the other systemd features.

p.s. I am asking this after reading through this thread and thinking about adding a request for template unit files (i.e. service files ending with “@”)…

2

We do this for several reasons:

  • the fact that systemd is used to launch services is an implementation detail of snapd that we do not want to expose to snap developers. It is entirely possible that another mechanism could be used on different distributions or in the future, and we don’t want snap developers to have to deal with transitions or making the snap only usable on distros with systemd
  • snaps can be installed on any number of systems with varying systemd versions. Exposing the unit files directly in the manner you describe could cause problems with snaps using units with newer systemd directives than the systemd on the system supports
  • the systemd unit specification is extremely rich and flexible and exposing the entirety of the unit specification would allow snaps to influence the system and other snaps in unpredictable and undesirable ways that are counter to snapd’s design surrounding application isolation, reverts, dependencies, etc, etc

Because of the above, we do not plan to wrap the entire systemd unit specification (as you said, that would be unreasonable) and we are exposing a subset of the functionality. Do note that the subset of functionality is being expanded and reevaluated based on feedback from the field (eg, most recently timers and the thread you mentioned). Importantly, we want to expose needed functionality to developers in a manner that is consistent with snapd’s design principles and work everywhere in the cross-distribution ecosystem.

3 Likes
3

OK. Thank you for the explanation.

4

These are valid points, but doesn’t it cancel out many of the benefits of using systemd at the first place? Especially being able to specify dependencies, launching services on certain events, timers etc. ?

5

I personally don’t think so. We derive a lot of benefit from using systemd in the way we do now and there is work to expose other useful features to snap developers in ways that work within snapd’s design principles.

6

just imagine there will be systemd2.0 in a few years … completely incompatible with todays systemd (because lennart thinks this is cooler for a 2.0 release) …

if the snaps would manage their units directly you would have to re-build all 12948646 snaps in the store then to pick up the new 2.0 features… if the api is wrapped snapd can take care for it and not a single snap from the store needs to be re-built …

1 Like