# systemd.slice

## NAME



           systemd.slice - Slice unit configuration
    


## SYNOPSIS



           _slice_.slice
    


## DESCRIPTION



           A unit configuration file whose name ends in ".slice" encodes
           information about a slice unit. A slice unit is a concept for
           hierarchically managing resources of a group of processes. This
           management is performed by creating a node in the Linux Control
           Group (cgroup) tree. Units that manage processes (primarily scope
           and service units) may be assigned to a specific slice. For each
           slice, certain resource limits may be set that apply to all
           processes of all units contained in that slice. Slices are
           organized hierarchically in a tree. The name of the slice encodes
           the location in the tree. The name consists of a dash-separated
           series of names, which describes the path to the slice from the
           root slice. The root slice is named -.slice. Example:
           foo-bar.slice is a slice that is located within foo.slice, which
           in turn is located in the root slice -.slice.
    
           Note that slice units cannot be templated, nor is possible to add
           multiple names to a slice unit by creating additional symlinks to
           its unit file.
    
           By default, service and scope units are placed in system.slice,
           virtual machines and containers registered with
           systemd-machined(8) are found in machine.slice, and user sessions
           handled by systemd-logind(8) in user.slice. See systemd.special(7)
           for more information.
    
           See systemd.unit(5) for the common options of all unit
           configuration files. The common configuration items are configured
           in the generic [Unit] and [Install] sections. The slice specific
           configuration options are configured in the [Slice] section.
           Currently, only generic resource control settings as described in
           systemd.resource-control(5) are allowed.
    
           See the **New Control Group Interfaces******[1] for an introduction on how
           to make use of slice units from programs.


## AUTOMATIC DEPENDENCIES



       **Implicit Dependencies**
           The following dependencies are implicitly added:
    
           •   Slice units automatically gain dependencies of type _After=_ and
               _Requires=_ on their immediate parent slice unit.
    
       **Default Dependencies**
           The following dependencies are added unless _DefaultDependencies=no_
           is set:
    
           •   Slice units will automatically have dependencies of type
               _Conflicts=_ and _Before=_ on shutdown.target. These ensure that
               slice units are removed prior to system shutdown. Only slice
               units involved with late system shutdown should disable
               _DefaultDependencies=_ option.
    


## OPTIONS



           Slice unit files may include [Unit] and [Install] sections, which
           are described in systemd.unit(5).
    
           Slice files may include a [Slice] section. Many options that may
           be used in this section are shared with other unit types. These
           options are documented in systemd.resource-control(5).
    
           The options specific to the [Slice] section of slice units are the
           following:
    
           _ConcurrencyHardMax=_ , _ConcurrencySoftMax=_
               Configures a hard and a soft limit on the maximum number of
               units assigned to this slice (or any descendent slices) that
               may be active at the same time. If the hard limit is reached
               no further units associated with the slice may be activated,
               and their activation will fail with an error. If the soft
               limit is reached any further requested activation of units
               will be queued, but no immediate error is generated. The
               queued activation job will remain queued until the number of
               concurrent active units within the slice is below the limit
               again.
    
               If the special value "infinity" is specified, no concurrency
               limit is enforced. This is the default.
    
               Note that if multiple start jobs are queued for units, and all
               their dependencies are fulfilled they'll be processed in an
               order that is dependent on the unit type, the CPU weight (for
               unit types that know the concept, such as services), the nice
               level (similar), and finally in alphabetical order by the unit
               name. This may be used to influence dispatching order when
               using _ConcurrencySoftMax=_ to pace concurrency within a slice
               unit.
    
               Note that these options have a hierarchial effect: a limit set
               for a slice unit will apply to both the units immediately
               within the slice, but also all units further down the slice
               tree. Also note that each sub-slice unit counts as one unit
               each too, and thus when choosing a limit for a slice hierarchy
               the limit must provide room for both the payload units (i.e.
               services, mounts, ...) and structural units (i.e. slice
               units), if any are defined.
    
               Added in version 258.
    


## NOTES



            1. New Control Group Interfaces
               https://systemd.io/CONTROL_GROUP_INTERFACE
    


* * *