systemd is responsible for directly or indirectly starting all processes on the system. If you recall, it always places processes it starts in a control group (and processes started by other processes can be placed under its control by creating a scope unit for them). What is not clear is how these control groups are organized. This is where we learn exactly what scopes and slices are.

A slice is a major division of the control group heirarchy. All processes on  the system, including systemd, are in the root slice, named - (dash), or -.slice  Beneath this root slice are any number of sub-slices (and sub-sub-slices). This is configurable based on how the administrator wants to organize resource control.

By default there are four slices just below the root slice:

• the systemd slice. Only systemd is in this slice
• the user slice. All user processes are beneath this slice.
  
• the system slice. All system processes are beneath this slice
  
• the machine slice. All virtual machines are beneath this slice. (this only exists if there are virtual machines)

Slices below this level are named to mimick a path with slashes replaced by dashes. Thus, a subslice x of slice system would be named system-x.

The user slice is for processes run by and on behalf of the user. Each user that is running processes on the system gets their own subslice in the user slice. User processes, however, are not created by systemd directly - they are created by either the user or by processes such as sshd or gdm on behalf of the user. For organization purposes, these processes are organized into scopes beneath their user's slice. For example, if the user logged on via ssh, a scope would be created to hold the ssh session and all the processes created by the user (at the commandline) during that session. If the user had logged on via gdm instead, a scope would be created to hold the gdm session and all the desktop processes.

Now that we have this background, let's look at [ a partial listing of ] the systemd control groups for a RH7 system. On this system, a single user is logged in (me), user 505, via ssh. You can see two sshd processes - a privileged one owned by root, but running on my behalf, and my own sshd. You can also see my shell, my new root shell (via su) and the systemd-cgls command piped thru more, which is displaying systemd's control group tree:

# systemd-cgls | more
├─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 23
├─user.slice
│ ├─user-505.slice
│ │ ├─session-171.scope
│ │ │ ├─16612 sshd: gboyd [priv]
│ │ │ ├─16624 sshd: gboyd@pts/2
│ │ │ ├─16626 -bash
│ │ │ ├─16684 su -
│ │ │ ├─16691 -bash
│ │ │ ├─18255 systemd-cgls
│ │ │ └─18256 more
│ │ └─session-1.scope
│ │   └─1885 /usr/bin/pulseaudio --start
│ └─user-42.slice
│   └─session-c2.scope
│     ├─18158 gdm-session-worker [pam/gdm-launch-environment]
│     ├─18163 /usr/bin/gnome-session --autostart /usr/share/gdm/greeter/autos...
│     ├─18166 /usr/bin/dbus-launch --exit-with-session /usr/bin/gnome-session...
│     ├─18167 /bin/dbus-daemon --fork --print-pid 4 --print-address 6 --sessi...

(I have no idea what the session for pulseaudio is, but evidently it is running on my behalf! You can also see a user #42 slice, however, I am the only user logged in! Interestingly, that user is reported:

# who
(unknown) :0           2014-07-16 06:31 (:0)
gboyd    pts/2        2014-07-16 06:01 (192.168.122.1)

So let's check to see who user 42 is:

# grep :42: /etc/passwd
gdm:x:42:42::/var/lib/gdm:/sbin/nologin

That makes sense - the login session for the GUI is running as gdm, the GNOME display manager. Beneath it are all the processes that are involved in managing a desktop session. When someone logs into the desktop, these processes will be inherited by them, their owner will be changed, and they will be moved into a new scope created for the user in the user slice.

Let's continue our look at the control group listing and look at [ part of ] the system slice:

└─system.slice
  ├─sshd.service
  │ └─5784 /usr/sbin/sshd -D
  ├─udisks2.service
  │ └─1918 /usr/lib/udisks2/udisksd --no-debug
  ├─bluetooth.service
  │ └─1898 /usr/sbin/bluetoothd -n
  ├─colord.service
  │ └─1616 /usr/libexec/colord
  ├─upower.service
  │ └─1557 /usr/libexec/upowerd
  ├─polkit.service
  │ └─751 /usr/lib/polkit-1/polkitd --no-debug

Just to check for consistency, let's look in the /usr/lib/systemd/system directory for the unit files corresponding to these services:

# ls {sshd,udisks2,bluetooth,colord,upower,polkit}.service
bluetooth.service  polkit.service  udisks2.service
colord.service     sshd.service    upower.service

and, if we examine one of the unit files

# more udisks2.service
[Unit]
Description=Disk Manager
Documentation=man:udisks(8)

[Service]
Type=dbus
BusName=org.freedesktop.UDisks2
ExecStart=/usr/lib/udisks2/udisksd --no-debug

we can verify that the command executed to start udisksd is, indeed, the ExecStart command. (You will see a different Type here - dbus, which means that the service announces its start on the system message bus, and that's where systemd must look to verify it has started.) (udisks manages removable disks - whenever you insert a CD or a thumb drive, udisks notices and announces its presence on dbus so that other desktop processes can take action, such as mounting the disk, drawing the icon, and opening a window to it.)

Commands to manipulate control groups

Frankly, I don't know much about control groups, and I certainly am not well-enough versed on the subject to tell you how to manage them yourself. Interested readers are referred to all the commands whose names start with cg - there is a man page on each

# cg
cgclassify      cgcreate        cgdisk          cgrulesengd
cgclear         cgdcbxd         cgexec          cgset
cgconfigparser  cgdelete        cgget           cgsnapshot

However, feel free to look at systemd's control groups using systemd-cgls. You can also look at the heirarchy yourself under /sys/fs/cgroup/systemd