What is the difference between a systemd scope and a systemd slice?

Question

What is the difference between a systemd scope and a systemd slice?

Both are for resource management. But what can you do only with a slice and what only with a scope?

Answer 1

As described in systemd(1):

• Services are a type of unit which instructs systemd how to start a process, as specified by systemd.exec. Services are not the only mechanism for spawning processes from systemd, but they are unique in being able to do so arbitrarily, without being bound to a device or socket.
• Scopes are a type of unit which instructs systemd how to group processes which it didn't start itself.

As you can see, services and scopes are both primitives for grouping processes. A couple of differences worth noting are:

• Scopes are not declared by a unit file, but rather created programatically using systemd's dbus API.
• Services have a notion of a main process, and the lifetime of the service is the lifetime of that process. For scopes, the lifetime of the unit is bound to the "existence of at least one process in the scope."

Now, to introduce the third unit type:

• Slices are a type of unit which groups services, scopes, and other slices.
  • Why not use a scope instead? Because scopes manage processes, not other systemd units. Also, scopes can't be declared with a file, which is desirable.
  • Why not use a service instead? Well, services themselves actually are capable of encapsulating scopes and slices (and we'll see the utility of this later), so that's not the answer. My answer would be that services are semantically bound to something being executed. Using slices allows one to group systemd units together, without necessarily executing a process.

Services, scopes, and slices are the three systemd unit types which support resource control. This comprises systemd's interface to the Linux kernel's cgroups API. All three are useful, and all three are used on any default systemd system. To give some examples of how they are used:

• To run a process regularly, or in response to a stimulus somewhere in the systemd ecosystem, you use a service - this, you are likely familiar with.
• When seeking to control the relative resource usage of several services, you use slices, as demonstrated in this article. If it was just one service, than configuring the resource limits in that service unit would suffice. However, for that article, slices are right because:
  • For the "parent" of this hierarchy — that is, the unit grouping the services together — there's nothing to execute, so a parent service isn't applicable (also, I'm not sure if systemd provides a way to do this grouping for a regular service unit).
  • Scopes are for grouping processes not spawned by systemd. Here, we have the ability to spawn the processes using service units though. To reiterate, if you are using services to spawn the processes, scopes are irrelevant.

To go through a more general look at the system:

• The systemd process itself is located under a scope under the root slice, because it can't really exist as a service.
• Broadly, the system is split into a system.slice slice for system services, and a user.slice slice for user slices, eventually containing user processes.
• When a user logs in (e.g. by graphical session, terminal, or SSH), systemd-loginctl.service sets up the following:
  • The [email protected] template is instantiated, within the user's slice. This service starts the systemd user instance.
  • Within [email protected] is a session.slice for the user services. This is the one case where a service is used for grouping other units, and it's possible because it's logical for it to launch a process, while still grouping other units below it.

Answer 2

It seems to be a little like files and directories in a resource management tree:

• services, slices and scopes represent directories
• processes (things with PIDs) represent files
• slices can not contain files, only other directories
  • i.e. slices don’t launch processes directly, they have slices, scopes or services beneath them
• services and scopes can only be under a “slice directory”, not a “service or scope directory”
  • thus, the shape of the directory tree is determined by slices only

Links:

• systemd’s documentation regarding cgroups, decent source to shine some light on the topic
• service vs. slice
• service vs. scope