app.js

angular.module('systemdgen', ['ngMaterial'])
    .controller('main', ['$scope', '$mdConstant', '$mdDialog', function ($scope, $mdConstant, $mdDialog) {

        $scope.keys = [$mdConstant.KEY_CODE.ENTER, $mdConstant.KEY_CODE.COMMA];


        $scope.docs = {
            unit: {
                "Description": "<p>A human readable name for the unit. This is used by\n        <span class=\"command\"><strong>systemd</strong></span> (and other UIs) as the label for the unit, so this string should\n        identify the unit rather than describe it, despite the name. \"<code class=\"literal\">Apache2 Web\n        Server</code>\" is a good example. Bad examples are \"<code class=\"literal\">high-performance light-weight\n        HTTP server</code>\" (too generic) or \"<code class=\"literal\">Apache2</code>\" (too specific and\n        meaningless for people who do not know Apache). <span class=\"command\"><strong>systemd</strong></span> will use this\n        string as a noun in status messages (\"<code class=\"literal\">Starting\n        <em class=\"replaceable\"><code>description</code></em>...</code>\", \"<code class=\"literal\">Started\n        <em class=\"replaceable\"><code>description</code></em>.</code>\", \"<code class=\"literal\">Reached target\n        <em class=\"replaceable\"><code>description</code></em>.</code>\", \"<code class=\"literal\">Failed to start\n        <em class=\"replaceable\"><code>description</code></em>.</code>\"), so it should be capitalized, and should\n        not be a full sentence or a phrase with a continuous verb. Bad examples include\n        \"<code class=\"literal\">exiting the container</code>\" or \"<code class=\"literal\">updating the database once per\n        day.</code>\".</p>",
                "Documentation": "<p>A space-separated list of URIs referencing\n        documentation for this unit or its configuration. Accepted are\n        only URIs of the types \"<code class=\"literal\">http://</code>\",\n        \"<code class=\"literal\">https://</code>\", \"<code class=\"literal\">file:</code>\",\n        \"<code class=\"literal\">info:</code>\", \"<code class=\"literal\">man:</code>\". For more\n        information about the syntax of these URIs, see <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/uri.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">uri</span>(7)</span></a>.\n        The URIs should be listed in order of relevance, starting with\n        the most relevant. It is a good idea to first reference\n        documentation that explains what the unit's purpose is,\n        followed by how it is configured, followed by any other\n        related documentation. This option may be specified more than\n        once, in which case the specified list of URIs is merged. If\n        the empty string is assigned to this option, the list is reset\n        and all prior assignments will have no\n        effect.</p>",
                "Wants": "<p>Configures requirement dependencies on other units. This option may be specified more\n        than once or multiple space-separated units may be specified in one option in which case dependencies\n        for all listed names will be created. Dependencies of this type may also be configured outside of the\n        unit configuration file by adding a symlink to a <code class=\"filename\">.wants/</code> directory accompanying\n        the unit file. For details, see above.</p><p>Units listed in this option will be started if the configuring unit is. However, if the listed\n        units fail to start or cannot be added to the transaction, this has no impact on the validity of the\n        transaction as a whole, and this unit will still be started. This is the recommended way to hook\n        the start-up of one unit to the start-up of another unit.</p><p>Note that requirement dependencies do not influence the order in which services are started or\n        stopped. This has to be configured independently with the <code class=\"varname\">After=</code> or\n        <code class=\"varname\">Before=</code> options. If unit <code class=\"filename\">foo.service</code> pulls in unit\n        <code class=\"filename\">bar.service</code> as configured with <code class=\"varname\">Wants=</code> and no ordering is\n        configured with <code class=\"varname\">After=</code> or <code class=\"varname\">Before=</code>, then both units will be\n        started simultaneously and without any delay between them if <code class=\"filename\">foo.service</code> is\n        activated.</p>",
                "Requires": "<p>Similar to <code class=\"varname\">Wants=</code>, but declares a stronger\n        dependency. Dependencies of this type may also be configured by adding a symlink to a\n        <code class=\"filename\">.requires/</code> directory accompanying the unit file.</p><p>If this unit gets activated, the units listed will be activated as well. If one of\n        the other units fails to activate, and an ordering dependency <code class=\"varname\">After=</code> on the\n        failing unit is set, this unit will not be started. Besides, with or without specifying\n        <code class=\"varname\">After=</code>, this unit will be stopped if one of the other units is explicitly\n        stopped.</p><p>Often, it is a better choice to use <code class=\"varname\">Wants=</code> instead of\n        <code class=\"varname\">Requires=</code> in order to achieve a system that is more robust when dealing with\n        failing services.</p><p>Note that this dependency type does not imply that the other unit always has to be in active state when\n        this unit is running. Specifically: failing condition checks (such as <code class=\"varname\">ConditionPathExists=</code>,\n        <code class=\"varname\">ConditionPathIsSymbolicLink=</code>, … — see below) do not cause the start job of a unit with a\n        <code class=\"varname\">Requires=</code> dependency on it to fail. Also, some unit types may deactivate on their own (for\n        example, a service process may decide to exit cleanly, or a device may be unplugged by the user), which is not\n        propagated to units having a <code class=\"varname\">Requires=</code> dependency. Use the <code class=\"varname\">BindsTo=</code>\n        dependency type together with <code class=\"varname\">After=</code> to ensure that a unit may never be in active state\n        without a specific other unit also in active state (see below).</p>",
                "Requisite": "<p>Similar to <code class=\"varname\">Requires=</code>. However, if the units listed here\n        are not started already, they will not be started and the starting of this unit will fail\n        immediately. <code class=\"varname\">Requisite=</code> does not imply an ordering dependency, even if\n        both units are started in the same transaction. Hence this setting should usually be\n        combined with <code class=\"varname\">After=</code>, to ensure this unit is not started before the other\n        unit.</p><p>When <code class=\"varname\">Requisite=b.service</code> is used on\n        <code class=\"filename\">a.service</code>, this dependency will show as\n        <code class=\"varname\">RequisiteOf=a.service</code> in property listing of\n        <code class=\"filename\">b.service</code>. <code class=\"varname\">RequisiteOf=</code>\n        dependency cannot be specified directly.</p>",
                "BindsTo": "<p>Configures requirement dependencies, very similar in style to\n        <code class=\"varname\">Requires=</code>. However, this dependency type is stronger: in addition to the effect of\n        <code class=\"varname\">Requires=</code> it declares that if the unit bound to is stopped, this unit will be stopped\n        too. This means a unit bound to another unit that suddenly enters inactive state will be stopped too.\n        Units can suddenly, unexpectedly enter inactive state for different reasons: the main process of a service unit\n        might terminate on its own choice, the backing device of a device unit might be unplugged or the mount point of\n        a mount unit might be unmounted without involvement of the system and service manager.</p><p>When used in conjunction with <code class=\"varname\">After=</code> on the same unit the behaviour of\n        <code class=\"varname\">BindsTo=</code> is even stronger. In this case, the unit bound to strictly has to be in active\n        state for this unit to also be in active state. This not only means a unit bound to another unit that suddenly\n        enters inactive state, but also one that is bound to another unit that gets skipped due to a failed condition\n        check (such as <code class=\"varname\">ConditionPathExists=</code>, <code class=\"varname\">ConditionPathIsSymbolicLink=</code>, … —\n        see below) will be stopped, should it be running. Hence, in many cases it is best to combine\n        <code class=\"varname\">BindsTo=</code> with <code class=\"varname\">After=</code>.</p><p>When <code class=\"varname\">BindsTo=b.service</code> is used on\n        <code class=\"filename\">a.service</code>, this dependency will show as\n        <code class=\"varname\">BoundBy=a.service</code> in property listing of\n        <code class=\"filename\">b.service</code>. <code class=\"varname\">BoundBy=</code>\n        dependency cannot be specified directly.</p>",
                "PartOf": "<p>Configures dependencies similar to\n        <code class=\"varname\">Requires=</code>, but limited to stopping and\n        restarting of units. When systemd stops or restarts the units\n        listed here, the action is propagated to this unit. Note that\n        this is a one-way dependency&nbsp;— changes to this unit do not\n        affect the listed units.</p><p>When <code class=\"varname\">PartOf=b.service</code> is used on\n        <code class=\"filename\">a.service</code>, this dependency will show as\n        <code class=\"varname\">ConsistsOf=a.service</code> in property listing of\n        <code class=\"filename\">b.service</code>. <code class=\"varname\">ConsistsOf=</code>\n        dependency cannot be specified directly.</p>",
                "Conflicts": "<p>A space-separated list of unit names. Configures negative requirement\n        dependencies. If a unit has a <code class=\"varname\">Conflicts=</code> setting on another unit, starting the\n        former will stop the latter and vice versa.</p><p>Note that this setting does not imply an ordering dependency, similarly to the\n        <code class=\"varname\">Wants=</code> and <code class=\"varname\">Requires=</code> dependencies described above. This means\n        that to ensure that the conflicting unit is stopped before the other unit is started, an\n        <code class=\"varname\">After=</code> or <code class=\"varname\">Before=</code> dependency must be declared. It doesn't\n        matter which of the two ordering dependencies is used, because stop jobs are always ordered before\n        start jobs, see the discussion in <code class=\"varname\">Before=</code>/<code class=\"varname\">After=</code> below.</p><p>If unit A that conflicts with unit B is scheduled to\n        be started at the same time as B, the transaction will either\n        fail (in case both are required parts of the transaction) or be\n        modified to be fixed (in case one or both jobs are not a\n        required part of the transaction). In the latter case, the job\n        that is not required will be removed, or in case both are\n        not required, the unit that conflicts will be started and the\n        unit that is conflicted is stopped.</p>",
                "Before": "<p>These two settings expect a space-separated list of unit names. They may be specified\n        more than once, in which case dependencies for all listed names are created.</p><p>Those two settings configure ordering dependencies between units. If unit\n        <code class=\"filename\">foo.service</code> contains the setting <code class=\"option\">Before=bar.service</code> and both\n        units are being started, <code class=\"filename\">bar.service</code>'s start-up is delayed until\n        <code class=\"filename\">foo.service</code> has finished starting up. <code class=\"varname\">After=</code> is the inverse\n        of <code class=\"varname\">Before=</code>, i.e. while <code class=\"varname\">Before=</code> ensures that the configured unit\n        is started before the listed unit begins starting up, <code class=\"varname\">After=</code> ensures the opposite,\n        that the listed unit is fully started up before the configured unit is started.</p><p>When two units with an ordering dependency between them are shut down, the inverse of the\n        start-up order is applied. I.e. if a unit is configured with <code class=\"varname\">After=</code> on another\n        unit, the former is stopped before the latter if both are shut down. Given two units with any\n        ordering dependency between them, if one unit is shut down and the other is started up, the shutdown\n        is ordered before the start-up. It doesn't matter if the ordering dependency is\n        <code class=\"varname\">After=</code> or <code class=\"varname\">Before=</code>, in this case. It also doesn't matter which\n        of the two is shut down, as long as one is shut down and the other is started up; the shutdown is\n        ordered before the start-up in all cases. If two units have no ordering dependencies between them,\n        they are shut down or started up simultaneously, and no ordering takes place. It depends on the unit\n        type when precisely a unit has finished starting up. Most importantly, for service units start-up is\n        considered completed for the purpose of <code class=\"varname\">Before=</code>/<code class=\"varname\">After=</code> when all\n        its configured start-up commands have been invoked and they either failed or reported start-up\n        success. Note that this does includes <code class=\"varname\">ExecStartPost=</code> (or\n        <code class=\"varname\">ExecStopPost=</code> for the shutdown case).</p><p>Note that those settings are independent of and orthogonal to the requirement dependencies as\n        configured by <code class=\"varname\">Requires=</code>, <code class=\"varname\">Wants=</code>, <code class=\"varname\">Requisite=</code>,\n        or <code class=\"varname\">BindsTo=</code>. It is a common pattern to include a unit name in both the\n        <code class=\"varname\">After=</code> and <code class=\"varname\">Wants=</code> options, in which case the unit listed will\n        be started before the unit that is configured with these options.</p><p>Note that <code class=\"varname\">Before=</code> dependencies on device units have no effect and are not\n        supported.  Devices generally become available as a result of an external hotplug event, and systemd\n        creates the corresponding device unit without delay.</p>",
                "After": "<p>These two settings expect a space-separated list of unit names. They may be specified\n        more than once, in which case dependencies for all listed names are created.</p><p>Those two settings configure ordering dependencies between units. If unit\n        <code class=\"filename\">foo.service</code> contains the setting <code class=\"option\">Before=bar.service</code> and both\n        units are being started, <code class=\"filename\">bar.service</code>'s start-up is delayed until\n        <code class=\"filename\">foo.service</code> has finished starting up. <code class=\"varname\">After=</code> is the inverse\n        of <code class=\"varname\">Before=</code>, i.e. while <code class=\"varname\">Before=</code> ensures that the configured unit\n        is started before the listed unit begins starting up, <code class=\"varname\">After=</code> ensures the opposite,\n        that the listed unit is fully started up before the configured unit is started.</p><p>When two units with an ordering dependency between them are shut down, the inverse of the\n        start-up order is applied. I.e. if a unit is configured with <code class=\"varname\">After=</code> on another\n        unit, the former is stopped before the latter if both are shut down. Given two units with any\n        ordering dependency between them, if one unit is shut down and the other is started up, the shutdown\n        is ordered before the start-up. It doesn't matter if the ordering dependency is\n        <code class=\"varname\">After=</code> or <code class=\"varname\">Before=</code>, in this case. It also doesn't matter which\n        of the two is shut down, as long as one is shut down and the other is started up; the shutdown is\n        ordered before the start-up in all cases. If two units have no ordering dependencies between them,\n        they are shut down or started up simultaneously, and no ordering takes place. It depends on the unit\n        type when precisely a unit has finished starting up. Most importantly, for service units start-up is\n        considered completed for the purpose of <code class=\"varname\">Before=</code>/<code class=\"varname\">After=</code> when all\n        its configured start-up commands have been invoked and they either failed or reported start-up\n        success. Note that this does includes <code class=\"varname\">ExecStartPost=</code> (or\n        <code class=\"varname\">ExecStopPost=</code> for the shutdown case).</p><p>Note that those settings are independent of and orthogonal to the requirement dependencies as\n        configured by <code class=\"varname\">Requires=</code>, <code class=\"varname\">Wants=</code>, <code class=\"varname\">Requisite=</code>,\n        or <code class=\"varname\">BindsTo=</code>. It is a common pattern to include a unit name in both the\n        <code class=\"varname\">After=</code> and <code class=\"varname\">Wants=</code> options, in which case the unit listed will\n        be started before the unit that is configured with these options.</p><p>Note that <code class=\"varname\">Before=</code> dependencies on device units have no effect and are not\n        supported.  Devices generally become available as a result of an external hotplug event, and systemd\n        creates the corresponding device unit without delay.</p>",
                "OnFailure": "<p>A space-separated list of one or more units\n        that are activated when this unit enters the\n        \"<code class=\"literal\">failed</code>\" state.  A service unit using\n        <code class=\"varname\">Restart=</code> enters the failed state only after\n        the start limits are reached.</p>",
                "PropagatesReloadTo": "<p>A space-separated list of one or more units\n        where reload requests on this unit will be propagated to, or\n        reload requests on the other unit will be propagated to this\n        unit, respectively. Issuing a reload request on a unit will\n        automatically also enqueue a reload request on all units that\n        the reload request shall be propagated to via these two\n        settings.</p>",
                "ReloadPropagatedFrom": "<p>A space-separated list of one or more units\n        where reload requests on this unit will be propagated to, or\n        reload requests on the other unit will be propagated to this\n        unit, respectively. Issuing a reload request on a unit will\n        automatically also enqueue a reload request on all units that\n        the reload request shall be propagated to via these two\n        settings.</p>",
                "JoinsNamespaceOf": "<p>For units that start processes (such as service units), lists one or more other units\n        whose network and/or temporary file namespace to join. This only applies to unit types which support\n        the <code class=\"varname\">PrivateNetwork=</code>, <code class=\"varname\">NetworkNamespacePath=</code> and\n        <code class=\"varname\">PrivateTmp=</code> directives (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.exec.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.exec</span>(5)</span></a> for\n        details). If a unit that has this setting set is started, its processes will see the same\n        <code class=\"filename\">/tmp</code>, <code class=\"filename\">/var/tmp</code> and network namespace as one listed unit\n        that is started. If multiple listed units are already started, it is not defined which namespace is\n        joined.  Note that this setting only has an effect if\n        <code class=\"varname\">PrivateNetwork=</code>/<code class=\"varname\">NetworkNamespacePath=</code> and/or\n        <code class=\"varname\">PrivateTmp=</code> is enabled for both the unit that joins the namespace and the unit\n        whose namespace is joined.</p>",
                "RequiresMountsFor": "<p>Takes a space-separated list of absolute\n        paths. Automatically adds dependencies of type\n        <code class=\"varname\">Requires=</code> and <code class=\"varname\">After=</code> for\n        all mount units required to access the specified path.</p><p>Mount points marked with <code class=\"option\">noauto</code> are not\n        mounted automatically through <code class=\"filename\">local-fs.target</code>,\n        but are still honored for the purposes of this option, i.e. they\n        will be pulled in by this unit.</p>",
                "OnFailureJobMode": "<p>Takes a value of\n        \"<code class=\"literal\">fail</code>\",\n        \"<code class=\"literal\">replace</code>\",\n        \"<code class=\"literal\">replace-irreversibly</code>\",\n        \"<code class=\"literal\">isolate</code>\",\n        \"<code class=\"literal\">flush</code>\",\n        \"<code class=\"literal\">ignore-dependencies</code>\" or\n        \"<code class=\"literal\">ignore-requirements</code>\". Defaults to\n        \"<code class=\"literal\">replace</code>\". Specifies how the units listed in\n        <code class=\"varname\">OnFailure=</code> will be enqueued. See\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemctl.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemctl</span>(1)</span></a>'s\n        <code class=\"option\">--job-mode=</code> option for details on the\n        possible values. If this is set to \"<code class=\"literal\">isolate</code>\",\n        only a single unit may be listed in\n        <code class=\"varname\">OnFailure=</code>.</p>",
                "IgnoreOnIsolate": "<p>Takes a boolean argument. If <code class=\"option\">true</code>, this unit\n        will not be stopped when isolating another unit. Defaults to\n        <code class=\"option\">false</code> for service, target, socket, busname, timer, and path\n        units, and <code class=\"option\">true</code> for slice, scope, device, swap, mount, and\n        automount units.</p>",
                "StopWhenUnneeded": "<p>Takes a boolean argument. If\n        <code class=\"option\">true</code>, this unit will be stopped when it is no\n        longer used. Note that, in order to minimize the work to be\n        executed, systemd will not stop units by default unless they\n        are conflicting with other units, or the user explicitly\n        requested their shut down. If this option is set, a unit will\n        be automatically cleaned up if no other active unit requires\n        it. Defaults to <code class=\"option\">false</code>.</p>",
                "RefuseManualStart": "<p>Takes a boolean argument. If\n        <code class=\"option\">true</code>, this unit can only be activated or\n        deactivated indirectly. In this case, explicit start-up or\n        termination requested by the user is denied, however if it is\n        started or stopped as a dependency of another unit, start-up\n        or termination will succeed. This is mostly a safety feature\n        to ensure that the user does not accidentally activate units\n        that are not intended to be activated explicitly, and not\n        accidentally deactivate units that are not intended to be\n        deactivated. These options default to\n        <code class=\"option\">false</code>.</p>",
                "RefuseManualStop": "<p>Takes a boolean argument. If\n        <code class=\"option\">true</code>, this unit can only be activated or\n        deactivated indirectly. In this case, explicit start-up or\n        termination requested by the user is denied, however if it is\n        started or stopped as a dependency of another unit, start-up\n        or termination will succeed. This is mostly a safety feature\n        to ensure that the user does not accidentally activate units\n        that are not intended to be activated explicitly, and not\n        accidentally deactivate units that are not intended to be\n        deactivated. These options default to\n        <code class=\"option\">false</code>.</p>",
                "AllowIsolate": "<p>Takes a boolean argument. If\n        <code class=\"option\">true</code>, this unit may be used with the\n        <span class=\"command\"><strong>systemctl isolate</strong></span> command. Otherwise, this\n        will be refused. It probably is a good idea to leave this\n        disabled except for target units that shall be used similar to\n        runlevels in SysV init systems, just as a precaution to avoid\n        unusable system states. This option defaults to\n        <code class=\"option\">false</code>.</p>",
                "DefaultDependencies": "<p>Takes a boolean argument. If\n        <code class=\"option\">yes</code>, (the default), a few default\n        dependencies will implicitly be created for the unit. The\n        actual dependencies created depend on the unit type. For\n        example, for service units, these dependencies ensure that the\n        service is started only after basic system initialization is\n        completed and is properly terminated on system shutdown. See\n        the respective man pages for details. Generally, only services\n        involved with early boot or late shutdown should set this\n        option to <code class=\"option\">no</code>. It is highly recommended to\n        leave this option enabled for the majority of common units. If\n        set to <code class=\"option\">no</code>, this option does not disable\n        all implicit dependencies, just non-essential\n        ones.</p>",
                "CollectMode": "<p>Tweaks the \"garbage collection\" algorithm for this unit. Takes one of <code class=\"option\">inactive</code>\n        or <code class=\"option\">inactive-or-failed</code>. If set to <code class=\"option\">inactive</code> the unit will be unloaded if it is\n        in the <code class=\"constant\">inactive</code> state and is not referenced by clients, jobs or other units — however it\n        is not unloaded if it is in the <code class=\"constant\">failed</code> state. In <code class=\"option\">failed</code> mode, failed\n        units are not unloaded until the user invoked <span class=\"command\"><strong>systemctl reset-failed</strong></span> on them to reset the\n        <code class=\"constant\">failed</code> state, or an equivalent command. This behaviour is altered if this option is set to\n        <code class=\"option\">inactive-or-failed</code>: in this case the unit is unloaded even if the unit is in a\n        <code class=\"constant\">failed</code> state, and thus an explicitly resetting of the <code class=\"constant\">failed</code> state is\n        not necessary. Note that if this mode is used unit results (such as exit codes, exit signals, consumed\n        resources, …) are flushed out immediately after the unit completed, except for what is stored in the logging\n        subsystem. Defaults to <code class=\"option\">inactive</code>.</p>",
                "FailureAction": "<p>Configure the action to take when the unit stops and enters a failed state or inactive state.\n        Takes one of <code class=\"option\">none</code>, <code class=\"option\">reboot</code>, <code class=\"option\">reboot-force</code>,\n        <code class=\"option\">reboot-immediate</code>, <code class=\"option\">poweroff</code>, <code class=\"option\">poweroff-force</code>,\n        <code class=\"option\">poweroff-immediate</code>, <code class=\"option\">exit</code>, and <code class=\"option\">exit-force</code>. In system mode,\n        all options are allowed. In user mode, only <code class=\"option\">none</code>, <code class=\"option\">exit</code>, and\n        <code class=\"option\">exit-force</code> are allowed. Both options default to <code class=\"option\">none</code>.</p><p>If <code class=\"option\">none</code> is set, no action will be triggered. <code class=\"option\">reboot</code> causes a reboot\n        following the normal shutdown procedure (i.e. equivalent to <span class=\"command\"><strong>systemctl reboot</strong></span>).\n        <code class=\"option\">reboot-force</code> causes a forced reboot which will terminate all processes forcibly but should\n        cause no dirty file systems on reboot (i.e. equivalent to <span class=\"command\"><strong>systemctl reboot -f</strong></span>) and\n        <code class=\"option\">reboot-immediate</code> causes immediate execution of the\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/reboot.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">reboot</span>(2)</span></a> system call, which\n        might result in data loss (i.e. equivalent to <span class=\"command\"><strong>systemctl reboot -ff</strong></span>). Similarly,\n        <code class=\"option\">poweroff</code>, <code class=\"option\">poweroff-force</code>, <code class=\"option\">poweroff-immediate</code> have the effect\n        of powering down the system with similar semantics. <code class=\"option\">exit</code> causes the manager to exit following\n        the normal shutdown procedure, and <code class=\"option\">exit-force</code> causes it terminate without shutting down\n        services. When <code class=\"option\">exit</code> or <code class=\"option\">exit-force</code> is used by default the exit status of the\n        main process of the unit (if this applies) is returned from the service manager. However, this may be overridden\n        with <code class=\"varname\">FailureActionExitStatus=</code>/<code class=\"varname\">SuccessActionExitStatus=</code>, see\n        below.</p>",
                "SuccessAction": "<p>Configure the action to take when the unit stops and enters a failed state or inactive state.\n        Takes one of <code class=\"option\">none</code>, <code class=\"option\">reboot</code>, <code class=\"option\">reboot-force</code>,\n        <code class=\"option\">reboot-immediate</code>, <code class=\"option\">poweroff</code>, <code class=\"option\">poweroff-force</code>,\n        <code class=\"option\">poweroff-immediate</code>, <code class=\"option\">exit</code>, and <code class=\"option\">exit-force</code>. In system mode,\n        all options are allowed. In user mode, only <code class=\"option\">none</code>, <code class=\"option\">exit</code>, and\n        <code class=\"option\">exit-force</code> are allowed. Both options default to <code class=\"option\">none</code>.</p><p>If <code class=\"option\">none</code> is set, no action will be triggered. <code class=\"option\">reboot</code> causes a reboot\n        following the normal shutdown procedure (i.e. equivalent to <span class=\"command\"><strong>systemctl reboot</strong></span>).\n        <code class=\"option\">reboot-force</code> causes a forced reboot which will terminate all processes forcibly but should\n        cause no dirty file systems on reboot (i.e. equivalent to <span class=\"command\"><strong>systemctl reboot -f</strong></span>) and\n        <code class=\"option\">reboot-immediate</code> causes immediate execution of the\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/reboot.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">reboot</span>(2)</span></a> system call, which\n        might result in data loss (i.e. equivalent to <span class=\"command\"><strong>systemctl reboot -ff</strong></span>). Similarly,\n        <code class=\"option\">poweroff</code>, <code class=\"option\">poweroff-force</code>, <code class=\"option\">poweroff-immediate</code> have the effect\n        of powering down the system with similar semantics. <code class=\"option\">exit</code> causes the manager to exit following\n        the normal shutdown procedure, and <code class=\"option\">exit-force</code> causes it terminate without shutting down\n        services. When <code class=\"option\">exit</code> or <code class=\"option\">exit-force</code> is used by default the exit status of the\n        main process of the unit (if this applies) is returned from the service manager. However, this may be overridden\n        with <code class=\"varname\">FailureActionExitStatus=</code>/<code class=\"varname\">SuccessActionExitStatus=</code>, see\n        below.</p>",
                "FailureActionExitStatus": "<p>Controls the exit status to propagate back to an invoking container manager (in case of a\n        system service) or service manager (in case of a user manager) when the\n        <code class=\"varname\">FailureAction=</code>/<code class=\"varname\">SuccessAction=</code> are set to <code class=\"option\">exit</code> or\n        <code class=\"option\">exit-force</code> and the action is triggered. By default the exit status of the main process of the\n        triggering unit (if this applies) is propagated. Takes a value in the range 0…255 or the empty string to\n        request default behaviour.</p>",
                "SuccessActionExitStatus": "<p>Controls the exit status to propagate back to an invoking container manager (in case of a\n        system service) or service manager (in case of a user manager) when the\n        <code class=\"varname\">FailureAction=</code>/<code class=\"varname\">SuccessAction=</code> are set to <code class=\"option\">exit</code> or\n        <code class=\"option\">exit-force</code> and the action is triggered. By default the exit status of the main process of the\n        triggering unit (if this applies) is propagated. Takes a value in the range 0…255 or the empty string to\n        request default behaviour.</p>",
                "JobTimeoutSec": "<p>When a job for this unit is queued, a timeout <code class=\"varname\">JobTimeoutSec=</code> may be\n        configured. Similarly, <code class=\"varname\">JobRunningTimeoutSec=</code> starts counting when the queued job is actually\n        started. If either time limit is reached, the job will be cancelled, the unit however will not change state or\n        even enter the \"<code class=\"literal\">failed</code>\" mode. This value defaults to \"<code class=\"literal\">infinity</code>\" (job timeouts\n        disabled), except for device units (<code class=\"varname\">JobRunningTimeoutSec=</code> defaults to\n        <code class=\"varname\">DefaultTimeoutStartSec=</code>). NB: this timeout is independent from any unit-specific timeout\n        (for example, the timeout set with <code class=\"varname\">TimeoutStartSec=</code> in service units) as the job timeout has\n        no effect on the unit itself, only on the job that might be pending for it. Or in other words: unit-specific\n        timeouts are useful to abort unit state changes, and revert them. The job timeout set with this option however\n        is useful to abort only the job waiting for the unit state to change.</p>",
                "JobRunningTimeoutSec": "<p>When a job for this unit is queued, a timeout <code class=\"varname\">JobTimeoutSec=</code> may be\n        configured. Similarly, <code class=\"varname\">JobRunningTimeoutSec=</code> starts counting when the queued job is actually\n        started. If either time limit is reached, the job will be cancelled, the unit however will not change state or\n        even enter the \"<code class=\"literal\">failed</code>\" mode. This value defaults to \"<code class=\"literal\">infinity</code>\" (job timeouts\n        disabled), except for device units (<code class=\"varname\">JobRunningTimeoutSec=</code> defaults to\n        <code class=\"varname\">DefaultTimeoutStartSec=</code>). NB: this timeout is independent from any unit-specific timeout\n        (for example, the timeout set with <code class=\"varname\">TimeoutStartSec=</code> in service units) as the job timeout has\n        no effect on the unit itself, only on the job that might be pending for it. Or in other words: unit-specific\n        timeouts are useful to abort unit state changes, and revert them. The job timeout set with this option however\n        is useful to abort only the job waiting for the unit state to change.</p>",
                "JobTimeoutAction": "<p><code class=\"varname\">JobTimeoutAction=</code> optionally configures an additional action to take when\n        the timeout is hit, see description of <code class=\"varname\">JobTimeoutSec=</code> and\n        <code class=\"varname\">JobRunningTimeoutSec=</code> above. It takes the same values as\n        <code class=\"varname\">StartLimitAction=</code>. Defaults to <code class=\"option\">none</code>.\n        <code class=\"varname\">JobTimeoutRebootArgument=</code> configures an optional reboot string to pass to the\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/reboot.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">reboot</span>(2)</span></a> system call.\n        </p>",
                "JobTimeoutRebootArgument": "<p><code class=\"varname\">JobTimeoutAction=</code> optionally configures an additional action to take when\n        the timeout is hit, see description of <code class=\"varname\">JobTimeoutSec=</code> and\n        <code class=\"varname\">JobRunningTimeoutSec=</code> above. It takes the same values as\n        <code class=\"varname\">StartLimitAction=</code>. Defaults to <code class=\"option\">none</code>.\n        <code class=\"varname\">JobTimeoutRebootArgument=</code> configures an optional reboot string to pass to the\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/reboot.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">reboot</span>(2)</span></a> system call.\n        </p>",
                "StartLimitIntervalSecinterval": "<p>Configure unit start rate limiting. Units which are started more than\n        <em class=\"replaceable\"><code>burst</code></em> times within an <em class=\"replaceable\"><code>interval</code></em> time interval are not\n        permitted to start any more. Use <code class=\"varname\">StartLimitIntervalSec=</code> to configure the checking interval\n        (defaults to <code class=\"varname\">DefaultStartLimitIntervalSec=</code> in manager configuration file, set it to 0 to\n        disable any kind of rate limiting). Use <code class=\"varname\">StartLimitBurst=</code> to configure how many starts per\n        interval are allowed (defaults to <code class=\"varname\">DefaultStartLimitBurst=</code> in manager configuration\n        file). These configuration options are particularly useful in conjunction with the service setting\n        <code class=\"varname\">Restart=</code> (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.service.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.service</span>(5)</span></a>); however,\n        they apply to all kinds of starts (including manual), not just those triggered by the\n        <code class=\"varname\">Restart=</code> logic. Note that units which are configured for <code class=\"varname\">Restart=</code> and\n        which reach the start limit are not attempted to be restarted anymore; however, they may still be restarted\n        manually at a later point, after the <em class=\"replaceable\"><code>interval</code></em> has passed.  From this point on, the\n        restart logic is activated again. Note that <span class=\"command\"><strong>systemctl reset-failed</strong></span> will cause the restart\n        rate counter for a service to be flushed, which is useful if the administrator wants to manually start a unit\n        and the start limit interferes with that. Note that this rate-limiting is enforced after any unit condition\n        checks are executed, and hence unit activations with failing conditions do not count towards this rate\n        limit. This setting does not apply to slice, target, device, and scope units, since they are unit types whose\n        activation may either never fail, or may succeed only a single time.</p><p>When a unit is unloaded due to the garbage collection logic (see above) its rate limit counters are\n        flushed out too. This means that configuring start rate limiting for a unit that is not referenced continuously\n        has no effect.</p>",
                "StartLimitBurst": "<p>Configure unit start rate limiting. Units which are started more than\n        <em class=\"replaceable\"><code>burst</code></em> times within an <em class=\"replaceable\"><code>interval</code></em> time interval are not\n        permitted to start any more. Use <code class=\"varname\">StartLimitIntervalSec=</code> to configure the checking interval\n        (defaults to <code class=\"varname\">DefaultStartLimitIntervalSec=</code> in manager configuration file, set it to 0 to\n        disable any kind of rate limiting). Use <code class=\"varname\">StartLimitBurst=</code> to configure how many starts per\n        interval are allowed (defaults to <code class=\"varname\">DefaultStartLimitBurst=</code> in manager configuration\n        file). These configuration options are particularly useful in conjunction with the service setting\n        <code class=\"varname\">Restart=</code> (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.service.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.service</span>(5)</span></a>); however,\n        they apply to all kinds of starts (including manual), not just those triggered by the\n        <code class=\"varname\">Restart=</code> logic. Note that units which are configured for <code class=\"varname\">Restart=</code> and\n        which reach the start limit are not attempted to be restarted anymore; however, they may still be restarted\n        manually at a later point, after the <em class=\"replaceable\"><code>interval</code></em> has passed.  From this point on, the\n        restart logic is activated again. Note that <span class=\"command\"><strong>systemctl reset-failed</strong></span> will cause the restart\n        rate counter for a service to be flushed, which is useful if the administrator wants to manually start a unit\n        and the start limit interferes with that. Note that this rate-limiting is enforced after any unit condition\n        checks are executed, and hence unit activations with failing conditions do not count towards this rate\n        limit. This setting does not apply to slice, target, device, and scope units, since they are unit types whose\n        activation may either never fail, or may succeed only a single time.</p><p>When a unit is unloaded due to the garbage collection logic (see above) its rate limit counters are\n        flushed out too. This means that configuring start rate limiting for a unit that is not referenced continuously\n        has no effect.</p>",
                "StartLimitAction": "<p>Configure an additional action to take if the rate limit configured with\n        <code class=\"varname\">StartLimitIntervalSec=</code> and <code class=\"varname\">StartLimitBurst=</code> is hit. Takes the same\n        values as the <code class=\"varname\">FailureAction=</code>/<code class=\"varname\">SuccessAction=</code> settings. If\n        <code class=\"option\">none</code> is set, hitting the rate limit will trigger no action except that\n        the start will not be permitted. Defaults to <code class=\"option\">none</code>.</p>",
                "RebootArgument": "<p>Configure the optional argument for the\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/reboot.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">reboot</span>(2)</span></a> system call if\n        <code class=\"varname\">StartLimitAction=</code> or <code class=\"varname\">FailureAction=</code> is a reboot action. This\n        works just like the optional argument to <span class=\"command\"><strong>systemctl reboot</strong></span> command.</p>",
                "SourcePath": "<p>A path to a configuration file this unit has\n        been generated from. This is primarily useful for\n        implementation of generator tools that convert configuration\n        from an external configuration file format into native unit\n        files. This functionality should not be used in normal\n        units.</p>",
                "ConditionArchitecture": "<p>Check whether the system is running on a specific architecture. Takes one of\n          \"<code class=\"literal\">x86</code>\",\n          \"<code class=\"literal\">x86-64</code>\",\n          \"<code class=\"literal\">ppc</code>\",\n          \"<code class=\"literal\">ppc-le</code>\",\n          \"<code class=\"literal\">ppc64</code>\",\n          \"<code class=\"literal\">ppc64-le</code>\",\n          \"<code class=\"literal\">ia64</code>\",\n          \"<code class=\"literal\">parisc</code>\",\n          \"<code class=\"literal\">parisc64</code>\",\n          \"<code class=\"literal\">s390</code>\",\n          \"<code class=\"literal\">s390x</code>\",\n          \"<code class=\"literal\">sparc</code>\",\n          \"<code class=\"literal\">sparc64</code>\",\n          \"<code class=\"literal\">mips</code>\",\n          \"<code class=\"literal\">mips-le</code>\",\n          \"<code class=\"literal\">mips64</code>\",\n          \"<code class=\"literal\">mips64-le</code>\",\n          \"<code class=\"literal\">alpha</code>\",\n          \"<code class=\"literal\">arm</code>\",\n          \"<code class=\"literal\">arm-be</code>\",\n          \"<code class=\"literal\">arm64</code>\",\n          \"<code class=\"literal\">arm64-be</code>\",\n          \"<code class=\"literal\">sh</code>\",\n          \"<code class=\"literal\">sh64</code>\",\n          \"<code class=\"literal\">m68k</code>\",\n          \"<code class=\"literal\">tilegx</code>\",\n          \"<code class=\"literal\">cris</code>\",\n          \"<code class=\"literal\">arc</code>\",\n          \"<code class=\"literal\">arc-be</code>\", or\n          \"<code class=\"literal\">native</code>\".</p><p>The architecture is determined from the information returned by\n          <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/uname.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">uname</span>(2)</span></a>\n          and is thus subject to\n          <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/personality.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">personality</span>(2)</span></a>.\n          Note that a <code class=\"varname\">Personality=</code> setting in the same unit file has no effect on this\n          condition. A special architecture name \"<code class=\"literal\">native</code>\" is mapped to the architecture the\n          system manager itself is compiled for. The test may be negated by prepending an exclamation\n          mark.</p>",
                "ConditionVirtualization": "<p>Check whether the system is executed in a virtualized environment and optionally\n          test whether it is a specific implementation. Takes either boolean value to check if being executed\n          in any virtualized environment, or one of\n          \"<code class=\"literal\">vm</code>\" and\n          \"<code class=\"literal\">container</code>\" to test against a generic type of virtualization solution, or one of\n          \"<code class=\"literal\">qemu</code>\",\n          \"<code class=\"literal\">kvm</code>\",\n          \"<code class=\"literal\">zvm</code>\",\n          \"<code class=\"literal\">vmware</code>\",\n          \"<code class=\"literal\">microsoft</code>\",\n          \"<code class=\"literal\">oracle</code>\",\n          \"<code class=\"literal\">xen</code>\",\n          \"<code class=\"literal\">bochs</code>\",\n          \"<code class=\"literal\">uml</code>\",\n          \"<code class=\"literal\">bhyve</code>\",\n          \"<code class=\"literal\">qnx</code>\",\n          \"<code class=\"literal\">openvz</code>\",\n          \"<code class=\"literal\">lxc</code>\",\n          \"<code class=\"literal\">lxc-libvirt</code>\",\n          \"<code class=\"literal\">systemd-nspawn</code>\",\n          \"<code class=\"literal\">docker</code>\",\n          \"<code class=\"literal\">podman</code>\",\n          \"<code class=\"literal\">rkt</code>\",\n          \"<code class=\"literal\">wsl</code>\",\n          \"<code class=\"literal\">proot</code>\",\n          \"<code class=\"literal\">acrn</code>\" to test\n          against a specific implementation, or\n          \"<code class=\"literal\">private-users</code>\" to check whether we are running in a user namespace. See\n          <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd-detect-virt.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd-detect-virt</span>(1)</span></a>\n          for a full list of known virtualization technologies and their identifiers. If multiple\n          virtualization technologies are nested, only the innermost is considered. The test may be negated\n          by prepending an exclamation mark.</p>",
                "ConditionHost": "<p><code class=\"varname\">ConditionHost=</code> may be used to match against the hostname or\n          machine ID of the host. This either takes a hostname string (optionally with shell style globs)\n          which is tested against the locally set hostname as returned by\n          <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/gethostname.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">gethostname</span>(2)</span></a>, or\n          a machine ID formatted as string (see\n          <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/machine-id.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">machine-id</span>(5)</span></a>).\n          The test may be negated by prepending an exclamation mark.</p>",
                "ConditionKernelCommandLine": "<p><code class=\"varname\">ConditionKernelCommandLine=</code> may be used to check whether a\n          specific kernel command line option is set (or if prefixed with the exclamation mark — unset). The\n          argument must either be a single word, or an assignment (i.e. two words, separated by\n          \"<code class=\"literal\">=</code>\"). In the former case the kernel command line is searched for the word\n          appearing as is, or as left hand side of an assignment. In the latter case, the exact assignment is\n          looked for with right and left hand side matching.</p>",
                "ConditionKernelVersion": "<p><code class=\"varname\">ConditionKernelVersion=</code> may be used to check whether the kernel\n          version (as reported by <span class=\"command\"><strong>uname -r</strong></span>) matches a certain expression (or if prefixed\n          with the exclamation mark does not match it). The argument must be a list of (potentially quoted)\n          expressions.  For each of the expressions, if it starts with one of \"<code class=\"literal\">&lt;</code>\",\n          \"<code class=\"literal\">&lt;=</code>\", \"<code class=\"literal\">=</code>\", \"<code class=\"literal\">!=</code>\", \"<code class=\"literal\">&gt;=</code>\",\n          \"<code class=\"literal\">&gt;</code>\" a relative version comparison is done, otherwise the specified string is\n          matched with shell-style globs.</p><p>Note that using the kernel version string is an unreliable way to determine which features\n          are supported by a kernel, because of the widespread practice of backporting drivers, features, and\n          fixes from newer upstream kernels into older versions provided by distributions. Hence, this check\n          is inherently unportable and should not be used for units which may be used on different\n          distributions.</p>",
                "ConditionEnvironment": "<p><code class=\"varname\">ConditionEnvironment=</code> may be used to check whether a specific\n          environment variable is set (or if prefixed with the exclamation mark — unset) in the service\n          manager's environment block.\n\n          The argument may be a single word, to check if the variable with this name is defined in the\n          environment block, or an assignment\n          (\"<code class=\"literal\"><em class=\"replaceable\"><code>name</code></em>=<em class=\"replaceable\"><code>value</code></em></code>\"), to check if\n          the variable with this exact value is defined. Note that the environment block of the service\n          manager itself is checked, i.e. not any variables defined with <code class=\"varname\">Environment=</code> or\n          <code class=\"varname\">EnvironmentFile=</code>, as described above. This is particularly useful when the\n          service manager runs inside a containerized environment or as per-user service manager, in order to\n          check for variables passed in by the enclosing container manager or PAM.</p>",
                "ConditionSecurity": "<p><code class=\"varname\">ConditionSecurity=</code> may be used to check whether the given\n          security technology is enabled on the system. Currently, the recognized values are\n          \"<code class=\"literal\">selinux</code>\", \"<code class=\"literal\">apparmor</code>\", \"<code class=\"literal\">tomoyo</code>\",\n          \"<code class=\"literal\">ima</code>\", \"<code class=\"literal\">smack</code>\", \"<code class=\"literal\">audit</code>\" and\n          \"<code class=\"literal\">uefi-secureboot</code>\". The test may be negated by prepending an exclamation\n          mark.</p>",
                "ConditionCapability": "<p>Check whether the given capability exists in the capability bounding set of the\n          service manager (i.e. this does not check whether capability is actually available in the permitted\n          or effective sets, see\n          <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/capabilities.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">capabilities</span>(7)</span></a>\n          for details). Pass a capability name such as \"<code class=\"literal\">CAP_MKNOD</code>\", possibly prefixed with\n          an exclamation mark to negate the check.</p>",
                "ConditionACPower": "<p>Check whether the system has AC power, or is exclusively battery powered at the\n          time of activation of the unit. This takes a boolean argument. If set to \"<code class=\"literal\">true</code>\",\n          the condition will hold only if at least one AC connector of the system is connected to a power\n          source, or if no AC connectors are known. Conversely, if set to \"<code class=\"literal\">false</code>\", the\n          condition will hold only if there is at least one AC connector known and all AC connectors are\n          disconnected from a power source.</p>",
                "ConditionNeedsUpdate": "<p>Takes one of <code class=\"filename\">/var</code> or <code class=\"filename\">/etc</code> as argument,\n          possibly prefixed with a \"<code class=\"literal\">!</code>\" (to invert the condition). This condition may be\n          used to conditionalize units on whether the specified directory requires an update because\n          <code class=\"filename\">/usr</code>'s modification time is newer than the stamp file\n          <code class=\"filename\">.updated</code> in the specified directory. This is useful to implement offline\n          updates of the vendor operating system resources in <code class=\"filename\">/usr</code> that require updating\n          of <code class=\"filename\">/etc</code> or <code class=\"filename\">/var</code> on the next following boot. Units making\n          use of this condition should order themselves before\n          <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd-update-done.service.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd-update-done.service</span>(8)</span></a>,\n          to make sure they run before the stamp file's modification time gets reset indicating a completed\n          update.</p><p>If the <code class=\"varname\">systemd.condition-needs-update=</code> option is specified on the kernel\n          command line (taking a boolean), it will override the result of this condition check, taking\n          precedence over any file modification time checks. If it is used\n          <code class=\"filename\">systemd-update-done.service</code> will not have immediate effect on any following\n          <code class=\"varname\">ConditionNeedsUpdate=</code> checks, until the system is rebooted where the kernel\n          command line option is not specified anymore.</p>",
                "ConditionFirstBoot": "<p>Takes a boolean argument. This condition may be used to conditionalize units on\n          whether the system is booting up with an unpopulated <code class=\"filename\">/etc</code> directory\n          (specifically: an <code class=\"filename\">/etc</code> with no <code class=\"filename\">/etc/machine-id</code>). This may\n          be used to populate <code class=\"filename\">/etc</code> on the first boot after factory reset, or when a new\n          system instance boots up for the first time.</p><p>If the <code class=\"varname\">systemd.condition-first-boot=</code> option is specified on the kernel\n          command line (taking a boolean), it will override the result of this condition check, taking\n          precedence over <code class=\"filename\">/etc/machine-id</code> existence checks.</p>",
                "ConditionPathExists": "<p>Check for the exists of a file. If the specified absolute path name does not exist,\n          the condition will fail. If the absolute path name passed to\n          <code class=\"varname\">ConditionPathExists=</code> is prefixed with an exclamation mark\n          (\"<code class=\"literal\">!</code>\"), the test is negated, and the unit is only started if the path does not\n          exist.</p>",
                "ConditionPathExistsGlob": "<p><code class=\"varname\">ConditionPathExistsGlob=</code> is similar to\n          <code class=\"varname\">ConditionPathExists=</code>, but checks for the existence of at least one file or\n          directory matching the specified globbing pattern.</p>",
                "ConditionPathIsDirectory": "<p><code class=\"varname\">ConditionPathIsDirectory=</code> is similar to\n          <code class=\"varname\">ConditionPathExists=</code> but verifies that a certain path exists and is a\n          directory.</p>",
                "ConditionPathIsSymbolicLink": "<p><code class=\"varname\">ConditionPathIsSymbolicLink=</code> is similar to\n          <code class=\"varname\">ConditionPathExists=</code> but verifies that a certain path exists and is a symbolic\n          link.</p>",
                "ConditionPathIsMountPoint": "<p><code class=\"varname\">ConditionPathIsMountPoint=</code> is similar to\n          <code class=\"varname\">ConditionPathExists=</code> but verifies that a certain path exists and is a mount\n          point.</p>",
                "ConditionPathIsReadWrite": "<p><code class=\"varname\">ConditionPathIsReadWrite=</code> is similar to\n          <code class=\"varname\">ConditionPathExists=</code> but verifies that the underlying file system is readable\n          and writable (i.e. not mounted read-only).</p>",
                "ConditionPathIsEncrypted": "<p><code class=\"varname\">ConditionPathIsEncrypted=</code> is similar to\n          <code class=\"varname\">ConditionPathExists=</code> but verifies that the underlying file system's backing\n          block device is encrypted using dm-crypt/LUKS. Note that this check does not cover ext4\n          per-directory encryption, and only detects block level encryption. Moreover, if the specified path\n          resides on a file system on top of a loopback block device, only encryption above the loopback device is\n          detected. It is not detected whether the file system backing the loopback block device is encrypted.</p>",
                "ConditionDirectoryNotEmpty": "<p><code class=\"varname\">ConditionDirectoryNotEmpty=</code> is similar to\n          <code class=\"varname\">ConditionPathExists=</code> but verifies that a certain path exists and is a non-empty\n          directory.</p>",
                "ConditionFileNotEmpty": "<p><code class=\"varname\">ConditionFileNotEmpty=</code> is similar to\n          <code class=\"varname\">ConditionPathExists=</code> but verifies that a certain path exists and refers to a\n          regular file with a non-zero size.</p>",
                "ConditionFileIsExecutable": "<p><code class=\"varname\">ConditionFileIsExecutable=</code> is similar to\n          <code class=\"varname\">ConditionPathExists=</code> but verifies that a certain path exists, is a regular file,\n          and marked executable.</p>",
                "ConditionUser": "<p><code class=\"varname\">ConditionUser=</code> takes a numeric \"<code class=\"literal\">UID</code>\", a UNIX\n          user name, or the special value \"<code class=\"literal\">@system</code>\". This condition may be used to check\n          whether the service manager is running as the given user. The special value\n          \"<code class=\"literal\">@system</code>\" can be used to check if the user id is within the system user\n          range. This option is not useful for system services, as the system manager exclusively runs as the\n          root user, and thus the test result is constant.</p>",
                "ConditionGroup": "<p><code class=\"varname\">ConditionGroup=</code> is similar to <code class=\"varname\">ConditionUser=</code>\n          but verifies that the service manager's real or effective group, or any of its auxiliary groups,\n          match the specified group or GID. This setting does not support the special value\n          \"<code class=\"literal\">@system</code>\".</p>",
                "ConditionControlGroupController": "<p>Verify that the given cgroup controller (eg. \"<code class=\"literal\">cpu</code>\") is available\n          for use on the system. For example, a particular controller may not be available if it was disabled\n          on the kernel command line with <code class=\"varname\">cgroup_disable=controller</code>. Multiple controllers\n          may be passed with a space separating them; in this case the condition will only pass if all listed\n          controllers are available for use. Controllers unknown to systemd are ignored. Valid controllers\n          are \"<code class=\"literal\">cpu</code>\", \"<code class=\"literal\">cpuacct</code>\", \"<code class=\"literal\">io</code>\",\n          \"<code class=\"literal\">blkio</code>\", \"<code class=\"literal\">memory</code>\", \"<code class=\"literal\">devices</code>\", and\n          \"<code class=\"literal\">pids</code>\".</p>",
                "ConditionMemory": "<p>Verify that the specified amount of system memory is available to the current\n          system. Takes a memory size in bytes as argument, optionally prefixed with a comparison operator\n          \"<code class=\"literal\">&lt;</code>\", \"<code class=\"literal\">&lt;=</code>\", \"<code class=\"literal\">=</code>\", \"<code class=\"literal\">!=</code>\",\n          \"<code class=\"literal\">&gt;=</code>\", \"<code class=\"literal\">&gt;</code>\". On bare-metal systems compares the amount of\n          physical memory in the system with the specified size, adhering to the specified comparison\n          operator. In containers compares the amount of memory assigned to the container instead.</p>",
                "ConditionCPUs": "<p>Verify that the specified number of CPUs is available to the current system. Takes\n          a number of CPUs as argument, optionally prefixed with a comparison operator\n          \"<code class=\"literal\">&lt;</code>\", \"<code class=\"literal\">&lt;=</code>\", \"<code class=\"literal\">=</code>\", \"<code class=\"literal\">!=</code>\",\n          \"<code class=\"literal\">&gt;=</code>\", \"<code class=\"literal\">&gt;</code>\". Compares the number of CPUs in the CPU affinity\n          mask configured of the service manager itself with the specified number, adhering to the specified\n          comparison operator. On physical systems the number of CPUs in the affinity mask of the service\n          manager usually matches the number of physical CPUs, but in special and virtual environments might\n          differ. In particular, in containers the affinity mask usually matches the number of CPUs assigned\n          to the container and not the physically available ones.</p>",
                "AssertArchitecture": "<p>Similar to the <code class=\"varname\">ConditionArchitecture=</code>,\n          <code class=\"varname\">ConditionVirtualization=</code>, …, condition settings described above, these settings\n          add assertion checks to the start-up of the unit. However, unlike the conditions settings, any\n          assertion setting that is not met results in failure of the start job (which means this is logged\n          loudly). Note that hitting a configured assertion does not cause the unit to enter the\n          \"<code class=\"literal\">failed</code>\" state (or in fact result in any state change of the unit), it affects\n          only the job queued for it. Use assertion expressions for units that cannot operate when specific\n          requirements are not met, and when this is something the administrator or user should look\n          into.</p>",
            },
            service: {
                "Type": "<p>Configures the process start-up type for this service unit. One of <code class=\"option\">simple</code>,\n          <code class=\"option\">exec</code>, <code class=\"option\">forking</code>, <code class=\"option\">oneshot</code>, <code class=\"option\">dbus</code>,\n          <code class=\"option\">notify</code> or <code class=\"option\">idle</code>:</p><div class=\"itemizedlist\"><ul class=\"itemizedlist\" style=\"list-style-type: disc; \"><li class=\"listitem\"><p>If set to <code class=\"option\">simple</code> (the default if <code class=\"varname\">ExecStart=</code> is\n            specified but neither <code class=\"varname\">Type=</code> nor <code class=\"varname\">BusName=</code> are), the service manager\n            will consider the unit started immediately after the main service process has been forked off. It is\n            expected that the process configured with <code class=\"varname\">ExecStart=</code> is the main process of the\n            service. In this mode, if the process offers functionality to other processes on the system, its\n            communication channels should be installed before the service is started up (e.g.  sockets set up by\n            systemd, via socket activation), as the service manager will immediately proceed starting follow-up units,\n            right after creating the main service process, and before executing the service's binary. Note that this\n            means <span class=\"command\"><strong>systemctl start</strong></span> command lines for <code class=\"option\">simple</code> services will report\n            success even if the service's binary cannot be invoked successfully (for example because the selected\n            <code class=\"varname\">User=</code> doesn't exist, or the service binary is missing).</p></li><li class=\"listitem\"><p>The <code class=\"option\">exec</code> type is similar to <code class=\"option\">simple</code>, but the service\n            manager will consider the unit started immediately after the main service binary has been executed. The service\n            manager will delay starting of follow-up units until that point. (Or in other words:\n            <code class=\"option\">simple</code> proceeds with further jobs right after <code class=\"function\">fork()</code> returns, while\n            <code class=\"option\">exec</code> will not proceed before both <code class=\"function\">fork()</code> and\n            <code class=\"function\">execve()</code> in the service process succeeded.) Note that this means <span class=\"command\"><strong>systemctl\n            start</strong></span> command lines for <code class=\"option\">exec</code> services will report failure when the service's\n            binary cannot be invoked successfully (for example because the selected <code class=\"varname\">User=</code> doesn't\n            exist, or the service binary is missing).</p></li><li class=\"listitem\"><p>If set to <code class=\"option\">forking</code>, it is expected that the process configured with\n            <code class=\"varname\">ExecStart=</code> will call <code class=\"function\">fork()</code> as part of its start-up. The parent\n            process is expected to exit when start-up is complete and all communication channels are set up. The child\n            continues to run as the main service process, and the service manager will consider the unit started when\n            the parent process exits. This is the behavior of traditional UNIX services. If this setting is used, it is\n            recommended to also use the <code class=\"varname\">PIDFile=</code> option, so that systemd can reliably identify the\n            main process of the service. systemd will proceed with starting follow-up units as soon as the parent\n            process exits.</p></li><li class=\"listitem\"><p>Behavior of <code class=\"option\">oneshot</code> is similar to <code class=\"option\">simple</code>;\n            however, the service manager will consider the unit up after the main process exits. It will then\n            start follow-up units. <code class=\"varname\">RemainAfterExit=</code> is particularly useful for this type\n            of service. <code class=\"varname\">Type=</code><code class=\"option\">oneshot</code> is the implied default if neither\n            <code class=\"varname\">Type=</code> nor <code class=\"varname\">ExecStart=</code> are specified. Note that if this\n            option is used without <code class=\"varname\">RemainAfterExit=</code> the service will never enter\n            \"<code class=\"literal\">active</code>\" unit state, but directly transition from \"<code class=\"literal\">activating</code>\"\n            to \"<code class=\"literal\">deactivating</code>\" or \"<code class=\"literal\">dead</code>\" since no process is configured that\n            shall run continuously. In particular this means that after a service of this type ran (and which\n            has <code class=\"varname\">RemainAfterExit=</code> not set) it will not show up as started afterwards, but\n            as dead.</p></li><li class=\"listitem\"><p>Behavior of <code class=\"option\">dbus</code> is similar to <code class=\"option\">simple</code>; however, it is\n            expected that the service acquires a name on the D-Bus bus, as configured by\n            <code class=\"varname\">BusName=</code>. systemd will proceed with starting follow-up units after the D-Bus bus name\n            has been acquired. Service units with this option configured implicitly gain dependencies on the\n            <code class=\"filename\">dbus.socket</code> unit. This type is the default if <code class=\"varname\">BusName=</code> is\n            specified.</p></li><li class=\"listitem\"><p>Behavior of <code class=\"option\">notify</code> is similar to <code class=\"option\">exec</code>; however, it is\n            expected that the service sends a notification message via\n            <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/sd_notify.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">sd_notify</span>(3)</span></a> or an\n            equivalent call when it has finished starting up. systemd will proceed with starting follow-up units after\n            this notification message has been sent. If this option is used, <code class=\"varname\">NotifyAccess=</code> (see\n            below) should be set to open access to the notification socket provided by systemd. If\n            <code class=\"varname\">NotifyAccess=</code> is missing or set to <code class=\"option\">none</code>, it will be forcibly set to\n            <code class=\"option\">main</code></p></li><li class=\"listitem\"><p>Behavior of <code class=\"option\">idle</code> is very similar to <code class=\"option\">simple</code>; however,\n            actual execution of the service program is delayed until all active jobs are dispatched. This may be used\n            to avoid interleaving of output of shell services with the status output on the console. Note that this\n            type is useful only to improve console output, it is not useful as a general unit ordering tool, and the\n            effect of this service type is subject to a 5s timeout, after which the service program is invoked\n            anyway.</p></li></ul></div><p>It is generally recommended to use <code class=\"varname\">Type=</code><code class=\"option\">simple</code> for long-running\n          services whenever possible, as it is the simplest and fastest option. However, as this service type won't\n          propagate service start-up failures and doesn't allow ordering of other units against completion of\n          initialization of the service (which for example is useful if clients need to connect to the service through\n          some form of IPC, and the IPC channel is only established by the service itself — in contrast to doing this\n          ahead of time through socket or bus activation or similar), it might not be sufficient for many cases. If so,\n          <code class=\"option\">notify</code> or <code class=\"option\">dbus</code> (the latter only in case the service provides a D-Bus\n          interface) are the preferred options as they allow service program code to precisely schedule when to\n          consider the service started up successfully and when to proceed with follow-up units. The\n          <code class=\"option\">notify</code> service type requires explicit support in the service codebase (as\n          <code class=\"function\">sd_notify()</code> or an equivalent API needs to be invoked by the service at the appropriate\n          time) — if it's not supported, then <code class=\"option\">forking</code> is an alternative: it supports the traditional\n          UNIX service start-up protocol. Finally, <code class=\"option\">exec</code> might be an option for cases where it is\n          enough to ensure the service binary is invoked, and where the service binary itself executes no or little\n          initialization on its own (and its initialization is unlikely to fail). Note that using any type other than\n          <code class=\"option\">simple</code> possibly delays the boot process, as the service manager needs to wait for service\n          initialization to complete. It is hence recommended not to needlessly use any types other than\n          <code class=\"option\">simple</code>. (Also note it is generally not recommended to use <code class=\"option\">idle</code> or\n          <code class=\"option\">oneshot</code> for long-running services.)</p>",
                "RemainAfterExit": "<p>Takes a boolean value that specifies whether\n        the service shall be considered active even when all its\n        processes exited. Defaults to <code class=\"option\">no</code>.</p>",
                "GuessMainPID": "<p>Takes a boolean value that specifies whether\n        systemd should try to guess the main PID of a service if it\n        cannot be determined reliably. This option is ignored unless\n        <code class=\"option\">Type=forking</code> is set and\n        <code class=\"option\">PIDFile=</code> is unset because for the other types\n        or with an explicitly configured PID file, the main PID is\n        always known. The guessing algorithm might come to incorrect\n        conclusions if a daemon consists of more than one process. If\n        the main PID cannot be determined, failure detection and\n        automatic restarting of a service will not work reliably.\n        Defaults to <code class=\"option\">yes</code>.</p>",
                "PIDFile": "<p>Takes a path referring to the PID file of the service. Usage of this option is recommended for\n        services where <code class=\"varname\">Type=</code> is set to <code class=\"option\">forking</code>. The path specified typically points\n        to a file below <code class=\"filename\">/run/</code>. If a relative path is specified it is hence prefixed with\n        <code class=\"filename\">/run/</code>. The service manager will read the PID of the main process of the service from this\n        file after start-up of the service. The service manager will not write to the file configured here, although it\n        will remove the file after the service has shut down if it still exists. The PID file does not need to be owned\n        by a privileged user, but if it is owned by an unprivileged user additional safety restrictions are enforced:\n        the file may not be a symlink to a file owned by a different user (neither directly nor indirectly), and the\n        PID file must refer to a process already belonging to the service.</p>",
                "BusName": "<p>Takes a D-Bus bus name that this service is\n        reachable as. This option is mandatory for services where\n        <code class=\"varname\">Type=</code> is set to\n        <code class=\"option\">dbus</code>.</p>",
                "ExecStart": "<p>Commands with their arguments that are\n        executed when this service is started. The value is split into\n        zero or more command lines according to the rules described\n        below (see section \"Command Lines\" below).\n        </p><p>Unless <code class=\"varname\">Type=</code> is <code class=\"option\">oneshot</code>, exactly one command must be given. When\n        <code class=\"varname\">Type=oneshot</code> is used, zero or more commands may be specified. Commands may be specified by\n        providing multiple command lines in the same directive, or alternatively, this directive may be specified more\n        than once with the same effect. If the empty string is assigned to this option, the list of commands to start\n        is reset, prior assignments of this option will have no effect. If no <code class=\"varname\">ExecStart=</code> is\n        specified, then the service must have <code class=\"varname\">RemainAfterExit=yes</code> and at least one\n        <code class=\"varname\">ExecStop=</code> line set. (Services lacking both <code class=\"varname\">ExecStart=</code> and\n        <code class=\"varname\">ExecStop=</code> are not valid.)</p><p>For each of the specified commands, the first argument must be either an absolute path to an executable\n        or a simple file name without any slashes. Optionally, this filename may be prefixed with a number of special\n        characters:</p><div class=\"table\"><a target=\"__blank\" name=\"id-1.8.3.6.2.4\"></a><p class=\"title\"><b>Table&nbsp;1.&nbsp;Special executable prefixes</b></p><div class=\"table-contents\"><table class=\"table\" summary=\"Special executable prefixes\" border=\"1\"><colgroup><col class=\"prefix\"><col class=\"meaning\"></colgroup><thead><tr><th>Prefix</th><th>Effect</th></tr></thead><tbody><tr><td>\"<code class=\"literal\">@</code>\"</td><td>If the executable path is prefixed with \"<code class=\"literal\">@</code>\", the second specified token will be passed as \"<code class=\"literal\">argv[0]</code>\" to the executed process (instead of the actual filename), followed by the further arguments specified.</td></tr><tr><td>\"<code class=\"literal\">-</code>\"</td><td>If the executable path is prefixed with \"<code class=\"literal\">-</code>\", an exit code of the command normally considered a failure (i.e. non-zero exit status or abnormal exit due to signal) is recorded, but has no further effect and is considered equivalent to success.</td></tr><tr><td>\"<code class=\"literal\">:</code>\"</td><td>If the executable path is prefixed with \"<code class=\"literal\">:</code>\", environment variable substitution (as described by the \"Command Lines\" section below) is not applied.</td></tr><tr><td>\"<code class=\"literal\">+</code>\"</td><td>If the executable path is prefixed with \"<code class=\"literal\">+</code>\" then the process is executed with full privileges. In this mode privilege restrictions configured with <code class=\"varname\">User=</code>, <code class=\"varname\">Group=</code>, <code class=\"varname\">CapabilityBoundingSet=</code> or the various file system namespacing options (such as <code class=\"varname\">PrivateDevices=</code>, <code class=\"varname\">PrivateTmp=</code>) are not applied to the invoked command line (but still affect any other <code class=\"varname\">ExecStart=</code>, <code class=\"varname\">ExecStop=</code>, … lines).</td></tr><tr><td>\"<code class=\"literal\">!</code>\"</td><td>Similar to the \"<code class=\"literal\">+</code>\" character discussed above this permits invoking command lines with elevated privileges. However, unlike \"<code class=\"literal\">+</code>\" the \"<code class=\"literal\">!</code>\" character exclusively alters the effect of <code class=\"varname\">User=</code>, <code class=\"varname\">Group=</code> and <code class=\"varname\">SupplementaryGroups=</code>, i.e. only the stanzas that affect user and group credentials. Note that this setting may be combined with <code class=\"varname\">DynamicUser=</code>, in which case a dynamic user/group pair is allocated before the command is invoked, but credential changing is left to the executed process itself.</td></tr><tr><td>\"<code class=\"literal\">!!</code>\"</td><td>This prefix is very similar to \"<code class=\"literal\">!</code>\", however it only has an effect on systems lacking support for ambient process capabilities, i.e. without support for <code class=\"varname\">AmbientCapabilities=</code>. It's intended to be used for unit files that take benefit of ambient capabilities to run processes with minimal privileges wherever possible while remaining compatible with systems that lack ambient capabilities support. Note that when \"<code class=\"literal\">!!</code>\" is used, and a system lacking ambient capability support is detected any configured <code class=\"varname\">SystemCallFilter=</code> and <code class=\"varname\">CapabilityBoundingSet=</code> stanzas are implicitly modified, in order to permit spawned processes to drop credentials and capabilities themselves, even if this is configured to not be allowed. Moreover, if this prefix is used and a system lacking ambient capability support is detected <code class=\"varname\">AmbientCapabilities=</code> will be skipped and not be applied. On systems supporting ambient capabilities, \"<code class=\"literal\">!!</code>\" has no effect and is redundant.</td></tr></tbody></table></div></div><br class=\"table-break\"><p>\"<code class=\"literal\">@</code>\", \"<code class=\"literal\">-</code>\", \"<code class=\"literal\">:</code>\", and one of\n        \"<code class=\"literal\">+</code>\"/\"<code class=\"literal\">!</code>\"/\"<code class=\"literal\">!!</code>\" may be used together and they can appear in any\n        order. However, only one of \"<code class=\"literal\">+</code>\", \"<code class=\"literal\">!</code>\", \"<code class=\"literal\">!!</code>\" may be used at a\n        time. Note that these prefixes are also supported for the other command line settings,\n        i.e. <code class=\"varname\">ExecStartPre=</code>, <code class=\"varname\">ExecStartPost=</code>, <code class=\"varname\">ExecReload=</code>,\n        <code class=\"varname\">ExecStop=</code> and <code class=\"varname\">ExecStopPost=</code>.</p><p>If more than one command is specified, the commands are\n        invoked sequentially in the order they appear in the unit\n        file. If one of the commands fails (and is not prefixed with\n        \"<code class=\"literal\">-</code>\"), other lines are not executed, and the\n        unit is considered failed.</p><p>Unless <code class=\"varname\">Type=forking</code> is set, the\n        process started via this command line will be considered the\n        main process of the daemon.</p>",
                "ExecStartPre": "<p>Additional commands that are executed before\n        or after the command in <code class=\"varname\">ExecStart=</code>,\n        respectively. Syntax is the same as for\n        <code class=\"varname\">ExecStart=</code>, except that multiple command\n        lines are allowed and the commands are executed one after the\n        other, serially.</p><p>If any of those commands (not prefixed with\n        \"<code class=\"literal\">-</code>\") fail, the rest are not executed and the\n        unit is considered failed.</p><p><code class=\"varname\">ExecStart=</code> commands are only run after\n        all <code class=\"varname\">ExecStartPre=</code> commands that were not prefixed\n        with a \"<code class=\"literal\">-</code>\" exit successfully.</p><p><code class=\"varname\">ExecStartPost=</code> commands are only run after the commands specified in\n        <code class=\"varname\">ExecStart=</code> have been invoked successfully, as determined by <code class=\"varname\">Type=</code>\n        (i.e. the process has been started for <code class=\"varname\">Type=simple</code> or <code class=\"varname\">Type=idle</code>, the last\n        <code class=\"varname\">ExecStart=</code> process exited successfully for <code class=\"varname\">Type=oneshot</code>, the initial\n        process exited successfully for <code class=\"varname\">Type=forking</code>, \"<code class=\"literal\">READY=1</code>\" is sent for\n        <code class=\"varname\">Type=notify</code>, or the <code class=\"varname\">BusName=</code> has been taken for\n        <code class=\"varname\">Type=dbus</code>).</p><p>Note that <code class=\"varname\">ExecStartPre=</code> may not be\n        used to start long-running processes. All processes forked\n        off by processes invoked via <code class=\"varname\">ExecStartPre=</code> will\n        be killed before the next service process is run.</p><p>Note that if any of the commands specified in <code class=\"varname\">ExecStartPre=</code>,\n        <code class=\"varname\">ExecStart=</code>, or <code class=\"varname\">ExecStartPost=</code> fail (and are not prefixed with\n        \"<code class=\"literal\">-</code>\", see above) or time out before the service is fully up, execution continues with commands\n        specified in <code class=\"varname\">ExecStopPost=</code>, the commands in <code class=\"varname\">ExecStop=</code> are skipped.</p><p>Note that the execution of <code class=\"varname\">ExecStartPost=</code> is taken into account for the purpose of\n        <code class=\"varname\">Before=</code>/<code class=\"varname\">After=</code> ordering constraints.</p>",
                "ExecStartPost": "<p>Additional commands that are executed before\n        or after the command in <code class=\"varname\">ExecStart=</code>,\n        respectively. Syntax is the same as for\n        <code class=\"varname\">ExecStart=</code>, except that multiple command\n        lines are allowed and the commands are executed one after the\n        other, serially.</p><p>If any of those commands (not prefixed with\n        \"<code class=\"literal\">-</code>\") fail, the rest are not executed and the\n        unit is considered failed.</p><p><code class=\"varname\">ExecStart=</code> commands are only run after\n        all <code class=\"varname\">ExecStartPre=</code> commands that were not prefixed\n        with a \"<code class=\"literal\">-</code>\" exit successfully.</p><p><code class=\"varname\">ExecStartPost=</code> commands are only run after the commands specified in\n        <code class=\"varname\">ExecStart=</code> have been invoked successfully, as determined by <code class=\"varname\">Type=</code>\n        (i.e. the process has been started for <code class=\"varname\">Type=simple</code> or <code class=\"varname\">Type=idle</code>, the last\n        <code class=\"varname\">ExecStart=</code> process exited successfully for <code class=\"varname\">Type=oneshot</code>, the initial\n        process exited successfully for <code class=\"varname\">Type=forking</code>, \"<code class=\"literal\">READY=1</code>\" is sent for\n        <code class=\"varname\">Type=notify</code>, or the <code class=\"varname\">BusName=</code> has been taken for\n        <code class=\"varname\">Type=dbus</code>).</p><p>Note that <code class=\"varname\">ExecStartPre=</code> may not be\n        used to start long-running processes. All processes forked\n        off by processes invoked via <code class=\"varname\">ExecStartPre=</code> will\n        be killed before the next service process is run.</p><p>Note that if any of the commands specified in <code class=\"varname\">ExecStartPre=</code>,\n        <code class=\"varname\">ExecStart=</code>, or <code class=\"varname\">ExecStartPost=</code> fail (and are not prefixed with\n        \"<code class=\"literal\">-</code>\", see above) or time out before the service is fully up, execution continues with commands\n        specified in <code class=\"varname\">ExecStopPost=</code>, the commands in <code class=\"varname\">ExecStop=</code> are skipped.</p><p>Note that the execution of <code class=\"varname\">ExecStartPost=</code> is taken into account for the purpose of\n        <code class=\"varname\">Before=</code>/<code class=\"varname\">After=</code> ordering constraints.</p>",
                "ExecCondition": "<p>Optional commands that are executed before the command(s) in <code class=\"varname\">ExecStartPre=</code>.\n        Syntax is the same as for <code class=\"varname\">ExecStart=</code>, except that multiple command lines are allowed and the\n        commands are executed one after the other, serially.</p><p>The behavior is like an <code class=\"varname\">ExecStartPre=</code> and condition check hybrid: when an\n        <code class=\"varname\">ExecCondition=</code> command exits with exit code 1 through 254 (inclusive), the remaining\n        commands are skipped and the unit is <span class=\"emphasis\"><em>not</em></span> marked as failed. However, if an\n        <code class=\"varname\">ExecCondition=</code> command exits with 255 or abnormally (e.g. timeout, killed by a\n        signal, etc.), the unit will be considered failed (and remaining commands will be skipped). Exit code of 0 or\n        those matching <code class=\"varname\">SuccessExitStatus=</code> will continue execution to the next command(s).</p><p>The same recommendations about not running long-running processes in <code class=\"varname\">ExecStartPre=</code>\n        also applies to <code class=\"varname\">ExecCondition=</code>. <code class=\"varname\">ExecCondition=</code> will also run the commands\n        in <code class=\"varname\">ExecStopPost=</code>, as part of stopping the service, in the case of any non-zero or abnormal\n        exits, like the ones described above.</p>",
                "ExecReload": "<p>Commands to execute to trigger a configuration\n        reload in the service. This argument takes multiple command\n        lines, following the same scheme as described for\n        <code class=\"varname\">ExecStart=</code> above. Use of this setting is\n        optional. Specifier and environment variable substitution is\n        supported here following the same scheme as for\n        <code class=\"varname\">ExecStart=</code>.</p><p>One additional, special environment variable is set: if\n        known, <code class=\"varname\">$MAINPID</code> is set to the main process\n        of the daemon, and may be used for command lines like the\n        following:</p><pre class=\"programlisting\">ExecReload=kill -HUP $MAINPID</pre><p>Note however that reloading a daemon by sending a signal\n        (as with the example line above) is usually not a good choice,\n        because this is an asynchronous operation and hence not\n        suitable to order reloads of multiple services against each\n        other. It is strongly recommended to set\n        <code class=\"varname\">ExecReload=</code> to a command that not only\n        triggers a configuration reload of the daemon, but also\n        synchronously waits for it to complete. For example,\n        <a target=\"__blank\" href=\"https://www.mankier.com/1/dbus-broker\"><span class=\"citerefentry\"><span class=\"refentrytitle\">dbus-broker</span>(1)</span></a>\n        uses the following:</p><pre class=\"programlisting\">ExecReload=busctl call org.freedesktop.DBus \\\n        /org/freedesktop/DBus org.freedesktop.DBus \\\n        ReloadConfig\n</pre>",
                "ExecStop": "<p>Commands to execute to stop the service started via\n        <code class=\"varname\">ExecStart=</code>. This argument takes multiple command lines, following the same scheme\n        as described for <code class=\"varname\">ExecStart=</code> above. Use of this setting is optional. After the\n        commands configured in this option are run, it is implied that the service is stopped, and any\n        processes remaining for it are terminated according to the <code class=\"varname\">KillMode=</code> setting (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.kill.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.kill</span>(5)</span></a>).\n        If this option is not specified, the process is terminated by sending the signal specified in\n        <code class=\"varname\">KillSignal=</code> or <code class=\"varname\">RestartKillSignal=</code> when service stop is\n        requested. Specifier and environment variable substitution is supported (including\n        <code class=\"varname\">$MAINPID</code>, see above).</p><p>Note that it is usually not sufficient to specify a command for this setting that only asks the\n        service to terminate (for example, by sending some form of termination signal to it), but does not\n        wait for it to do so. Since the remaining processes of the services are killed according to\n        <code class=\"varname\">KillMode=</code> and <code class=\"varname\">KillSignal=</code> or\n        <code class=\"varname\">RestartKillSignal=</code> as described above immediately after the command exited, this\n        may not result in a clean stop. The specified command should hence be a synchronous operation, not an\n        asynchronous one.</p><p>Note that the commands specified in <code class=\"varname\">ExecStop=</code> are only executed when the service\n        started successfully first. They are not invoked if the service was never started at all, or in case its\n        start-up failed, for example because any of the commands specified in <code class=\"varname\">ExecStart=</code>,\n        <code class=\"varname\">ExecStartPre=</code> or <code class=\"varname\">ExecStartPost=</code> failed (and weren't prefixed with\n        \"<code class=\"literal\">-</code>\", see above) or timed out. Use <code class=\"varname\">ExecStopPost=</code> to invoke commands when a\n        service failed to start up correctly and is shut down again. Also note that the stop operation is always\n        performed if the service started successfully, even if the processes in the service terminated on their\n        own or were killed. The stop commands must be prepared to deal with that case. <code class=\"varname\">$MAINPID</code>\n        will be unset if systemd knows that the main process exited by the time the stop commands are called.</p><p>Service restart requests are implemented as stop operations followed by start operations. This\n        means that <code class=\"varname\">ExecStop=</code> and <code class=\"varname\">ExecStopPost=</code> are executed during a\n        service restart operation.</p><p>It is recommended to use this setting for commands that communicate with the service requesting\n        clean termination. For post-mortem clean-up steps use <code class=\"varname\">ExecStopPost=</code> instead.\n        </p>",
                "ExecStopPost": "<p>Additional commands that are executed after the service is stopped. This includes cases where\n        the commands configured in <code class=\"varname\">ExecStop=</code> were used, where the service does not have any\n        <code class=\"varname\">ExecStop=</code> defined, or where the service exited unexpectedly. This argument takes multiple\n        command lines, following the same scheme as described for <code class=\"varname\">ExecStart=</code>. Use of these settings\n        is optional. Specifier and environment variable substitution is supported. Note that – unlike\n        <code class=\"varname\">ExecStop=</code> – commands specified with this setting are invoked when a service failed to start\n        up correctly and is shut down again.</p><p>It is recommended to use this setting for clean-up operations that shall be executed even when the\n        service failed to start up correctly. Commands configured with this setting need to be able to operate even if\n        the service failed starting up half-way and left incompletely initialized data around. As the service's\n        processes have been terminated already when the commands specified with this setting are executed they should\n        not attempt to communicate with them.</p><p>Note that all commands that are configured with this setting are invoked with the result code of the\n        service, as well as the main process' exit code and status, set in the <code class=\"varname\">$SERVICE_RESULT</code>,\n        <code class=\"varname\">$EXIT_CODE</code> and <code class=\"varname\">$EXIT_STATUS</code> environment variables, see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.exec.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.exec</span>(5)</span></a> for\n        details.</p><p>Note that the execution of <code class=\"varname\">ExecStopPost=</code> is taken into account for the purpose of\n        <code class=\"varname\">Before=</code>/<code class=\"varname\">After=</code> ordering constraints.</p>",
                "RestartSec": "<p>Configures the time to sleep before restarting\n        a service (as configured with <code class=\"varname\">Restart=</code>).\n        Takes a unit-less value in seconds, or a time span value such\n        as \"5min 20s\". Defaults to 100ms.</p>",
                "TimeoutStartSec": "<p>Configures the time to wait for start-up. If a daemon service does not signal start-up\n        completion within the configured time, the service will be considered failed and will be shut down again. The\n        precise action depends on the <code class=\"varname\">TimeoutStartFailureMode=</code> option. Takes a unit-less value in\n        seconds, or a time span value such as \"5min 20s\". Pass \"<code class=\"literal\">infinity</code>\" to disable the timeout logic.\n        Defaults to <code class=\"varname\">DefaultTimeoutStartSec=</code> from the manager configuration file, except when\n        <code class=\"varname\">Type=oneshot</code> is used, in which case the timeout is disabled by default (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd-system.conf</span>(5)</span></a>).\n        </p><p>If a service of <code class=\"varname\">Type=notify</code> sends \"<code class=\"literal\">EXTEND_TIMEOUT_USEC=…</code>\", this may cause\n        the start time to be extended beyond <code class=\"varname\">TimeoutStartSec=</code>. The first receipt of this message\n        must occur before <code class=\"varname\">TimeoutStartSec=</code> is exceeded, and once the start time has extended beyond\n        <code class=\"varname\">TimeoutStartSec=</code>, the service manager will allow the service to continue to start, provided\n        the service repeats \"<code class=\"literal\">EXTEND_TIMEOUT_USEC=…</code>\" within the interval specified until the service\n        startup status is finished by \"<code class=\"literal\">READY=1</code>\". (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/sd_notify.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">sd_notify</span>(3)</span></a>).\n        </p>",
                "TimeoutStopSec": "<p>This option serves two purposes. First, it configures the time to wait for each\n        <code class=\"varname\">ExecStop=</code> command. If any of them times out, subsequent <code class=\"varname\">ExecStop=</code> commands\n        are skipped and the service will be terminated by <code class=\"constant\">SIGTERM</code>. If no <code class=\"varname\">ExecStop=</code>\n        commands are specified, the service gets the <code class=\"constant\">SIGTERM</code> immediately. This default behavior\n        can be changed by the <code class=\"varname\">TimeoutStopFailureMode=</code> option. Second, it configures the time\n        to wait for the service itself to stop. If it doesn't terminate in the specified time, it will be forcibly terminated\n        by <code class=\"constant\">SIGKILL</code> (see <code class=\"varname\">KillMode=</code> in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.kill.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.kill</span>(5)</span></a>).\n        Takes a unit-less value in seconds, or a time span value such\n        as \"5min 20s\". Pass \"<code class=\"literal\">infinity</code>\" to disable the\n        timeout logic. Defaults to\n        <code class=\"varname\">DefaultTimeoutStopSec=</code> from the manager\n        configuration file (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd-system.conf</span>(5)</span></a>).\n        </p><p>If a service of <code class=\"varname\">Type=notify</code> sends \"<code class=\"literal\">EXTEND_TIMEOUT_USEC=…</code>\", this may cause\n        the stop time to be extended beyond <code class=\"varname\">TimeoutStopSec=</code>. The first receipt of this message\n        must occur before <code class=\"varname\">TimeoutStopSec=</code> is exceeded, and once the stop time has extended beyond\n        <code class=\"varname\">TimeoutStopSec=</code>, the service manager will allow the service to continue to stop, provided\n        the service repeats \"<code class=\"literal\">EXTEND_TIMEOUT_USEC=…</code>\" within the interval specified, or terminates itself\n        (see <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/sd_notify.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">sd_notify</span>(3)</span></a>).\n        </p>",
                "TimeoutAbortSec": "<p>This option configures the time to wait for the service to terminate when it was aborted due to a\n        watchdog timeout (see <code class=\"varname\">WatchdogSec=</code>). If the service has a short <code class=\"varname\">TimeoutStopSec=</code>\n        this option can be used to give the system more time to write a core dump of the service. Upon expiration the service\n        will be forcibly terminated by <code class=\"constant\">SIGKILL</code> (see <code class=\"varname\">KillMode=</code> in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.kill.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.kill</span>(5)</span></a>). The core file will\n        be truncated in this case. Use <code class=\"varname\">TimeoutAbortSec=</code> to set a sensible timeout for the core dumping per\n        service that is large enough to write all expected data while also being short enough to handle the service failure\n        in due time.\n        </p><p>Takes a unit-less value in seconds, or a time span value such as \"5min 20s\". Pass an empty value to skip\n        the dedicated watchdog abort timeout handling and fall back <code class=\"varname\">TimeoutStopSec=</code>. Pass\n        \"<code class=\"literal\">infinity</code>\" to disable the timeout logic. Defaults to <code class=\"varname\">DefaultTimeoutAbortSec=</code> from\n        the manager configuration file (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd-system.conf</span>(5)</span></a>).\n        </p><p>If a service of <code class=\"varname\">Type=notify</code> handles <code class=\"constant\">SIGABRT</code> itself (instead of relying\n        on the kernel to write a core dump) it can send \"<code class=\"literal\">EXTEND_TIMEOUT_USEC=…</code>\" to\n        extended the abort time beyond <code class=\"varname\">TimeoutAbortSec=</code>. The first receipt of this message\n        must occur before <code class=\"varname\">TimeoutAbortSec=</code> is exceeded, and once the abort time has extended beyond\n        <code class=\"varname\">TimeoutAbortSec=</code>, the service manager will allow the service to continue to abort, provided\n        the service repeats \"<code class=\"literal\">EXTEND_TIMEOUT_USEC=…</code>\" within the interval specified, or terminates itself\n        (see <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/sd_notify.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">sd_notify</span>(3)</span></a>).\n        </p>",
                "TimeoutSec": "<p>A shorthand for configuring both\n        <code class=\"varname\">TimeoutStartSec=</code> and\n        <code class=\"varname\">TimeoutStopSec=</code> to the specified value.\n        </p>",
                "TimeoutStartFailureMode": "<p>These options configure the action that is taken in case a daemon service does not signal\n        start-up within its configured <code class=\"varname\">TimeoutStartSec=</code>, respectively if it does not stop within\n        <code class=\"varname\">TimeoutStopSec=</code>. Takes one of <code class=\"option\">terminate</code>, <code class=\"option\">abort</code> and\n        <code class=\"option\">kill</code>. Both options default to <code class=\"option\">terminate</code>.</p><p>If <code class=\"option\">terminate</code> is set the service will be gracefully terminated by sending the signal\n        specified in <code class=\"varname\">KillSignal=</code> (defaults to <code class=\"constant\">SIGTERM</code>, see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.kill.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.kill</span>(5)</span></a>). If the\n        service does not terminate the <code class=\"varname\">FinalKillSignal=</code> is sent after\n        <code class=\"varname\">TimeoutStopSec=</code>. If <code class=\"option\">abort</code> is set, <code class=\"varname\">WatchdogSignal=</code> is sent\n        instead and <code class=\"varname\">TimeoutAbortSec=</code> applies before sending <code class=\"varname\">FinalKillSignal=</code>.\n        This setting may be used to analyze services that fail to start-up or shut-down intermittently.\n        By using <code class=\"option\">kill</code> the service is immediately terminated by sending\n        <code class=\"varname\">FinalKillSignal=</code> without any further timeout. This setting can be used to expedite the\n        shutdown of failing services.\n        </p>",
                "TimeoutStopFailureMode": "<p>These options configure the action that is taken in case a daemon service does not signal\n        start-up within its configured <code class=\"varname\">TimeoutStartSec=</code>, respectively if it does not stop within\n        <code class=\"varname\">TimeoutStopSec=</code>. Takes one of <code class=\"option\">terminate</code>, <code class=\"option\">abort</code> and\n        <code class=\"option\">kill</code>. Both options default to <code class=\"option\">terminate</code>.</p><p>If <code class=\"option\">terminate</code> is set the service will be gracefully terminated by sending the signal\n        specified in <code class=\"varname\">KillSignal=</code> (defaults to <code class=\"constant\">SIGTERM</code>, see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.kill.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.kill</span>(5)</span></a>). If the\n        service does not terminate the <code class=\"varname\">FinalKillSignal=</code> is sent after\n        <code class=\"varname\">TimeoutStopSec=</code>. If <code class=\"option\">abort</code> is set, <code class=\"varname\">WatchdogSignal=</code> is sent\n        instead and <code class=\"varname\">TimeoutAbortSec=</code> applies before sending <code class=\"varname\">FinalKillSignal=</code>.\n        This setting may be used to analyze services that fail to start-up or shut-down intermittently.\n        By using <code class=\"option\">kill</code> the service is immediately terminated by sending\n        <code class=\"varname\">FinalKillSignal=</code> without any further timeout. This setting can be used to expedite the\n        shutdown of failing services.\n        </p>",
                "RuntimeMaxSec": "<p>Configures a maximum time for the service to run. If this is used and the service has been\n        active for longer than the specified time it is terminated and put into a failure state. Note that this setting\n        does not have any effect on <code class=\"varname\">Type=oneshot</code> services, as they terminate immediately after\n        activation completed. Pass \"<code class=\"literal\">infinity</code>\" (the default) to configure no runtime\n        limit.</p><p>If a service of <code class=\"varname\">Type=notify</code> sends \"<code class=\"literal\">EXTEND_TIMEOUT_USEC=…</code>\", this may cause\n        the runtime to be extended beyond <code class=\"varname\">RuntimeMaxSec=</code>. The first receipt of this message\n        must occur before <code class=\"varname\">RuntimeMaxSec=</code> is exceeded, and once the runtime has extended beyond\n        <code class=\"varname\">RuntimeMaxSec=</code>, the service manager will allow the service to continue to run, provided\n        the service repeats \"<code class=\"literal\">EXTEND_TIMEOUT_USEC=…</code>\" within the interval specified until the service\n        shutdown is achieved by \"<code class=\"literal\">STOPPING=1</code>\" (or termination). (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/sd_notify.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">sd_notify</span>(3)</span></a>).\n        </p>",
                "WatchdogSec": "<p>Configures the watchdog timeout for a service.\n        The watchdog is activated when the start-up is completed. The\n        service must call\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/sd_notify.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">sd_notify</span>(3)</span></a>\n        regularly with \"<code class=\"literal\">WATCHDOG=1</code>\" (i.e. the\n        \"keep-alive ping\"). If the time between two such calls is\n        larger than the configured time, then the service is placed in\n        a failed state and it will be terminated with\n        <code class=\"constant\">SIGABRT</code> (or the signal specified by\n        <code class=\"varname\">WatchdogSignal=</code>). By setting\n        <code class=\"varname\">Restart=</code> to <code class=\"option\">on-failure</code>,\n        <code class=\"option\">on-watchdog</code>, <code class=\"option\">on-abnormal</code> or\n        <code class=\"option\">always</code>, the service will be automatically\n        restarted. The time configured here will be passed to the\n        executed service process in the\n        <code class=\"varname\">WATCHDOG_USEC=</code> environment variable. This\n        allows daemons to automatically enable the keep-alive pinging\n        logic if watchdog support is enabled for the service. If this\n        option is used, <code class=\"varname\">NotifyAccess=</code> (see below)\n        should be set to open access to the notification socket\n        provided by systemd. If <code class=\"varname\">NotifyAccess=</code> is\n        not set, it will be implicitly set to <code class=\"option\">main</code>.\n        Defaults to 0, which disables this feature. The service can\n        check whether the service manager expects watchdog keep-alive\n        notifications. See\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/sd_watchdog_enabled.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">sd_watchdog_enabled</span>(3)</span></a>\n        for details.\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/sd_event_set_watchdog.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">sd_event_set_watchdog</span>(3)</span></a>\n        may be used to enable automatic watchdog notification support.\n        </p>",
                "Restart": "<p>Configures whether the service shall be\n        restarted when the service process exits, is killed, or a\n        timeout is reached. The service process may be the main\n        service process, but it may also be one of the processes\n        specified with <code class=\"varname\">ExecStartPre=</code>,\n        <code class=\"varname\">ExecStartPost=</code>,\n        <code class=\"varname\">ExecStop=</code>,\n        <code class=\"varname\">ExecStopPost=</code>, or\n        <code class=\"varname\">ExecReload=</code>. When the death of the process\n        is a result of systemd operation (e.g. service stop or\n        restart), the service will not be restarted. Timeouts include\n        missing the watchdog \"keep-alive ping\" deadline and a service\n        start, reload, and stop operation timeouts.</p><p>Takes one of\n        <code class=\"option\">no</code>,\n        <code class=\"option\">on-success</code>,\n        <code class=\"option\">on-failure</code>,\n        <code class=\"option\">on-abnormal</code>,\n        <code class=\"option\">on-watchdog</code>,\n        <code class=\"option\">on-abort</code>, or\n        <code class=\"option\">always</code>.\n        If set to <code class=\"option\">no</code> (the default), the service will\n        not be restarted. If set to <code class=\"option\">on-success</code>, it\n        will be restarted only when the service process exits cleanly.\n        In this context, a clean exit means an exit code of 0, or one\n        of the signals\n        <code class=\"constant\">SIGHUP</code>,\n        <code class=\"constant\">SIGINT</code>,\n        <code class=\"constant\">SIGTERM</code> or\n        <code class=\"constant\">SIGPIPE</code>, and\n        additionally, exit statuses and signals specified in\n        <code class=\"varname\">SuccessExitStatus=</code>. If set to\n        <code class=\"option\">on-failure</code>, the service will be restarted\n        when the process exits with a non-zero exit code, is\n        terminated by a signal (including on core dump, but excluding\n        the aforementioned four signals), when an operation (such as\n        service reload) times out, and when the configured watchdog\n        timeout is triggered. If set to <code class=\"option\">on-abnormal</code>,\n        the service will be restarted when the process is terminated\n        by a signal (including on core dump, excluding the\n        aforementioned four signals), when an operation times out, or\n        when the watchdog timeout is triggered. If set to\n        <code class=\"option\">on-abort</code>, the service will be restarted only\n        if the service process exits due to an uncaught signal not\n        specified as a clean exit status. If set to\n        <code class=\"option\">on-watchdog</code>, the service will be restarted\n        only if the watchdog timeout for the service expires. If set\n        to <code class=\"option\">always</code>, the service will be restarted\n        regardless of whether it exited cleanly or not, got terminated\n        abnormally by a signal, or hit a timeout.</p><div class=\"table\"><a target=\"__blank\" name=\"id-1.8.3.20.2.3\"></a><p class=\"title\"><b>Table&nbsp;2.&nbsp;Exit causes and the effect of the <code class=\"varname\">Restart=</code> settings on them</b></p><div class=\"table-contents\"><table class=\"table\" summary=\"Exit causes and the effect of the Restart= settings on them\" border=\"1\"><colgroup><col class=\"path\"><col class=\"expl\"></colgroup><thead><tr><th>Restart settings/Exit causes</th><th><code class=\"option\">no</code></th><th><code class=\"option\">always</code></th><th><code class=\"option\">on-success</code></th><th><code class=\"option\">on-failure</code></th><th><code class=\"option\">on-abnormal</code></th><th><code class=\"option\">on-abort</code></th><th><code class=\"option\">on-watchdog</code></th></tr></thead><tbody><tr><td>Clean exit code or signal</td><td>&nbsp;</td><td>X</td><td>X</td><td>&nbsp;</td><td>&nbsp;</td><td>&nbsp;</td><td>&nbsp;</td></tr><tr><td>Unclean exit code</td><td>&nbsp;</td><td>X</td><td>&nbsp;</td><td>X</td><td>&nbsp;</td><td>&nbsp;</td><td>&nbsp;</td></tr><tr><td>Unclean signal</td><td>&nbsp;</td><td>X</td><td>&nbsp;</td><td>X</td><td>X</td><td>X</td><td>&nbsp;</td></tr><tr><td>Timeout</td><td>&nbsp;</td><td>X</td><td>&nbsp;</td><td>X</td><td>X</td><td>&nbsp;</td><td>&nbsp;</td></tr><tr><td>Watchdog</td><td>&nbsp;</td><td>X</td><td>&nbsp;</td><td>X</td><td>X</td><td>&nbsp;</td><td>X</td></tr></tbody></table></div></div><br class=\"table-break\"><p>As exceptions to the setting above, the service will not\n        be restarted if the exit code or signal is specified in\n        <code class=\"varname\">RestartPreventExitStatus=</code> (see below) or\n        the service is stopped with <span class=\"command\"><strong>systemctl stop</strong></span>\n        or an equivalent operation. Also, the services will always be\n        restarted if the exit code or signal is specified in\n        <code class=\"varname\">RestartForceExitStatus=</code> (see below).</p><p>Note that service restart is subject to unit start rate\n        limiting configured with <code class=\"varname\">StartLimitIntervalSec=</code>\n        and <code class=\"varname\">StartLimitBurst=</code>, see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.unit.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.unit</span>(5)</span></a>\n        for details.  A restarted service enters the failed state only\n        after the start limits are reached.</p><p>Setting this to <code class=\"option\">on-failure</code> is the\n        recommended choice for long-running services, in order to\n        increase reliability by attempting automatic recovery from\n        errors. For services that shall be able to terminate on their\n        own choice (and avoid immediate restarting),\n        <code class=\"option\">on-abnormal</code> is an alternative choice.</p>",
                "SuccessExitStatus": "<p>Takes a list of exit status definitions that, when returned by the main service\n        process, will be considered successful termination, in addition to the normal successful exit status\n        0 and the signals <code class=\"constant\">SIGHUP</code>, <code class=\"constant\">SIGINT</code>,\n        <code class=\"constant\">SIGTERM</code>, and <code class=\"constant\">SIGPIPE</code>. Exit status definitions can be\n        numeric termination statuses, termination status names, or termination signal names, separated by\n        spaces. See the Process Exit Codes section in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.exec.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.exec</span>(5)</span></a> for\n        a list of termination status names (for this setting only the part without the\n        \"<code class=\"literal\">EXIT_</code>\" or \"<code class=\"literal\">EX_</code>\" prefix should be used). See <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/signal.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">signal</span>(7)</span></a> for\n        a list of signal names.</p><p>Note that this setting does not change the mapping between numeric exit statuses and their\n        names, i.e. regardless how this setting is used 0 will still be mapped to \"<code class=\"literal\">SUCCESS</code>\"\n        (and thus typically shown as \"<code class=\"literal\">0/SUCCESS</code>\" in tool outputs) and 1 to\n        \"<code class=\"literal\">FAILURE</code>\" (and thus typically shown as \"<code class=\"literal\">1/FAILURE</code>\"), and so on. It\n        only controls what happens as effect of these exit statuses, and how it propagates to the state of\n        the service as a whole.</p><p>This option may appear more than once, in which case the list of successful exit statuses is\n        merged. If the empty string is assigned to this option, the list is reset, all prior assignments of\n        this option will have no effect.</p><div class=\"example\"><a target=\"__blank\" name=\"id-1.8.3.21.2.4\"></a><p class=\"title\"><b>Example&nbsp;1.&nbsp;A service with the <code class=\"varname\">SuccessExitStatus=</code> setting</b></p><div class=\"example-contents\"><pre class=\"programlisting\">SuccessExitStatus=TEMPFAIL 250 SIGUSR1</pre><p>Exit status 75 (<code class=\"constant\">TEMPFAIL</code>), 250, and the termination signal\n          <code class=\"constant\">SIGKILL</code> are considered clean service terminations.</p></div></div><br class=\"example-break\"><p>Note: <span class=\"command\"><strong>systemd-analyze exit-status</strong></span> may be used to list exit statuses and\n        translate between numerical status values and names.</p>",
                "RestartPreventExitStatus": "<p>Takes a list of exit status definitions that, when returned by the main service\n        process, will prevent automatic service restarts, regardless of the restart setting configured with\n        <code class=\"varname\">Restart=</code>. Exit status definitions can either be numeric exit codes or termination\n        signal names, and are separated by spaces. Defaults to the empty list, so that, by default, no exit\n        status is excluded from the configured restart logic. For example:\n\n        </p><pre class=\"programlisting\">RestartPreventExitStatus=1 6 SIGABRT</pre><p>\n\n        ensures that exit codes 1 and 6 and the termination signal <code class=\"constant\">SIGABRT</code> will not\n        result in automatic service restarting. This option may appear more than once, in which case the list\n        of restart-preventing statuses is merged. If the empty string is assigned to this option, the list is\n        reset and all prior assignments of this option will have no effect.</p><p>Note that this setting has no effect on processes configured via\n        <code class=\"varname\">ExecStartPre=</code>, <code class=\"varname\">ExecStartPost=</code>, <code class=\"varname\">ExecStop=</code>,\n        <code class=\"varname\">ExecStopPost=</code> or <code class=\"varname\">ExecReload=</code>, but only on the main service\n        process, i.e. either the one invoked by <code class=\"varname\">ExecStart=</code> or (depending on\n        <code class=\"varname\">Type=</code>, <code class=\"varname\">PIDFile=</code>, …) the otherwise configured main\n        process.</p>",
                "RestartForceExitStatus": "<p>Takes a list of exit status definitions that,\n        when returned by the main service process, will force automatic\n        service restarts, regardless of the restart setting configured\n        with <code class=\"varname\">Restart=</code>. The argument format is\n        similar to\n        <code class=\"varname\">RestartPreventExitStatus=</code>.</p>",
                "RootDirectoryStartOnly": "<p>Takes a boolean argument. If true, the root\n        directory, as configured with the\n        <code class=\"varname\">RootDirectory=</code> option (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.exec.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.exec</span>(5)</span></a>\n        for more information), is only applied to the process started\n        with <code class=\"varname\">ExecStart=</code>, and not to the various\n        other <code class=\"varname\">ExecStartPre=</code>,\n        <code class=\"varname\">ExecStartPost=</code>,\n        <code class=\"varname\">ExecReload=</code>, <code class=\"varname\">ExecStop=</code>,\n        and <code class=\"varname\">ExecStopPost=</code> commands. If false, the\n        setting is applied to all configured commands the same way.\n        Defaults to false.</p>",
                "NonBlocking": "<p>Set the <code class=\"constant\">O_NONBLOCK</code> flag for all file descriptors passed via socket-based\n        activation. If true, all file descriptors &gt;= 3 (i.e. all except stdin, stdout, stderr), excluding those passed\n        in via the file descriptor storage logic (see <code class=\"varname\">FileDescriptorStoreMax=</code> for details), will\n        have the <code class=\"constant\">O_NONBLOCK</code> flag set and hence are in non-blocking mode. This option is only\n        useful in conjunction with a socket unit, as described in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.socket.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.socket</span>(5)</span></a> and has no\n        effect on file descriptors which were previously saved in the file-descriptor store for example.  Defaults to\n        false.</p>",
                "NotifyAccess": "<p>Controls access to the service status notification socket, as accessible via the\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/sd_notify.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">sd_notify</span>(3)</span></a> call. Takes one\n        of <code class=\"option\">none</code> (the default), <code class=\"option\">main</code>, <code class=\"option\">exec</code> or\n        <code class=\"option\">all</code>. If <code class=\"option\">none</code>, no daemon status updates are accepted from the service\n        processes, all status update messages are ignored. If <code class=\"option\">main</code>, only service updates sent from the\n        main process of the service are accepted. If <code class=\"option\">exec</code>, only service updates sent from any of the\n        main or control processes originating from one of the <code class=\"varname\">Exec*=</code> commands are accepted. If\n        <code class=\"option\">all</code>, all services updates from all members of the service's control group are accepted. This\n        option should be set to open access to the notification socket when using <code class=\"varname\">Type=notify</code> or\n        <code class=\"varname\">WatchdogSec=</code> (see above). If those options are used but <code class=\"varname\">NotifyAccess=</code> is\n        not configured, it will be implicitly set to <code class=\"option\">main</code>.</p><p>Note that <code class=\"function\">sd_notify()</code> notifications may be attributed to units correctly only if\n        either the sending process is still around at the time PID 1 processes the message, or if the sending process\n        is explicitly runtime-tracked by the service manager. The latter is the case if the service manager originally\n        forked off the process, i.e. on all processes that match <code class=\"option\">main</code> or\n        <code class=\"option\">exec</code>. Conversely, if an auxiliary process of the unit sends an\n        <code class=\"function\">sd_notify()</code> message and immediately exits, the service manager might not be able to\n        properly attribute the message to the unit, and thus will ignore it, even if\n        <code class=\"varname\">NotifyAccess=</code><code class=\"option\">all</code> is set for it.</p><p>Hence, to eliminate all race conditions involving lookup of the client's unit and attribution of notifications\n        to units correctly, <code class=\"function\">sd_notify_barrier()</code> may be used. This call acts as a synchronization point\n        and ensures all notifications sent before this call have been picked up by the service manager when it returns\n        successfully. Use of <code class=\"function\">sd_notify_barrier()</code> is needed for clients which are not invoked by the\n        service manager, otherwise this synchronization mechanism is unnecessary for attribution of notifications to the\n        unit.</p>",
                "Sockets": "<p>Specifies the name of the socket units this\n        service shall inherit socket file descriptors from when the\n        service is started. Normally, it should not be necessary to use\n        this setting, as all socket file descriptors whose unit shares\n        the same name as the service (subject to the different unit\n        name suffix of course) are passed to the spawned\n        process.</p><p>Note that the same socket file descriptors may be passed\n        to multiple processes simultaneously. Also note that a\n        different service may be activated on incoming socket traffic\n        than the one which is ultimately configured to inherit the\n        socket file descriptors. Or, in other words: the\n        <code class=\"varname\">Service=</code> setting of\n        <code class=\"filename\">.socket</code> units does not have to match the\n        inverse of the <code class=\"varname\">Sockets=</code> setting of the\n        <code class=\"filename\">.service</code> it refers to.</p><p>This option may appear more than once, in which case the list of socket units is merged. Note\n        that once set, clearing the list of sockets again (for example, by assigning the empty string to this\n        option) is not supported.</p>",
                "FileDescriptorStoreMax": "<p>Configure how many file descriptors may be stored in the service manager for the service using\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/sd_pid_notify_with_fds.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">sd_pid_notify_with_fds</span>(3)</span></a>'s\n        \"<code class=\"literal\">FDSTORE=1</code>\" messages. This is useful for implementing services that can restart after an\n        explicit request or a crash without losing state. Any open sockets and other file descriptors which should not\n        be closed during the restart may be stored this way. Application state can either be serialized to a file in\n        <code class=\"filename\">/run</code>, or better, stored in a\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/memfd_create.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">memfd_create</span>(2)</span></a> memory file\n        descriptor. Defaults to 0, i.e. no file descriptors may be stored in the service manager. All file descriptors\n        passed to the service manager from a specific service are passed back to the service's main process on the next\n        service restart. Any file descriptors passed to the service manager are automatically closed when\n        <code class=\"constant\">POLLHUP</code> or <code class=\"constant\">POLLERR</code> is seen on them, or when the service is fully\n        stopped and no job is queued or being executed for it. If this option is used, <code class=\"varname\">NotifyAccess=</code>\n        (see above) should be set to open access to the notification socket provided by systemd. If\n        <code class=\"varname\">NotifyAccess=</code> is not set, it will be implicitly set to\n        <code class=\"option\">main</code>.</p>",
                "USBFunctionDescriptors": "<p>Configure the location of a file containing\n        <a target=\"__blank\" class=\"ulink\" href=\"https://www.kernel.org/doc/Documentation/usb/functionfs.txt\" target=\"_top\">USB\n        FunctionFS</a> descriptors, for implementation of USB\n        gadget functions. This is used only in conjunction with a\n        socket unit with <code class=\"varname\">ListenUSBFunction=</code>\n        configured. The contents of this file are written to the\n        <code class=\"filename\">ep0</code> file after it is\n        opened.</p>",
                "USBFunctionStrings": "<p>Configure the location of a file containing\n        USB FunctionFS strings.  Behavior is similar to\n        <code class=\"varname\">USBFunctionDescriptors=</code>\n        above.</p>",
                "OOMPolicy": "<p>Configure the Out-Of-Memory (OOM) killer policy. On Linux, when memory becomes scarce\n        the kernel might decide to kill a running process in order to free up memory and reduce memory\n        pressure. This setting takes one of <code class=\"constant\">continue</code>, <code class=\"constant\">stop</code> or\n        <code class=\"constant\">kill</code>. If set to <code class=\"constant\">continue</code> and a process of the service is\n        killed by the kernel's OOM killer this is logged but the service continues running. If set to\n        <code class=\"constant\">stop</code> the event is logged but the service is terminated cleanly by the service\n        manager. If set to <code class=\"constant\">kill</code> and one of the service's processes is killed by the OOM\n        killer the kernel is instructed to kill all remaining processes of the service, too. Defaults to the\n        setting <code class=\"varname\">DefaultOOMPolicy=</code> in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd-system.conf</span>(5)</span></a>\n        is set to, except for services where <code class=\"varname\">Delegate=</code> is turned on, where it defaults to\n        <code class=\"constant\">continue</code>.</p><p>Use the <code class=\"varname\">OOMScoreAdjust=</code> setting to configure whether processes of the unit\n        shall be considered preferred or less preferred candidates for process termination by the Linux OOM\n        killer logic. See\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.exec.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.exec</span>(5)</span></a> for\n        details.</p>",
                "WorkingDirectory": "<p>Takes a directory path relative to the service's root directory specified by\n        <code class=\"varname\">RootDirectory=</code>, or the special value \"<code class=\"literal\">~</code>\". Sets the working directory for\n        executed processes. If set to \"<code class=\"literal\">~</code>\", the home directory of the user specified in\n        <code class=\"varname\">User=</code> is used. If not set, defaults to the root directory when systemd is running as a\n        system instance and the respective user's home directory if run as user. If the setting is prefixed with the\n        \"<code class=\"literal\">-</code>\" character, a missing working directory is not considered fatal. If\n        <code class=\"varname\">RootDirectory=</code>/<code class=\"varname\">RootImage=</code> is not set, then\n        <code class=\"varname\">WorkingDirectory=</code> is relative to the root of the system running the service manager.  Note\n        that setting this parameter might result in additional dependencies to be added to the unit (see\n        above).</p>",
                "RootDirectory": "<p>Takes a directory path relative to the host's root directory (i.e. the root of the system\n        running the service manager). Sets the root directory for executed processes, with the <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/chroot.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">chroot</span>(2)</span></a> system\n        call. If this is used, it must be ensured that the process binary and all its auxiliary files are available in\n        the <code class=\"function\">chroot()</code> jail. Note that setting this parameter might result in additional\n        dependencies to be added to the unit (see above).</p><p>The <code class=\"varname\">MountAPIVFS=</code> and <code class=\"varname\">PrivateUsers=</code> settings are particularly useful\n        in conjunction with <code class=\"varname\">RootDirectory=</code>. For details, see below.</p><p><a target=\"__blank\" name=\"singular\"></a>This option is only available for system services and is not supported for services\nrunning in per-user instances of the service manager.</p>",
                "RootImage": "<p>Takes a path to a block device node or regular file as argument. This call is similar\n        to <code class=\"varname\">RootDirectory=</code> however mounts a file system hierarchy from a block device node\n        or loopback file instead of a directory. The device node or file system image file needs to contain a\n        file system without a partition table, or a file system within an MBR/MS-DOS or GPT partition table\n        with only a single Linux-compatible partition, or a set of file systems within a GPT partition table\n        that follows the <a target=\"__blank\" class=\"ulink\" href=\"https://systemd.io/DISCOVERABLE_PARTITIONS\" target=\"_top\">Discoverable Partitions\n        Specification</a>.</p><p>When <code class=\"varname\">DevicePolicy=</code> is set to \"<code class=\"literal\">closed</code>\" or\n        \"<code class=\"literal\">strict</code>\", or set to \"<code class=\"literal\">auto</code>\" and <code class=\"varname\">DeviceAllow=</code> is\n        set, then this setting adds <code class=\"filename\">/dev/loop-control</code> with <code class=\"constant\">rw</code> mode,\n        \"<code class=\"literal\">block-loop</code>\" and \"<code class=\"literal\">block-blkext</code>\" with <code class=\"constant\">rwm</code> mode\n        to <code class=\"varname\">DeviceAllow=</code>. See\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.resource-control</span>(5)</span></a>\n        for the details about <code class=\"varname\">DevicePolicy=</code> or <code class=\"varname\">DeviceAllow=</code>. Also, see\n        <code class=\"varname\">PrivateDevices=</code> below, as it may change the setting of\n        <code class=\"varname\">DevicePolicy=</code>.</p><p>Units making use of <code class=\"varname\">RootImage=</code> automatically gain an\n        <code class=\"varname\">After=</code> dependency on <code class=\"filename\">systemd-udevd.service</code>.</p><p><a target=\"__blank\" name=\"singular\"></a>This option is only available for system services and is not supported for services\nrunning in per-user instances of the service manager.</p>",
                "RootHash": "<p>Takes a data integrity (dm-verity) root hash specified in hexadecimal, or the path to a file\n        containing a root hash in ASCII hexadecimal format. This option enables data integrity checks using dm-verity,\n        if the used image contains the appropriate integrity data (see above) or if <code class=\"varname\">RootVerity=</code> is used.\n        The specified hash must match the root hash of integrity data, and is usually at least 256 bits (and hence 64\n        formatted hexadecimal characters) long (in case of SHA256 for example). If this option is not specified, but\n        the image file carries the \"<code class=\"literal\">user.verity.roothash</code>\" extended file attribute (see <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/xattr.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">xattr</span>(7)</span></a>), then the root\n        hash is read from it, also as formatted hexadecimal characters. If the extended file attribute is not found (or\n        is not supported by the underlying file system), but a file with the <code class=\"filename\">.roothash</code> suffix is\n        found next to the image file, bearing otherwise the same name (except if the image has the\n        <code class=\"filename\">.raw</code> suffix, in which case the root hash file must not have it in its name), the root hash\n        is read from it and automatically used, also as formatted hexadecimal characters.</p><p><a target=\"__blank\" name=\"singular\"></a>This option is only available for system services and is not supported for services\nrunning in per-user instances of the service manager.</p>",
                "RootHashSignature": "<p>Takes a PKCS7 formatted binary signature of the <code class=\"varname\">RootHash=</code> option as a path\n        to a DER encoded signature file or as an ASCII base64 string encoding of the DER encoded signature, prefixed\n        by \"<code class=\"literal\">base64:</code>\". The dm-verity volume will only be opened if the signature of the root hash\n        signature is valid and created by a public key present in the kernel keyring. If this option is not specified,\n        but a file with the <code class=\"filename\">.roothash.p7s</code> suffix is found next to the image file, bearing otherwise\n        the same name (except if the image has the <code class=\"filename\">.raw</code> suffix, in which case the signature file\n        must not have it in its name), the signature is read from it and automatically used.</p><p><a target=\"__blank\" name=\"singular\"></a>This option is only available for system services and is not supported for services\nrunning in per-user instances of the service manager.</p>",
                "RootVerity": "<p>Takes the path to a data integrity (dm-verity) file. This option enables data integrity checks\n        using dm-verity, if <code class=\"varname\">RootImage=</code> is used and a root-hash is passed and if the used image itself\n        does not contains the integrity data. The integrity data must be matched by the root hash. If this option is not\n        specified, but a file with the <code class=\"filename\">.verity</code> suffix is found next to the image file, bearing otherwise\n        the same name (except if the image has the <code class=\"filename\">.raw</code> suffix, in which case the verity data file must\n        not have it in its name), the verity data is read from it and automatically used.</p><p>This option is supported only for disk images that contain a single file system, without an\n        enveloping partition table. Images that contain a GPT partition table should instead include both\n        root file system and matching Verity data in the same image, implementing the <a target=\"__blank\" class=\"ulink\" href=\"https://systemd.io/DISCOVERABLE_PARTITIONS\" target=\"_top\">Discoverable Partition Specification</a>.</p><p><a target=\"__blank\" name=\"singular\"></a>This option is only available for system services and is not supported for services\nrunning in per-user instances of the service manager.</p>",
                "MountAPIVFS": "<p>Takes a boolean argument. If on, a private mount namespace for the unit's processes is created\n        and the API file systems <code class=\"filename\">/proc</code>, <code class=\"filename\">/sys</code>, and <code class=\"filename\">/dev</code>\n        are mounted inside of it, unless they are already mounted. Note that this option has no effect unless used in\n        conjunction with <code class=\"varname\">RootDirectory=</code>/<code class=\"varname\">RootImage=</code> as these three mounts are\n        generally mounted in the host anyway, and unless the root directory is changed, the private mount namespace\n        will be a 1:1 copy of the host's, and include these three mounts. Note that the <code class=\"filename\">/dev</code> file\n        system of the host is bind mounted if this option is used without <code class=\"varname\">PrivateDevices=</code>. To run\n        the service with a private, minimal version of <code class=\"filename\">/dev/</code>, combine this option with\n        <code class=\"varname\">PrivateDevices=</code>.</p><p><a target=\"__blank\" name=\"singular\"></a>This option is only available for system services and is not supported for services\nrunning in per-user instances of the service manager.</p>",
                "BindPaths": "<p>Configures unit-specific bind mounts. A bind mount makes a particular file or directory\n        available at an additional place in the unit's view of the file system. Any bind mounts created with this\n        option are specific to the unit, and are not visible in the host's mount table. This option expects a\n        whitespace separated list of bind mount definitions. Each definition consists of a colon-separated triple of\n        source path, destination path and option string, where the latter two are optional. If only a source path is\n        specified the source and destination is taken to be the same. The option string may be either\n        \"<code class=\"literal\">rbind</code>\" or \"<code class=\"literal\">norbind</code>\" for configuring a recursive or non-recursive bind\n        mount. If the destination path is omitted, the option string must be omitted too.\n        Each bind mount definition may be prefixed with \"<code class=\"literal\">-</code>\", in which case it will be ignored\n        when its source path does not exist.</p><p><code class=\"varname\">BindPaths=</code> creates regular writable bind mounts (unless the source file system mount\n        is already marked read-only), while <code class=\"varname\">BindReadOnlyPaths=</code> creates read-only bind mounts. These\n        settings may be used more than once, each usage appends to the unit's list of bind mounts. If the empty string\n        is assigned to either of these two options the entire list of bind mounts defined prior to this is reset. Note\n        that in this case both read-only and regular bind mounts are reset, regardless which of the two settings is\n        used.</p><p>This option is particularly useful when <code class=\"varname\">RootDirectory=</code>/<code class=\"varname\">RootImage=</code>\n        is used. In this case the source path refers to a path on the host file system, while the destination path\n        refers to a path below the root directory of the unit.</p><p>Note that the destination directory must exist or systemd must be able to create it.  Thus, it\n        is not possible to use those options for mount points nested underneath paths specified in\n        <code class=\"varname\">InaccessiblePaths=</code>, or under <code class=\"filename\">/home/</code> and other protected\n        directories if <code class=\"varname\">ProtectHome=yes</code> is\n        specified. <code class=\"varname\">TemporaryFileSystem=</code> with \"<code class=\"literal\">:ro</code>\" or\n        <code class=\"varname\">ProtectHome=tmpfs</code> should be used instead.</p><p><a target=\"__blank\" name=\"singular\"></a>This option is only available for system services and is not supported for services\nrunning in per-user instances of the service manager.</p>",
                "BindReadOnlyPaths": "<p>Configures unit-specific bind mounts. A bind mount makes a particular file or directory\n        available at an additional place in the unit's view of the file system. Any bind mounts created with this\n        option are specific to the unit, and are not visible in the host's mount table. This option expects a\n        whitespace separated list of bind mount definitions. Each definition consists of a colon-separated triple of\n        source path, destination path and option string, where the latter two are optional. If only a source path is\n        specified the source and destination is taken to be the same. The option string may be either\n        \"<code class=\"literal\">rbind</code>\" or \"<code class=\"literal\">norbind</code>\" for configuring a recursive or non-recursive bind\n        mount. If the destination path is omitted, the option string must be omitted too.\n        Each bind mount definition may be prefixed with \"<code class=\"literal\">-</code>\", in which case it will be ignored\n        when its source path does not exist.</p><p><code class=\"varname\">BindPaths=</code> creates regular writable bind mounts (unless the source file system mount\n        is already marked read-only), while <code class=\"varname\">BindReadOnlyPaths=</code> creates read-only bind mounts. These\n        settings may be used more than once, each usage appends to the unit's list of bind mounts. If the empty string\n        is assigned to either of these two options the entire list of bind mounts defined prior to this is reset. Note\n        that in this case both read-only and regular bind mounts are reset, regardless which of the two settings is\n        used.</p><p>This option is particularly useful when <code class=\"varname\">RootDirectory=</code>/<code class=\"varname\">RootImage=</code>\n        is used. In this case the source path refers to a path on the host file system, while the destination path\n        refers to a path below the root directory of the unit.</p><p>Note that the destination directory must exist or systemd must be able to create it.  Thus, it\n        is not possible to use those options for mount points nested underneath paths specified in\n        <code class=\"varname\">InaccessiblePaths=</code>, or under <code class=\"filename\">/home/</code> and other protected\n        directories if <code class=\"varname\">ProtectHome=yes</code> is\n        specified. <code class=\"varname\">TemporaryFileSystem=</code> with \"<code class=\"literal\">:ro</code>\" or\n        <code class=\"varname\">ProtectHome=tmpfs</code> should be used instead.</p><p><a target=\"__blank\" name=\"singular\"></a>This option is only available for system services and is not supported for services\nrunning in per-user instances of the service manager.</p>",
                "User": "<p>Set the UNIX user or group that the processes are executed as, respectively. Takes a single\n        user or group name, or a numeric ID as argument. For system services (services run by the system service\n        manager, i.e. managed by PID 1) and for user services of the root user (services managed by root's instance of\n        <span class=\"command\"><strong>systemd --user</strong></span>), the default is \"<code class=\"literal\">root</code>\", but <code class=\"varname\">User=</code> may be\n        used to specify a different user. For user services of any other user, switching user identity is not\n        permitted, hence the only valid setting is the same user the user's service manager is running as. If no group\n        is set, the default group of the user is used. This setting does not affect commands whose command line is\n        prefixed with \"<code class=\"literal\">+</code>\".</p><p>Note that this enforces only weak restrictions on the user/group name syntax, but will generate\n        warnings in many cases where user/group names do not adhere to the following rules: the specified\n        name should consist only of the characters a-z, A-Z, 0-9, \"<code class=\"literal\">_</code>\" and\n        \"<code class=\"literal\">-</code>\", except for the first character which must be one of a-z, A-Z and\n        \"<code class=\"literal\">_</code>\" (i.e. digits and \"<code class=\"literal\">-</code>\" are not permitted as first character). The\n        user/group name must have at least one character, and at most 31. These restrictions are made in\n        order to avoid ambiguities and to ensure user/group names and unit files remain portable among Linux\n        systems. For further details on the names accepted and the names warned about see <a target=\"__blank\" class=\"ulink\" href=\"https://systemd.io/USER_NAMES\" target=\"_top\">User/Group Name Syntax</a>.</p><p>When used in conjunction with <code class=\"varname\">DynamicUser=</code> the user/group name specified is\n        dynamically allocated at the time the service is started, and released at the time the service is\n        stopped — unless it is already allocated statically (see below). If <code class=\"varname\">DynamicUser=</code>\n        is not used the specified user and group must have been created statically in the user database no\n        later than the moment the service is started, for example using the\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/sysusers.d.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">sysusers.d</span>(5)</span></a>\n        facility, which is applied at boot or package install time. If the user does not exist by then\n        program invocation will fail.</p><p>If the <code class=\"varname\">User=</code> setting is used the supplementary group list is initialized\n        from the specified user's default group list, as defined in the system's user and group\n        database. Additional groups may be configured through the <code class=\"varname\">SupplementaryGroups=</code>\n        setting (see below).</p>",
                "Group": "<p>Set the UNIX user or group that the processes are executed as, respectively. Takes a single\n        user or group name, or a numeric ID as argument. For system services (services run by the system service\n        manager, i.e. managed by PID 1) and for user services of the root user (services managed by root's instance of\n        <span class=\"command\"><strong>systemd --user</strong></span>), the default is \"<code class=\"literal\">root</code>\", but <code class=\"varname\">User=</code> may be\n        used to specify a different user. For user services of any other user, switching user identity is not\n        permitted, hence the only valid setting is the same user the user's service manager is running as. If no group\n        is set, the default group of the user is used. This setting does not affect commands whose command line is\n        prefixed with \"<code class=\"literal\">+</code>\".</p><p>Note that this enforces only weak restrictions on the user/group name syntax, but will generate\n        warnings in many cases where user/group names do not adhere to the following rules: the specified\n        name should consist only of the characters a-z, A-Z, 0-9, \"<code class=\"literal\">_</code>\" and\n        \"<code class=\"literal\">-</code>\", except for the first character which must be one of a-z, A-Z and\n        \"<code class=\"literal\">_</code>\" (i.e. digits and \"<code class=\"literal\">-</code>\" are not permitted as first character). The\n        user/group name must have at least one character, and at most 31. These restrictions are made in\n        order to avoid ambiguities and to ensure user/group names and unit files remain portable among Linux\n        systems. For further details on the names accepted and the names warned about see <a target=\"__blank\" class=\"ulink\" href=\"https://systemd.io/USER_NAMES\" target=\"_top\">User/Group Name Syntax</a>.</p><p>When used in conjunction with <code class=\"varname\">DynamicUser=</code> the user/group name specified is\n        dynamically allocated at the time the service is started, and released at the time the service is\n        stopped — unless it is already allocated statically (see below). If <code class=\"varname\">DynamicUser=</code>\n        is not used the specified user and group must have been created statically in the user database no\n        later than the moment the service is started, for example using the\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/sysusers.d.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">sysusers.d</span>(5)</span></a>\n        facility, which is applied at boot or package install time. If the user does not exist by then\n        program invocation will fail.</p><p>If the <code class=\"varname\">User=</code> setting is used the supplementary group list is initialized\n        from the specified user's default group list, as defined in the system's user and group\n        database. Additional groups may be configured through the <code class=\"varname\">SupplementaryGroups=</code>\n        setting (see below).</p>",
                "DynamicUser": "<p>Takes a boolean parameter. If set, a UNIX user and group pair is allocated\n        dynamically when the unit is started, and released as soon as it is stopped. The user and group will\n        not be added to <code class=\"filename\">/etc/passwd</code> or <code class=\"filename\">/etc/group</code>, but are managed\n        transiently during runtime. The\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/nss-systemd.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">nss-systemd</span>(8)</span></a> glibc\n        NSS module provides integration of these dynamic users/groups into the system's user and group\n        databases. The user and group name to use may be configured via <code class=\"varname\">User=</code> and\n        <code class=\"varname\">Group=</code> (see above). If these options are not used and dynamic user/group\n        allocation is enabled for a unit, the name of the dynamic user/group is implicitly derived from the\n        unit name. If the unit name without the type suffix qualifies as valid user name it is used directly,\n        otherwise a name incorporating a hash of it is used. If a statically allocated user or group of the\n        configured name already exists, it is used and no dynamic user/group is allocated. Note that if\n        <code class=\"varname\">User=</code> is specified and the static group with the name exists, then it is required\n        that the static user with the name already exists. Similarly, if <code class=\"varname\">Group=</code> is\n        specified and the static user with the name exists, then it is required that the static group with\n        the name already exists. Dynamic users/groups are allocated from the UID/GID range 61184…65519. It is\n        recommended to avoid this range for regular system or login users.  At any point in time each UID/GID\n        from this range is only assigned to zero or one dynamically allocated users/groups in use. However,\n        UID/GIDs are recycled after a unit is terminated. Care should be taken that any processes running as\n        part of a unit for which dynamic users/groups are enabled do not leave files or directories owned by\n        these users/groups around, as a different unit might get the same UID/GID assigned later on, and thus\n        gain access to these files or directories. If <code class=\"varname\">DynamicUser=</code> is enabled,\n        <code class=\"varname\">RemoveIPC=</code> and <code class=\"varname\">PrivateTmp=</code> are implied (and cannot be turned\n        off). This ensures that the lifetime of IPC objects and temporary files created by the executed\n        processes is bound to the runtime of the service, and hence the lifetime of the dynamic\n        user/group. Since <code class=\"filename\">/tmp/</code> and <code class=\"filename\">/var/tmp/</code> are usually the only\n        world-writable directories on a system this ensures that a unit making use of dynamic user/group\n        allocation cannot leave files around after unit termination. Furthermore\n        <code class=\"varname\">NoNewPrivileges=</code> and <code class=\"varname\">RestrictSUIDSGID=</code> are implicitly enabled\n        (and cannot be disabled), to ensure that processes invoked cannot take benefit or create SUID/SGID\n        files or directories. Moreover <code class=\"varname\">ProtectSystem=strict</code> and\n        <code class=\"varname\">ProtectHome=read-only</code> are implied, thus prohibiting the service to write to\n        arbitrary file system locations. In order to allow the service to write to certain directories, they\n        have to be allow-listed using <code class=\"varname\">ReadWritePaths=</code>, but care must be taken so that\n        UID/GID recycling doesn't create security issues involving files created by the service. Use\n        <code class=\"varname\">RuntimeDirectory=</code> (see below) in order to assign a writable runtime directory to a\n        service, owned by the dynamic user/group and removed automatically when the unit is terminated. Use\n        <code class=\"varname\">StateDirectory=</code>, <code class=\"varname\">CacheDirectory=</code> and\n        <code class=\"varname\">LogsDirectory=</code> in order to assign a set of writable directories for specific\n        purposes to the service in a way that they are protected from vulnerabilities due to UID reuse (see\n        below). If this option is enabled, care should be taken that the unit's processes do not get access\n        to directories outside of these explicitly configured and managed ones. Specifically, do not use\n        <code class=\"varname\">BindPaths=</code> and be careful with <code class=\"constant\">AF_UNIX</code> file descriptor\n        passing for directory file descriptors, as this would permit processes to create files or directories\n        owned by the dynamic user/group that are not subject to the lifecycle and access guarantees of the\n        service. Defaults to off.</p>",
                "SupplementaryGroups": "<p>Sets the supplementary Unix groups the processes are executed as. This takes a space-separated\n        list of group names or IDs. This option may be specified more than once, in which case all listed groups are\n        set as supplementary groups. When the empty string is assigned, the list of supplementary groups is reset, and\n        all assignments prior to this one will have no effect. In any way, this option does not override, but extends\n        the list of supplementary groups configured in the system group database for the user. This does not affect\n        commands prefixed with \"<code class=\"literal\">+</code>\".</p>",
                "PAMName": "<p>Sets the PAM service name to set up a session as. If set, the executed process will be\n        registered as a PAM session under the specified service name. This is only useful in conjunction with the\n        <code class=\"varname\">User=</code> setting, and is otherwise ignored. If not set, no PAM session will be opened for the\n        executed processes. See <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man8/pam.8.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">pam</span>(8)</span></a> for\n        details.</p><p>Note that for each unit making use of this option a PAM session handler process will be maintained as\n        part of the unit and stays around as long as the unit is active, to ensure that appropriate actions can be\n        taken when the unit and hence the PAM session terminates. This process is named \"<code class=\"literal\">(sd-pam)</code>\" and\n        is an immediate child process of the unit's main process.</p><p>Note that when this option is used for a unit it is very likely (depending on PAM configuration) that the\n        main unit process will be migrated to its own session scope unit when it is activated. This process will hence\n        be associated with two units: the unit it was originally started from (and for which\n        <code class=\"varname\">PAMName=</code> was configured), and the session scope unit. Any child processes of that process\n        will however be associated with the session scope unit only. This has implications when used in combination\n        with <code class=\"varname\">NotifyAccess=</code><code class=\"option\">all</code>, as these child processes will not be able to affect\n        changes in the original unit through notification messages. These messages will be considered belonging to the\n        session scope unit and not the original unit. It is hence not recommended to use <code class=\"varname\">PAMName=</code> in\n        combination with <code class=\"varname\">NotifyAccess=</code><code class=\"option\">all</code>.</p>",
                "CapabilityBoundingSet": "<p>Controls which capabilities to include in the capability bounding set for the executed\n        process. See <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/capabilities.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">capabilities</span>(7)</span></a> for\n        details. Takes a whitespace-separated list of capability names, e.g. <code class=\"constant\">CAP_SYS_ADMIN</code>,\n        <code class=\"constant\">CAP_DAC_OVERRIDE</code>, <code class=\"constant\">CAP_SYS_PTRACE</code>. Capabilities listed will be\n        included in the bounding set, all others are removed. If the list of capabilities is prefixed with\n        \"<code class=\"literal\">~</code>\", all but the listed capabilities will be included, the effect of the assignment\n        inverted. Note that this option also affects the respective capabilities in the effective, permitted and\n        inheritable capability sets. If this option is not used, the capability bounding set is not modified on process\n        execution, hence no limits on the capabilities of the process are enforced. This option may appear more than\n        once, in which case the bounding sets are merged by <code class=\"constant\">OR</code>, or by <code class=\"constant\">AND</code> if\n        the lines are prefixed with \"<code class=\"literal\">~</code>\" (see below). If the empty string is assigned to this option,\n        the bounding set is reset to the empty capability set, and all prior settings have no effect.  If set to\n        \"<code class=\"literal\">~</code>\" (without any further argument), the bounding set is reset to the full set of available\n        capabilities, also undoing any previous settings. This does not affect commands prefixed with\n        \"<code class=\"literal\">+</code>\".</p><p>Example: if a unit has the following,\n        </p><pre class=\"programlisting\">CapabilityBoundingSet=CAP_A CAP_B\nCapabilityBoundingSet=CAP_B CAP_C</pre><p>\n        then <code class=\"constant\">CAP_A</code>, <code class=\"constant\">CAP_B</code>, and\n        <code class=\"constant\">CAP_C</code> are set.  If the second line is prefixed with\n        \"<code class=\"literal\">~</code>\", e.g.,\n        </p><pre class=\"programlisting\">CapabilityBoundingSet=CAP_A CAP_B\nCapabilityBoundingSet=~CAP_B CAP_C</pre><p>\n        then, only <code class=\"constant\">CAP_A</code> is set.</p>",
                "AmbientCapabilities": "<p>Controls which capabilities to include in the ambient capability set for the executed\n        process. Takes a whitespace-separated list of capability names, e.g. <code class=\"constant\">CAP_SYS_ADMIN</code>,\n        <code class=\"constant\">CAP_DAC_OVERRIDE</code>, <code class=\"constant\">CAP_SYS_PTRACE</code>. This option may appear more than\n        once in which case the ambient capability sets are merged (see the above examples in\n        <code class=\"varname\">CapabilityBoundingSet=</code>). If the list of capabilities is prefixed with \"<code class=\"literal\">~</code>\",\n        all but the listed capabilities will be included, the effect of the assignment inverted. If the empty string is\n        assigned to this option, the ambient capability set is reset to the empty capability set, and all prior\n        settings have no effect.  If set to \"<code class=\"literal\">~</code>\" (without any further argument), the ambient capability\n        set is reset to the full set of available capabilities, also undoing any previous settings. Note that adding\n        capabilities to ambient capability set adds them to the process's inherited capability set.  </p><p>\n        Ambient capability sets are useful if you want to execute a process as a non-privileged user but still want to\n        give it some capabilities.  Note that in this case option <code class=\"constant\">keep-caps</code> is automatically added\n        to <code class=\"varname\">SecureBits=</code> to retain the capabilities over the user\n        change. <code class=\"varname\">AmbientCapabilities=</code> does not affect commands prefixed with\n        \"<code class=\"literal\">+</code>\".</p>",
                "NoNewPrivileges": "<p>Takes a boolean argument. If true, ensures that the service process and all its\n        children can never gain new privileges through <code class=\"function\">execve()</code> (e.g. via setuid or\n        setgid bits, or filesystem capabilities). This is the simplest and most effective way to ensure that\n        a process and its children can never elevate privileges again. Defaults to false, but certain\n        settings override this and ignore the value of this setting.  This is the case when\n        <code class=\"varname\">SystemCallFilter=</code>, <code class=\"varname\">SystemCallArchitectures=</code>,\n        <code class=\"varname\">RestrictAddressFamilies=</code>, <code class=\"varname\">RestrictNamespaces=</code>,\n        <code class=\"varname\">PrivateDevices=</code>, <code class=\"varname\">ProtectKernelTunables=</code>,\n        <code class=\"varname\">ProtectKernelModules=</code>, <code class=\"varname\">ProtectKernelLogs=</code>,\n        <code class=\"varname\">ProtectClock=</code>, <code class=\"varname\">MemoryDenyWriteExecute=</code>,\n        <code class=\"varname\">RestrictRealtime=</code>, <code class=\"varname\">RestrictSUIDSGID=</code>, <code class=\"varname\">DynamicUser=</code>\n        or <code class=\"varname\">LockPersonality=</code> are specified. Note that even if this setting is overridden by them,\n        <span class=\"command\"><strong>systemctl show</strong></span> shows the original value of this setting.\n        Also see <a target=\"__blank\" class=\"ulink\" href=\"https://www.kernel.org/doc/html/latest/userspace-api/no_new_privs.html\" target=\"_top\">No New Privileges\n        Flag</a>.</p>",
                "SecureBits": "<p>Controls the secure bits set for the executed process. Takes a space-separated combination of\n        options from the following list: <code class=\"option\">keep-caps</code>, <code class=\"option\">keep-caps-locked</code>,\n        <code class=\"option\">no-setuid-fixup</code>, <code class=\"option\">no-setuid-fixup-locked</code>, <code class=\"option\">noroot</code>, and\n        <code class=\"option\">noroot-locked</code>.  This option may appear more than once, in which case the secure bits are\n        ORed. If the empty string is assigned to this option, the bits are reset to 0. This does not affect commands\n        prefixed with \"<code class=\"literal\">+</code>\".  See <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/capabilities.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">capabilities</span>(7)</span></a> for\n        details.</p>",
                "SELinuxContext": "<p>Set the SELinux security context of the executed process. If set, this will override the\n        automated domain transition. However, the policy still needs to authorize the transition. This directive is\n        ignored if SELinux is disabled. If prefixed by \"<code class=\"literal\">-</code>\", all errors will be ignored. This does not\n        affect commands prefixed with \"<code class=\"literal\">+</code>\".  See <a target=\"__blank\" href=\"http://linux.die.net/man/3/setexeccon\"><span class=\"citerefentry\"><span class=\"refentrytitle\">setexeccon</span>(3)</span></a> for\n        details.</p>",
                "AppArmorProfile": "<p>Takes a profile name as argument. The process executed by the unit will switch to\n        this profile when started. Profiles must already be loaded in the kernel, or the unit will fail. If\n        prefixed by \"<code class=\"literal\">-</code>\", all errors will be ignored. This setting has no effect if AppArmor\n        is not enabled. This setting not affect commands prefixed with \"<code class=\"literal\">+</code>\".</p>",
                "SmackProcessLabel": "<p>Takes a <code class=\"option\">SMACK64</code> security label as argument. The process executed by the unit\n        will be started under this label and SMACK will decide whether the process is allowed to run or not, based on\n        it. The process will continue to run under the label specified here unless the executable has its own\n        <code class=\"option\">SMACK64EXEC</code> label, in which case the process will transition to run under that label. When not\n        specified, the label that systemd is running under is used. This directive is ignored if SMACK is\n        disabled.</p><p>The value may be prefixed by \"<code class=\"literal\">-</code>\", in which case all errors will be ignored. An empty\n        value may be specified to unset previous assignments. This does not affect commands prefixed with\n        \"<code class=\"literal\">+</code>\".</p>",
                "LimitCPU": "<p>Set soft and hard limits on various resources for executed processes. See\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/setrlimit.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">setrlimit</span>(2)</span></a> for\n        details on the resource limit concept. Resource limits may be specified in two formats: either as\n        single value to set a specific soft and hard limit to the same value, or as colon-separated pair\n        <code class=\"option\">soft:hard</code> to set both limits individually (e.g. \"<code class=\"literal\">LimitAS=4G:16G</code>\").\n        Use the string <code class=\"option\">infinity</code> to configure no limit on a specific resource. The\n        multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits\n        measured in bytes (e.g. \"<code class=\"literal\">LimitAS=16G</code>\"). For the limits referring to time values, the\n        usual time units ms, s, min, h and so on may be used (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.time.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.time</span>(7)</span></a> for\n        details). Note that if no time unit is specified for <code class=\"varname\">LimitCPU=</code> the default unit of\n        seconds is implied, while for <code class=\"varname\">LimitRTTIME=</code> the default unit of microseconds is\n        implied. Also, note that the effective granularity of the limits might influence their\n        enforcement. For example, time limits specified for <code class=\"varname\">LimitCPU=</code> will be rounded up\n        implicitly to multiples of 1s. For <code class=\"varname\">LimitNICE=</code> the value may be specified in two\n        syntaxes: if prefixed with \"<code class=\"literal\">+</code>\" or \"<code class=\"literal\">-</code>\", the value is understood as\n        regular Linux nice value in the range -20..19. If not prefixed like this the value is understood as\n        raw resource limit parameter in the range 0..40 (with 0 being equivalent to 1).</p><p>Note that most process resource limits configured with these options are per-process, and\n        processes may fork in order to acquire a new set of resources that are accounted independently of the\n        original process, and may thus escape limits set. Also note that <code class=\"varname\">LimitRSS=</code> is not\n        implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource\n        controls listed in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.resource-control</span>(5)</span></a>\n        over these per-process limits, as they apply to services as a whole, may be altered dynamically at\n        runtime, and are generally more expressive. For example, <code class=\"varname\">MemoryMax=</code> is a more\n        powerful (and working) replacement for <code class=\"varname\">LimitRSS=</code>.</p><p>Resource limits not configured explicitly for a unit default to the value configured in the various\n        <code class=\"varname\">DefaultLimitCPU=</code>, <code class=\"varname\">DefaultLimitFSIZE=</code>, … options available in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd-system.conf</span>(5)</span></a>, and –\n        if not configured there – the kernel or per-user defaults, as defined by the OS (the latter only for user\n        services, see below).</p><p>For system units these resource limits may be chosen freely. When these settings are configured\n        in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be\n        used to raise the limits above those set for the user manager itself when it was first invoked, as\n        the user's service manager generally lacks the privileges to do so. In user context these\n        configuration options are hence only useful to lower the limits passed in or to raise the soft limit\n        to the maximum of the hard limit as configured for the user. To raise the user's limits further, the\n        available configuration mechanisms differ between operating systems, but typically require\n        privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by\n        setting limits on the system service encapsulating the user's service manager, i.e. the user's\n        instance of <code class=\"filename\">user@.service</code>. After making such changes, make sure to restart the\n        user's service manager.</p><div class=\"table\"><a target=\"__blank\" name=\"id-1.12.2.1.17.5\"></a><p class=\"title\"><b>Table&nbsp;1.&nbsp;Resource limit directives, their equivalent <span class=\"command\">ulimit</span> shell commands and the unit used</b></p><div class=\"table-contents\"><table class=\"table\" summary=\"Resource limit directives, their equivalent ulimit shell commands and the unit used\" border=\"1\"><colgroup><col class=\"directive\"><col class=\"equivalent\"><col class=\"unit\"></colgroup><thead><tr><th>Directive</th><th><span class=\"command\"><strong>ulimit</strong></span> equivalent</th><th>Unit</th></tr></thead><tbody><tr><td>LimitCPU=</td><td>ulimit -t</td><td>Seconds</td></tr><tr><td>LimitFSIZE=</td><td>ulimit -f</td><td>Bytes</td></tr><tr><td>LimitDATA=</td><td>ulimit -d</td><td>Bytes</td></tr><tr><td>LimitSTACK=</td><td>ulimit -s</td><td>Bytes</td></tr><tr><td>LimitCORE=</td><td>ulimit -c</td><td>Bytes</td></tr><tr><td>LimitRSS=</td><td>ulimit -m</td><td>Bytes</td></tr><tr><td>LimitNOFILE=</td><td>ulimit -n</td><td>Number of File Descriptors</td></tr><tr><td>LimitAS=</td><td>ulimit -v</td><td>Bytes</td></tr><tr><td>LimitNPROC=</td><td>ulimit -u</td><td>Number of Processes</td></tr><tr><td>LimitMEMLOCK=</td><td>ulimit -l</td><td>Bytes</td></tr><tr><td>LimitLOCKS=</td><td>ulimit -x</td><td>Number of Locks</td></tr><tr><td>LimitSIGPENDING=</td><td>ulimit -i</td><td>Number of Queued Signals</td></tr><tr><td>LimitMSGQUEUE=</td><td>ulimit -q</td><td>Bytes</td></tr><tr><td>LimitNICE=</td><td>ulimit -e</td><td>Nice Level</td></tr><tr><td>LimitRTPRIO=</td><td>ulimit -r</td><td>Realtime Priority</td></tr><tr><td>LimitRTTIME=</td><td>No equivalent</td><td>Microseconds</td></tr></tbody></table></div></div><br class=\"table-break\">",
                "LimitFSIZE": "<p>Set soft and hard limits on various resources for executed processes. See\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/setrlimit.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">setrlimit</span>(2)</span></a> for\n        details on the resource limit concept. Resource limits may be specified in two formats: either as\n        single value to set a specific soft and hard limit to the same value, or as colon-separated pair\n        <code class=\"option\">soft:hard</code> to set both limits individually (e.g. \"<code class=\"literal\">LimitAS=4G:16G</code>\").\n        Use the string <code class=\"option\">infinity</code> to configure no limit on a specific resource. The\n        multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits\n        measured in bytes (e.g. \"<code class=\"literal\">LimitAS=16G</code>\"). For the limits referring to time values, the\n        usual time units ms, s, min, h and so on may be used (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.time.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.time</span>(7)</span></a> for\n        details). Note that if no time unit is specified for <code class=\"varname\">LimitCPU=</code> the default unit of\n        seconds is implied, while for <code class=\"varname\">LimitRTTIME=</code> the default unit of microseconds is\n        implied. Also, note that the effective granularity of the limits might influence their\n        enforcement. For example, time limits specified for <code class=\"varname\">LimitCPU=</code> will be rounded up\n        implicitly to multiples of 1s. For <code class=\"varname\">LimitNICE=</code> the value may be specified in two\n        syntaxes: if prefixed with \"<code class=\"literal\">+</code>\" or \"<code class=\"literal\">-</code>\", the value is understood as\n        regular Linux nice value in the range -20..19. If not prefixed like this the value is understood as\n        raw resource limit parameter in the range 0..40 (with 0 being equivalent to 1).</p><p>Note that most process resource limits configured with these options are per-process, and\n        processes may fork in order to acquire a new set of resources that are accounted independently of the\n        original process, and may thus escape limits set. Also note that <code class=\"varname\">LimitRSS=</code> is not\n        implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource\n        controls listed in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.resource-control</span>(5)</span></a>\n        over these per-process limits, as they apply to services as a whole, may be altered dynamically at\n        runtime, and are generally more expressive. For example, <code class=\"varname\">MemoryMax=</code> is a more\n        powerful (and working) replacement for <code class=\"varname\">LimitRSS=</code>.</p><p>Resource limits not configured explicitly for a unit default to the value configured in the various\n        <code class=\"varname\">DefaultLimitCPU=</code>, <code class=\"varname\">DefaultLimitFSIZE=</code>, … options available in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd-system.conf</span>(5)</span></a>, and –\n        if not configured there – the kernel or per-user defaults, as defined by the OS (the latter only for user\n        services, see below).</p><p>For system units these resource limits may be chosen freely. When these settings are configured\n        in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be\n        used to raise the limits above those set for the user manager itself when it was first invoked, as\n        the user's service manager generally lacks the privileges to do so. In user context these\n        configuration options are hence only useful to lower the limits passed in or to raise the soft limit\n        to the maximum of the hard limit as configured for the user. To raise the user's limits further, the\n        available configuration mechanisms differ between operating systems, but typically require\n        privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by\n        setting limits on the system service encapsulating the user's service manager, i.e. the user's\n        instance of <code class=\"filename\">user@.service</code>. After making such changes, make sure to restart the\n        user's service manager.</p><div class=\"table\"><a target=\"__blank\" name=\"id-1.12.2.1.17.5\"></a><p class=\"title\"><b>Table&nbsp;1.&nbsp;Resource limit directives, their equivalent <span class=\"command\">ulimit</span> shell commands and the unit used</b></p><div class=\"table-contents\"><table class=\"table\" summary=\"Resource limit directives, their equivalent ulimit shell commands and the unit used\" border=\"1\"><colgroup><col class=\"directive\"><col class=\"equivalent\"><col class=\"unit\"></colgroup><thead><tr><th>Directive</th><th><span class=\"command\"><strong>ulimit</strong></span> equivalent</th><th>Unit</th></tr></thead><tbody><tr><td>LimitCPU=</td><td>ulimit -t</td><td>Seconds</td></tr><tr><td>LimitFSIZE=</td><td>ulimit -f</td><td>Bytes</td></tr><tr><td>LimitDATA=</td><td>ulimit -d</td><td>Bytes</td></tr><tr><td>LimitSTACK=</td><td>ulimit -s</td><td>Bytes</td></tr><tr><td>LimitCORE=</td><td>ulimit -c</td><td>Bytes</td></tr><tr><td>LimitRSS=</td><td>ulimit -m</td><td>Bytes</td></tr><tr><td>LimitNOFILE=</td><td>ulimit -n</td><td>Number of File Descriptors</td></tr><tr><td>LimitAS=</td><td>ulimit -v</td><td>Bytes</td></tr><tr><td>LimitNPROC=</td><td>ulimit -u</td><td>Number of Processes</td></tr><tr><td>LimitMEMLOCK=</td><td>ulimit -l</td><td>Bytes</td></tr><tr><td>LimitLOCKS=</td><td>ulimit -x</td><td>Number of Locks</td></tr><tr><td>LimitSIGPENDING=</td><td>ulimit -i</td><td>Number of Queued Signals</td></tr><tr><td>LimitMSGQUEUE=</td><td>ulimit -q</td><td>Bytes</td></tr><tr><td>LimitNICE=</td><td>ulimit -e</td><td>Nice Level</td></tr><tr><td>LimitRTPRIO=</td><td>ulimit -r</td><td>Realtime Priority</td></tr><tr><td>LimitRTTIME=</td><td>No equivalent</td><td>Microseconds</td></tr></tbody></table></div></div><br class=\"table-break\">",
                "LimitDATA": "<p>Set soft and hard limits on various resources for executed processes. See\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/setrlimit.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">setrlimit</span>(2)</span></a> for\n        details on the resource limit concept. Resource limits may be specified in two formats: either as\n        single value to set a specific soft and hard limit to the same value, or as colon-separated pair\n        <code class=\"option\">soft:hard</code> to set both limits individually (e.g. \"<code class=\"literal\">LimitAS=4G:16G</code>\").\n        Use the string <code class=\"option\">infinity</code> to configure no limit on a specific resource. The\n        multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits\n        measured in bytes (e.g. \"<code class=\"literal\">LimitAS=16G</code>\"). For the limits referring to time values, the\n        usual time units ms, s, min, h and so on may be used (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.time.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.time</span>(7)</span></a> for\n        details). Note that if no time unit is specified for <code class=\"varname\">LimitCPU=</code> the default unit of\n        seconds is implied, while for <code class=\"varname\">LimitRTTIME=</code> the default unit of microseconds is\n        implied. Also, note that the effective granularity of the limits might influence their\n        enforcement. For example, time limits specified for <code class=\"varname\">LimitCPU=</code> will be rounded up\n        implicitly to multiples of 1s. For <code class=\"varname\">LimitNICE=</code> the value may be specified in two\n        syntaxes: if prefixed with \"<code class=\"literal\">+</code>\" or \"<code class=\"literal\">-</code>\", the value is understood as\n        regular Linux nice value in the range -20..19. If not prefixed like this the value is understood as\n        raw resource limit parameter in the range 0..40 (with 0 being equivalent to 1).</p><p>Note that most process resource limits configured with these options are per-process, and\n        processes may fork in order to acquire a new set of resources that are accounted independently of the\n        original process, and may thus escape limits set. Also note that <code class=\"varname\">LimitRSS=</code> is not\n        implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource\n        controls listed in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.resource-control</span>(5)</span></a>\n        over these per-process limits, as they apply to services as a whole, may be altered dynamically at\n        runtime, and are generally more expressive. For example, <code class=\"varname\">MemoryMax=</code> is a more\n        powerful (and working) replacement for <code class=\"varname\">LimitRSS=</code>.</p><p>Resource limits not configured explicitly for a unit default to the value configured in the various\n        <code class=\"varname\">DefaultLimitCPU=</code>, <code class=\"varname\">DefaultLimitFSIZE=</code>, … options available in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd-system.conf</span>(5)</span></a>, and –\n        if not configured there – the kernel or per-user defaults, as defined by the OS (the latter only for user\n        services, see below).</p><p>For system units these resource limits may be chosen freely. When these settings are configured\n        in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be\n        used to raise the limits above those set for the user manager itself when it was first invoked, as\n        the user's service manager generally lacks the privileges to do so. In user context these\n        configuration options are hence only useful to lower the limits passed in or to raise the soft limit\n        to the maximum of the hard limit as configured for the user. To raise the user's limits further, the\n        available configuration mechanisms differ between operating systems, but typically require\n        privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by\n        setting limits on the system service encapsulating the user's service manager, i.e. the user's\n        instance of <code class=\"filename\">user@.service</code>. After making such changes, make sure to restart the\n        user's service manager.</p><div class=\"table\"><a target=\"__blank\" name=\"id-1.12.2.1.17.5\"></a><p class=\"title\"><b>Table&nbsp;1.&nbsp;Resource limit directives, their equivalent <span class=\"command\">ulimit</span> shell commands and the unit used</b></p><div class=\"table-contents\"><table class=\"table\" summary=\"Resource limit directives, their equivalent ulimit shell commands and the unit used\" border=\"1\"><colgroup><col class=\"directive\"><col class=\"equivalent\"><col class=\"unit\"></colgroup><thead><tr><th>Directive</th><th><span class=\"command\"><strong>ulimit</strong></span> equivalent</th><th>Unit</th></tr></thead><tbody><tr><td>LimitCPU=</td><td>ulimit -t</td><td>Seconds</td></tr><tr><td>LimitFSIZE=</td><td>ulimit -f</td><td>Bytes</td></tr><tr><td>LimitDATA=</td><td>ulimit -d</td><td>Bytes</td></tr><tr><td>LimitSTACK=</td><td>ulimit -s</td><td>Bytes</td></tr><tr><td>LimitCORE=</td><td>ulimit -c</td><td>Bytes</td></tr><tr><td>LimitRSS=</td><td>ulimit -m</td><td>Bytes</td></tr><tr><td>LimitNOFILE=</td><td>ulimit -n</td><td>Number of File Descriptors</td></tr><tr><td>LimitAS=</td><td>ulimit -v</td><td>Bytes</td></tr><tr><td>LimitNPROC=</td><td>ulimit -u</td><td>Number of Processes</td></tr><tr><td>LimitMEMLOCK=</td><td>ulimit -l</td><td>Bytes</td></tr><tr><td>LimitLOCKS=</td><td>ulimit -x</td><td>Number of Locks</td></tr><tr><td>LimitSIGPENDING=</td><td>ulimit -i</td><td>Number of Queued Signals</td></tr><tr><td>LimitMSGQUEUE=</td><td>ulimit -q</td><td>Bytes</td></tr><tr><td>LimitNICE=</td><td>ulimit -e</td><td>Nice Level</td></tr><tr><td>LimitRTPRIO=</td><td>ulimit -r</td><td>Realtime Priority</td></tr><tr><td>LimitRTTIME=</td><td>No equivalent</td><td>Microseconds</td></tr></tbody></table></div></div><br class=\"table-break\">",
                "LimitSTACK": "<p>Set soft and hard limits on various resources for executed processes. See\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/setrlimit.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">setrlimit</span>(2)</span></a> for\n        details on the resource limit concept. Resource limits may be specified in two formats: either as\n        single value to set a specific soft and hard limit to the same value, or as colon-separated pair\n        <code class=\"option\">soft:hard</code> to set both limits individually (e.g. \"<code class=\"literal\">LimitAS=4G:16G</code>\").\n        Use the string <code class=\"option\">infinity</code> to configure no limit on a specific resource. The\n        multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits\n        measured in bytes (e.g. \"<code class=\"literal\">LimitAS=16G</code>\"). For the limits referring to time values, the\n        usual time units ms, s, min, h and so on may be used (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.time.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.time</span>(7)</span></a> for\n        details). Note that if no time unit is specified for <code class=\"varname\">LimitCPU=</code> the default unit of\n        seconds is implied, while for <code class=\"varname\">LimitRTTIME=</code> the default unit of microseconds is\n        implied. Also, note that the effective granularity of the limits might influence their\n        enforcement. For example, time limits specified for <code class=\"varname\">LimitCPU=</code> will be rounded up\n        implicitly to multiples of 1s. For <code class=\"varname\">LimitNICE=</code> the value may be specified in two\n        syntaxes: if prefixed with \"<code class=\"literal\">+</code>\" or \"<code class=\"literal\">-</code>\", the value is understood as\n        regular Linux nice value in the range -20..19. If not prefixed like this the value is understood as\n        raw resource limit parameter in the range 0..40 (with 0 being equivalent to 1).</p><p>Note that most process resource limits configured with these options are per-process, and\n        processes may fork in order to acquire a new set of resources that are accounted independently of the\n        original process, and may thus escape limits set. Also note that <code class=\"varname\">LimitRSS=</code> is not\n        implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource\n        controls listed in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.resource-control</span>(5)</span></a>\n        over these per-process limits, as they apply to services as a whole, may be altered dynamically at\n        runtime, and are generally more expressive. For example, <code class=\"varname\">MemoryMax=</code> is a more\n        powerful (and working) replacement for <code class=\"varname\">LimitRSS=</code>.</p><p>Resource limits not configured explicitly for a unit default to the value configured in the various\n        <code class=\"varname\">DefaultLimitCPU=</code>, <code class=\"varname\">DefaultLimitFSIZE=</code>, … options available in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd-system.conf</span>(5)</span></a>, and –\n        if not configured there – the kernel or per-user defaults, as defined by the OS (the latter only for user\n        services, see below).</p><p>For system units these resource limits may be chosen freely. When these settings are configured\n        in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be\n        used to raise the limits above those set for the user manager itself when it was first invoked, as\n        the user's service manager generally lacks the privileges to do so. In user context these\n        configuration options are hence only useful to lower the limits passed in or to raise the soft limit\n        to the maximum of the hard limit as configured for the user. To raise the user's limits further, the\n        available configuration mechanisms differ between operating systems, but typically require\n        privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by\n        setting limits on the system service encapsulating the user's service manager, i.e. the user's\n        instance of <code class=\"filename\">user@.service</code>. After making such changes, make sure to restart the\n        user's service manager.</p><div class=\"table\"><a target=\"__blank\" name=\"id-1.12.2.1.17.5\"></a><p class=\"title\"><b>Table&nbsp;1.&nbsp;Resource limit directives, their equivalent <span class=\"command\">ulimit</span> shell commands and the unit used</b></p><div class=\"table-contents\"><table class=\"table\" summary=\"Resource limit directives, their equivalent ulimit shell commands and the unit used\" border=\"1\"><colgroup><col class=\"directive\"><col class=\"equivalent\"><col class=\"unit\"></colgroup><thead><tr><th>Directive</th><th><span class=\"command\"><strong>ulimit</strong></span> equivalent</th><th>Unit</th></tr></thead><tbody><tr><td>LimitCPU=</td><td>ulimit -t</td><td>Seconds</td></tr><tr><td>LimitFSIZE=</td><td>ulimit -f</td><td>Bytes</td></tr><tr><td>LimitDATA=</td><td>ulimit -d</td><td>Bytes</td></tr><tr><td>LimitSTACK=</td><td>ulimit -s</td><td>Bytes</td></tr><tr><td>LimitCORE=</td><td>ulimit -c</td><td>Bytes</td></tr><tr><td>LimitRSS=</td><td>ulimit -m</td><td>Bytes</td></tr><tr><td>LimitNOFILE=</td><td>ulimit -n</td><td>Number of File Descriptors</td></tr><tr><td>LimitAS=</td><td>ulimit -v</td><td>Bytes</td></tr><tr><td>LimitNPROC=</td><td>ulimit -u</td><td>Number of Processes</td></tr><tr><td>LimitMEMLOCK=</td><td>ulimit -l</td><td>Bytes</td></tr><tr><td>LimitLOCKS=</td><td>ulimit -x</td><td>Number of Locks</td></tr><tr><td>LimitSIGPENDING=</td><td>ulimit -i</td><td>Number of Queued Signals</td></tr><tr><td>LimitMSGQUEUE=</td><td>ulimit -q</td><td>Bytes</td></tr><tr><td>LimitNICE=</td><td>ulimit -e</td><td>Nice Level</td></tr><tr><td>LimitRTPRIO=</td><td>ulimit -r</td><td>Realtime Priority</td></tr><tr><td>LimitRTTIME=</td><td>No equivalent</td><td>Microseconds</td></tr></tbody></table></div></div><br class=\"table-break\">",
                "LimitCORE": "<p>Set soft and hard limits on various resources for executed processes. See\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/setrlimit.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">setrlimit</span>(2)</span></a> for\n        details on the resource limit concept. Resource limits may be specified in two formats: either as\n        single value to set a specific soft and hard limit to the same value, or as colon-separated pair\n        <code class=\"option\">soft:hard</code> to set both limits individually (e.g. \"<code class=\"literal\">LimitAS=4G:16G</code>\").\n        Use the string <code class=\"option\">infinity</code> to configure no limit on a specific resource. The\n        multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits\n        measured in bytes (e.g. \"<code class=\"literal\">LimitAS=16G</code>\"). For the limits referring to time values, the\n        usual time units ms, s, min, h and so on may be used (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.time.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.time</span>(7)</span></a> for\n        details). Note that if no time unit is specified for <code class=\"varname\">LimitCPU=</code> the default unit of\n        seconds is implied, while for <code class=\"varname\">LimitRTTIME=</code> the default unit of microseconds is\n        implied. Also, note that the effective granularity of the limits might influence their\n        enforcement. For example, time limits specified for <code class=\"varname\">LimitCPU=</code> will be rounded up\n        implicitly to multiples of 1s. For <code class=\"varname\">LimitNICE=</code> the value may be specified in two\n        syntaxes: if prefixed with \"<code class=\"literal\">+</code>\" or \"<code class=\"literal\">-</code>\", the value is understood as\n        regular Linux nice value in the range -20..19. If not prefixed like this the value is understood as\n        raw resource limit parameter in the range 0..40 (with 0 being equivalent to 1).</p><p>Note that most process resource limits configured with these options are per-process, and\n        processes may fork in order to acquire a new set of resources that are accounted independently of the\n        original process, and may thus escape limits set. Also note that <code class=\"varname\">LimitRSS=</code> is not\n        implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource\n        controls listed in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.resource-control</span>(5)</span></a>\n        over these per-process limits, as they apply to services as a whole, may be altered dynamically at\n        runtime, and are generally more expressive. For example, <code class=\"varname\">MemoryMax=</code> is a more\n        powerful (and working) replacement for <code class=\"varname\">LimitRSS=</code>.</p><p>Resource limits not configured explicitly for a unit default to the value configured in the various\n        <code class=\"varname\">DefaultLimitCPU=</code>, <code class=\"varname\">DefaultLimitFSIZE=</code>, … options available in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd-system.conf</span>(5)</span></a>, and –\n        if not configured there – the kernel or per-user defaults, as defined by the OS (the latter only for user\n        services, see below).</p><p>For system units these resource limits may be chosen freely. When these settings are configured\n        in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be\n        used to raise the limits above those set for the user manager itself when it was first invoked, as\n        the user's service manager generally lacks the privileges to do so. In user context these\n        configuration options are hence only useful to lower the limits passed in or to raise the soft limit\n        to the maximum of the hard limit as configured for the user. To raise the user's limits further, the\n        available configuration mechanisms differ between operating systems, but typically require\n        privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by\n        setting limits on the system service encapsulating the user's service manager, i.e. the user's\n        instance of <code class=\"filename\">user@.service</code>. After making such changes, make sure to restart the\n        user's service manager.</p><div class=\"table\"><a target=\"__blank\" name=\"id-1.12.2.1.17.5\"></a><p class=\"title\"><b>Table&nbsp;1.&nbsp;Resource limit directives, their equivalent <span class=\"command\">ulimit</span> shell commands and the unit used</b></p><div class=\"table-contents\"><table class=\"table\" summary=\"Resource limit directives, their equivalent ulimit shell commands and the unit used\" border=\"1\"><colgroup><col class=\"directive\"><col class=\"equivalent\"><col class=\"unit\"></colgroup><thead><tr><th>Directive</th><th><span class=\"command\"><strong>ulimit</strong></span> equivalent</th><th>Unit</th></tr></thead><tbody><tr><td>LimitCPU=</td><td>ulimit -t</td><td>Seconds</td></tr><tr><td>LimitFSIZE=</td><td>ulimit -f</td><td>Bytes</td></tr><tr><td>LimitDATA=</td><td>ulimit -d</td><td>Bytes</td></tr><tr><td>LimitSTACK=</td><td>ulimit -s</td><td>Bytes</td></tr><tr><td>LimitCORE=</td><td>ulimit -c</td><td>Bytes</td></tr><tr><td>LimitRSS=</td><td>ulimit -m</td><td>Bytes</td></tr><tr><td>LimitNOFILE=</td><td>ulimit -n</td><td>Number of File Descriptors</td></tr><tr><td>LimitAS=</td><td>ulimit -v</td><td>Bytes</td></tr><tr><td>LimitNPROC=</td><td>ulimit -u</td><td>Number of Processes</td></tr><tr><td>LimitMEMLOCK=</td><td>ulimit -l</td><td>Bytes</td></tr><tr><td>LimitLOCKS=</td><td>ulimit -x</td><td>Number of Locks</td></tr><tr><td>LimitSIGPENDING=</td><td>ulimit -i</td><td>Number of Queued Signals</td></tr><tr><td>LimitMSGQUEUE=</td><td>ulimit -q</td><td>Bytes</td></tr><tr><td>LimitNICE=</td><td>ulimit -e</td><td>Nice Level</td></tr><tr><td>LimitRTPRIO=</td><td>ulimit -r</td><td>Realtime Priority</td></tr><tr><td>LimitRTTIME=</td><td>No equivalent</td><td>Microseconds</td></tr></tbody></table></div></div><br class=\"table-break\">",
                "LimitRSS": "<p>Set soft and hard limits on various resources for executed processes. See\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/setrlimit.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">setrlimit</span>(2)</span></a> for\n        details on the resource limit concept. Resource limits may be specified in two formats: either as\n        single value to set a specific soft and hard limit to the same value, or as colon-separated pair\n        <code class=\"option\">soft:hard</code> to set both limits individually (e.g. \"<code class=\"literal\">LimitAS=4G:16G</code>\").\n        Use the string <code class=\"option\">infinity</code> to configure no limit on a specific resource. The\n        multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits\n        measured in bytes (e.g. \"<code class=\"literal\">LimitAS=16G</code>\"). For the limits referring to time values, the\n        usual time units ms, s, min, h and so on may be used (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.time.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.time</span>(7)</span></a> for\n        details). Note that if no time unit is specified for <code class=\"varname\">LimitCPU=</code> the default unit of\n        seconds is implied, while for <code class=\"varname\">LimitRTTIME=</code> the default unit of microseconds is\n        implied. Also, note that the effective granularity of the limits might influence their\n        enforcement. For example, time limits specified for <code class=\"varname\">LimitCPU=</code> will be rounded up\n        implicitly to multiples of 1s. For <code class=\"varname\">LimitNICE=</code> the value may be specified in two\n        syntaxes: if prefixed with \"<code class=\"literal\">+</code>\" or \"<code class=\"literal\">-</code>\", the value is understood as\n        regular Linux nice value in the range -20..19. If not prefixed like this the value is understood as\n        raw resource limit parameter in the range 0..40 (with 0 being equivalent to 1).</p><p>Note that most process resource limits configured with these options are per-process, and\n        processes may fork in order to acquire a new set of resources that are accounted independently of the\n        original process, and may thus escape limits set. Also note that <code class=\"varname\">LimitRSS=</code> is not\n        implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource\n        controls listed in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.resource-control</span>(5)</span></a>\n        over these per-process limits, as they apply to services as a whole, may be altered dynamically at\n        runtime, and are generally more expressive. For example, <code class=\"varname\">MemoryMax=</code> is a more\n        powerful (and working) replacement for <code class=\"varname\">LimitRSS=</code>.</p><p>Resource limits not configured explicitly for a unit default to the value configured in the various\n        <code class=\"varname\">DefaultLimitCPU=</code>, <code class=\"varname\">DefaultLimitFSIZE=</code>, … options available in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd-system.conf</span>(5)</span></a>, and –\n        if not configured there – the kernel or per-user defaults, as defined by the OS (the latter only for user\n        services, see below).</p><p>For system units these resource limits may be chosen freely. When these settings are configured\n        in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be\n        used to raise the limits above those set for the user manager itself when it was first invoked, as\n        the user's service manager generally lacks the privileges to do so. In user context these\n        configuration options are hence only useful to lower the limits passed in or to raise the soft limit\n        to the maximum of the hard limit as configured for the user. To raise the user's limits further, the\n        available configuration mechanisms differ between operating systems, but typically require\n        privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by\n        setting limits on the system service encapsulating the user's service manager, i.e. the user's\n        instance of <code class=\"filename\">user@.service</code>. After making such changes, make sure to restart the\n        user's service manager.</p><div class=\"table\"><a target=\"__blank\" name=\"id-1.12.2.1.17.5\"></a><p class=\"title\"><b>Table&nbsp;1.&nbsp;Resource limit directives, their equivalent <span class=\"command\">ulimit</span> shell commands and the unit used</b></p><div class=\"table-contents\"><table class=\"table\" summary=\"Resource limit directives, their equivalent ulimit shell commands and the unit used\" border=\"1\"><colgroup><col class=\"directive\"><col class=\"equivalent\"><col class=\"unit\"></colgroup><thead><tr><th>Directive</th><th><span class=\"command\"><strong>ulimit</strong></span> equivalent</th><th>Unit</th></tr></thead><tbody><tr><td>LimitCPU=</td><td>ulimit -t</td><td>Seconds</td></tr><tr><td>LimitFSIZE=</td><td>ulimit -f</td><td>Bytes</td></tr><tr><td>LimitDATA=</td><td>ulimit -d</td><td>Bytes</td></tr><tr><td>LimitSTACK=</td><td>ulimit -s</td><td>Bytes</td></tr><tr><td>LimitCORE=</td><td>ulimit -c</td><td>Bytes</td></tr><tr><td>LimitRSS=</td><td>ulimit -m</td><td>Bytes</td></tr><tr><td>LimitNOFILE=</td><td>ulimit -n</td><td>Number of File Descriptors</td></tr><tr><td>LimitAS=</td><td>ulimit -v</td><td>Bytes</td></tr><tr><td>LimitNPROC=</td><td>ulimit -u</td><td>Number of Processes</td></tr><tr><td>LimitMEMLOCK=</td><td>ulimit -l</td><td>Bytes</td></tr><tr><td>LimitLOCKS=</td><td>ulimit -x</td><td>Number of Locks</td></tr><tr><td>LimitSIGPENDING=</td><td>ulimit -i</td><td>Number of Queued Signals</td></tr><tr><td>LimitMSGQUEUE=</td><td>ulimit -q</td><td>Bytes</td></tr><tr><td>LimitNICE=</td><td>ulimit -e</td><td>Nice Level</td></tr><tr><td>LimitRTPRIO=</td><td>ulimit -r</td><td>Realtime Priority</td></tr><tr><td>LimitRTTIME=</td><td>No equivalent</td><td>Microseconds</td></tr></tbody></table></div></div><br class=\"table-break\">",
                "LimitNOFILE": "<p>Set soft and hard limits on various resources for executed processes. See\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/setrlimit.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">setrlimit</span>(2)</span></a> for\n        details on the resource limit concept. Resource limits may be specified in two formats: either as\n        single value to set a specific soft and hard limit to the same value, or as colon-separated pair\n        <code class=\"option\">soft:hard</code> to set both limits individually (e.g. \"<code class=\"literal\">LimitAS=4G:16G</code>\").\n        Use the string <code class=\"option\">infinity</code> to configure no limit on a specific resource. The\n        multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits\n        measured in bytes (e.g. \"<code class=\"literal\">LimitAS=16G</code>\"). For the limits referring to time values, the\n        usual time units ms, s, min, h and so on may be used (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.time.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.time</span>(7)</span></a> for\n        details). Note that if no time unit is specified for <code class=\"varname\">LimitCPU=</code> the default unit of\n        seconds is implied, while for <code class=\"varname\">LimitRTTIME=</code> the default unit of microseconds is\n        implied. Also, note that the effective granularity of the limits might influence their\n        enforcement. For example, time limits specified for <code class=\"varname\">LimitCPU=</code> will be rounded up\n        implicitly to multiples of 1s. For <code class=\"varname\">LimitNICE=</code> the value may be specified in two\n        syntaxes: if prefixed with \"<code class=\"literal\">+</code>\" or \"<code class=\"literal\">-</code>\", the value is understood as\n        regular Linux nice value in the range -20..19. If not prefixed like this the value is understood as\n        raw resource limit parameter in the range 0..40 (with 0 being equivalent to 1).</p><p>Note that most process resource limits configured with these options are per-process, and\n        processes may fork in order to acquire a new set of resources that are accounted independently of the\n        original process, and may thus escape limits set. Also note that <code class=\"varname\">LimitRSS=</code> is not\n        implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource\n        controls listed in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.resource-control</span>(5)</span></a>\n        over these per-process limits, as they apply to services as a whole, may be altered dynamically at\n        runtime, and are generally more expressive. For example, <code class=\"varname\">MemoryMax=</code> is a more\n        powerful (and working) replacement for <code class=\"varname\">LimitRSS=</code>.</p><p>Resource limits not configured explicitly for a unit default to the value configured in the various\n        <code class=\"varname\">DefaultLimitCPU=</code>, <code class=\"varname\">DefaultLimitFSIZE=</code>, … options available in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd-system.conf</span>(5)</span></a>, and –\n        if not configured there – the kernel or per-user defaults, as defined by the OS (the latter only for user\n        services, see below).</p><p>For system units these resource limits may be chosen freely. When these settings are configured\n        in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be\n        used to raise the limits above those set for the user manager itself when it was first invoked, as\n        the user's service manager generally lacks the privileges to do so. In user context these\n        configuration options are hence only useful to lower the limits passed in or to raise the soft limit\n        to the maximum of the hard limit as configured for the user. To raise the user's limits further, the\n        available configuration mechanisms differ between operating systems, but typically require\n        privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by\n        setting limits on the system service encapsulating the user's service manager, i.e. the user's\n        instance of <code class=\"filename\">user@.service</code>. After making such changes, make sure to restart the\n        user's service manager.</p><div class=\"table\"><a target=\"__blank\" name=\"id-1.12.2.1.17.5\"></a><p class=\"title\"><b>Table&nbsp;1.&nbsp;Resource limit directives, their equivalent <span class=\"command\">ulimit</span> shell commands and the unit used</b></p><div class=\"table-contents\"><table class=\"table\" summary=\"Resource limit directives, their equivalent ulimit shell commands and the unit used\" border=\"1\"><colgroup><col class=\"directive\"><col class=\"equivalent\"><col class=\"unit\"></colgroup><thead><tr><th>Directive</th><th><span class=\"command\"><strong>ulimit</strong></span> equivalent</th><th>Unit</th></tr></thead><tbody><tr><td>LimitCPU=</td><td>ulimit -t</td><td>Seconds</td></tr><tr><td>LimitFSIZE=</td><td>ulimit -f</td><td>Bytes</td></tr><tr><td>LimitDATA=</td><td>ulimit -d</td><td>Bytes</td></tr><tr><td>LimitSTACK=</td><td>ulimit -s</td><td>Bytes</td></tr><tr><td>LimitCORE=</td><td>ulimit -c</td><td>Bytes</td></tr><tr><td>LimitRSS=</td><td>ulimit -m</td><td>Bytes</td></tr><tr><td>LimitNOFILE=</td><td>ulimit -n</td><td>Number of File Descriptors</td></tr><tr><td>LimitAS=</td><td>ulimit -v</td><td>Bytes</td></tr><tr><td>LimitNPROC=</td><td>ulimit -u</td><td>Number of Processes</td></tr><tr><td>LimitMEMLOCK=</td><td>ulimit -l</td><td>Bytes</td></tr><tr><td>LimitLOCKS=</td><td>ulimit -x</td><td>Number of Locks</td></tr><tr><td>LimitSIGPENDING=</td><td>ulimit -i</td><td>Number of Queued Signals</td></tr><tr><td>LimitMSGQUEUE=</td><td>ulimit -q</td><td>Bytes</td></tr><tr><td>LimitNICE=</td><td>ulimit -e</td><td>Nice Level</td></tr><tr><td>LimitRTPRIO=</td><td>ulimit -r</td><td>Realtime Priority</td></tr><tr><td>LimitRTTIME=</td><td>No equivalent</td><td>Microseconds</td></tr></tbody></table></div></div><br class=\"table-break\">",
                "LimitAS": "<p>Set soft and hard limits on various resources for executed processes. See\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/setrlimit.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">setrlimit</span>(2)</span></a> for\n        details on the resource limit concept. Resource limits may be specified in two formats: either as\n        single value to set a specific soft and hard limit to the same value, or as colon-separated pair\n        <code class=\"option\">soft:hard</code> to set both limits individually (e.g. \"<code class=\"literal\">LimitAS=4G:16G</code>\").\n        Use the string <code class=\"option\">infinity</code> to configure no limit on a specific resource. The\n        multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits\n        measured in bytes (e.g. \"<code class=\"literal\">LimitAS=16G</code>\"). For the limits referring to time values, the\n        usual time units ms, s, min, h and so on may be used (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.time.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.time</span>(7)</span></a> for\n        details). Note that if no time unit is specified for <code class=\"varname\">LimitCPU=</code> the default unit of\n        seconds is implied, while for <code class=\"varname\">LimitRTTIME=</code> the default unit of microseconds is\n        implied. Also, note that the effective granularity of the limits might influence their\n        enforcement. For example, time limits specified for <code class=\"varname\">LimitCPU=</code> will be rounded up\n        implicitly to multiples of 1s. For <code class=\"varname\">LimitNICE=</code> the value may be specified in two\n        syntaxes: if prefixed with \"<code class=\"literal\">+</code>\" or \"<code class=\"literal\">-</code>\", the value is understood as\n        regular Linux nice value in the range -20..19. If not prefixed like this the value is understood as\n        raw resource limit parameter in the range 0..40 (with 0 being equivalent to 1).</p><p>Note that most process resource limits configured with these options are per-process, and\n        processes may fork in order to acquire a new set of resources that are accounted independently of the\n        original process, and may thus escape limits set. Also note that <code class=\"varname\">LimitRSS=</code> is not\n        implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource\n        controls listed in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.resource-control</span>(5)</span></a>\n        over these per-process limits, as they apply to services as a whole, may be altered dynamically at\n        runtime, and are generally more expressive. For example, <code class=\"varname\">MemoryMax=</code> is a more\n        powerful (and working) replacement for <code class=\"varname\">LimitRSS=</code>.</p><p>Resource limits not configured explicitly for a unit default to the value configured in the various\n        <code class=\"varname\">DefaultLimitCPU=</code>, <code class=\"varname\">DefaultLimitFSIZE=</code>, … options available in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd-system.conf</span>(5)</span></a>, and –\n        if not configured there – the kernel or per-user defaults, as defined by the OS (the latter only for user\n        services, see below).</p><p>For system units these resource limits may be chosen freely. When these settings are configured\n        in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be\n        used to raise the limits above those set for the user manager itself when it was first invoked, as\n        the user's service manager generally lacks the privileges to do so. In user context these\n        configuration options are hence only useful to lower the limits passed in or to raise the soft limit\n        to the maximum of the hard limit as configured for the user. To raise the user's limits further, the\n        available configuration mechanisms differ between operating systems, but typically require\n        privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by\n        setting limits on the system service encapsulating the user's service manager, i.e. the user's\n        instance of <code class=\"filename\">user@.service</code>. After making such changes, make sure to restart the\n        user's service manager.</p><div class=\"table\"><a target=\"__blank\" name=\"id-1.12.2.1.17.5\"></a><p class=\"title\"><b>Table&nbsp;1.&nbsp;Resource limit directives, their equivalent <span class=\"command\">ulimit</span> shell commands and the unit used</b></p><div class=\"table-contents\"><table class=\"table\" summary=\"Resource limit directives, their equivalent ulimit shell commands and the unit used\" border=\"1\"><colgroup><col class=\"directive\"><col class=\"equivalent\"><col class=\"unit\"></colgroup><thead><tr><th>Directive</th><th><span class=\"command\"><strong>ulimit</strong></span> equivalent</th><th>Unit</th></tr></thead><tbody><tr><td>LimitCPU=</td><td>ulimit -t</td><td>Seconds</td></tr><tr><td>LimitFSIZE=</td><td>ulimit -f</td><td>Bytes</td></tr><tr><td>LimitDATA=</td><td>ulimit -d</td><td>Bytes</td></tr><tr><td>LimitSTACK=</td><td>ulimit -s</td><td>Bytes</td></tr><tr><td>LimitCORE=</td><td>ulimit -c</td><td>Bytes</td></tr><tr><td>LimitRSS=</td><td>ulimit -m</td><td>Bytes</td></tr><tr><td>LimitNOFILE=</td><td>ulimit -n</td><td>Number of File Descriptors</td></tr><tr><td>LimitAS=</td><td>ulimit -v</td><td>Bytes</td></tr><tr><td>LimitNPROC=</td><td>ulimit -u</td><td>Number of Processes</td></tr><tr><td>LimitMEMLOCK=</td><td>ulimit -l</td><td>Bytes</td></tr><tr><td>LimitLOCKS=</td><td>ulimit -x</td><td>Number of Locks</td></tr><tr><td>LimitSIGPENDING=</td><td>ulimit -i</td><td>Number of Queued Signals</td></tr><tr><td>LimitMSGQUEUE=</td><td>ulimit -q</td><td>Bytes</td></tr><tr><td>LimitNICE=</td><td>ulimit -e</td><td>Nice Level</td></tr><tr><td>LimitRTPRIO=</td><td>ulimit -r</td><td>Realtime Priority</td></tr><tr><td>LimitRTTIME=</td><td>No equivalent</td><td>Microseconds</td></tr></tbody></table></div></div><br class=\"table-break\">",
                "LimitNPROC": "<p>Set soft and hard limits on various resources for executed processes. See\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/setrlimit.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">setrlimit</span>(2)</span></a> for\n        details on the resource limit concept. Resource limits may be specified in two formats: either as\n        single value to set a specific soft and hard limit to the same value, or as colon-separated pair\n        <code class=\"option\">soft:hard</code> to set both limits individually (e.g. \"<code class=\"literal\">LimitAS=4G:16G</code>\").\n        Use the string <code class=\"option\">infinity</code> to configure no limit on a specific resource. The\n        multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits\n        measured in bytes (e.g. \"<code class=\"literal\">LimitAS=16G</code>\"). For the limits referring to time values, the\n        usual time units ms, s, min, h and so on may be used (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.time.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.time</span>(7)</span></a> for\n        details). Note that if no time unit is specified for <code class=\"varname\">LimitCPU=</code> the default unit of\n        seconds is implied, while for <code class=\"varname\">LimitRTTIME=</code> the default unit of microseconds is\n        implied. Also, note that the effective granularity of the limits might influence their\n        enforcement. For example, time limits specified for <code class=\"varname\">LimitCPU=</code> will be rounded up\n        implicitly to multiples of 1s. For <code class=\"varname\">LimitNICE=</code> the value may be specified in two\n        syntaxes: if prefixed with \"<code class=\"literal\">+</code>\" or \"<code class=\"literal\">-</code>\", the value is understood as\n        regular Linux nice value in the range -20..19. If not prefixed like this the value is understood as\n        raw resource limit parameter in the range 0..40 (with 0 being equivalent to 1).</p><p>Note that most process resource limits configured with these options are per-process, and\n        processes may fork in order to acquire a new set of resources that are accounted independently of the\n        original process, and may thus escape limits set. Also note that <code class=\"varname\">LimitRSS=</code> is not\n        implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource\n        controls listed in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.resource-control</span>(5)</span></a>\n        over these per-process limits, as they apply to services as a whole, may be altered dynamically at\n        runtime, and are generally more expressive. For example, <code class=\"varname\">MemoryMax=</code> is a more\n        powerful (and working) replacement for <code class=\"varname\">LimitRSS=</code>.</p><p>Resource limits not configured explicitly for a unit default to the value configured in the various\n        <code class=\"varname\">DefaultLimitCPU=</code>, <code class=\"varname\">DefaultLimitFSIZE=</code>, … options available in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd-system.conf</span>(5)</span></a>, and –\n        if not configured there – the kernel or per-user defaults, as defined by the OS (the latter only for user\n        services, see below).</p><p>For system units these resource limits may be chosen freely. When these settings are configured\n        in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be\n        used to raise the limits above those set for the user manager itself when it was first invoked, as\n        the user's service manager generally lacks the privileges to do so. In user context these\n        configuration options are hence only useful to lower the limits passed in or to raise the soft limit\n        to the maximum of the hard limit as configured for the user. To raise the user's limits further, the\n        available configuration mechanisms differ between operating systems, but typically require\n        privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by\n        setting limits on the system service encapsulating the user's service manager, i.e. the user's\n        instance of <code class=\"filename\">user@.service</code>. After making such changes, make sure to restart the\n        user's service manager.</p><div class=\"table\"><a target=\"__blank\" name=\"id-1.12.2.1.17.5\"></a><p class=\"title\"><b>Table&nbsp;1.&nbsp;Resource limit directives, their equivalent <span class=\"command\">ulimit</span> shell commands and the unit used</b></p><div class=\"table-contents\"><table class=\"table\" summary=\"Resource limit directives, their equivalent ulimit shell commands and the unit used\" border=\"1\"><colgroup><col class=\"directive\"><col class=\"equivalent\"><col class=\"unit\"></colgroup><thead><tr><th>Directive</th><th><span class=\"command\"><strong>ulimit</strong></span> equivalent</th><th>Unit</th></tr></thead><tbody><tr><td>LimitCPU=</td><td>ulimit -t</td><td>Seconds</td></tr><tr><td>LimitFSIZE=</td><td>ulimit -f</td><td>Bytes</td></tr><tr><td>LimitDATA=</td><td>ulimit -d</td><td>Bytes</td></tr><tr><td>LimitSTACK=</td><td>ulimit -s</td><td>Bytes</td></tr><tr><td>LimitCORE=</td><td>ulimit -c</td><td>Bytes</td></tr><tr><td>LimitRSS=</td><td>ulimit -m</td><td>Bytes</td></tr><tr><td>LimitNOFILE=</td><td>ulimit -n</td><td>Number of File Descriptors</td></tr><tr><td>LimitAS=</td><td>ulimit -v</td><td>Bytes</td></tr><tr><td>LimitNPROC=</td><td>ulimit -u</td><td>Number of Processes</td></tr><tr><td>LimitMEMLOCK=</td><td>ulimit -l</td><td>Bytes</td></tr><tr><td>LimitLOCKS=</td><td>ulimit -x</td><td>Number of Locks</td></tr><tr><td>LimitSIGPENDING=</td><td>ulimit -i</td><td>Number of Queued Signals</td></tr><tr><td>LimitMSGQUEUE=</td><td>ulimit -q</td><td>Bytes</td></tr><tr><td>LimitNICE=</td><td>ulimit -e</td><td>Nice Level</td></tr><tr><td>LimitRTPRIO=</td><td>ulimit -r</td><td>Realtime Priority</td></tr><tr><td>LimitRTTIME=</td><td>No equivalent</td><td>Microseconds</td></tr></tbody></table></div></div><br class=\"table-break\">",
                "LimitMEMLOCK": "<p>Set soft and hard limits on various resources for executed processes. See\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/setrlimit.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">setrlimit</span>(2)</span></a> for\n        details on the resource limit concept. Resource limits may be specified in two formats: either as\n        single value to set a specific soft and hard limit to the same value, or as colon-separated pair\n        <code class=\"option\">soft:hard</code> to set both limits individually (e.g. \"<code class=\"literal\">LimitAS=4G:16G</code>\").\n        Use the string <code class=\"option\">infinity</code> to configure no limit on a specific resource. The\n        multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits\n        measured in bytes (e.g. \"<code class=\"literal\">LimitAS=16G</code>\"). For the limits referring to time values, the\n        usual time units ms, s, min, h and so on may be used (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.time.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.time</span>(7)</span></a> for\n        details). Note that if no time unit is specified for <code class=\"varname\">LimitCPU=</code> the default unit of\n        seconds is implied, while for <code class=\"varname\">LimitRTTIME=</code> the default unit of microseconds is\n        implied. Also, note that the effective granularity of the limits might influence their\n        enforcement. For example, time limits specified for <code class=\"varname\">LimitCPU=</code> will be rounded up\n        implicitly to multiples of 1s. For <code class=\"varname\">LimitNICE=</code> the value may be specified in two\n        syntaxes: if prefixed with \"<code class=\"literal\">+</code>\" or \"<code class=\"literal\">-</code>\", the value is understood as\n        regular Linux nice value in the range -20..19. If not prefixed like this the value is understood as\n        raw resource limit parameter in the range 0..40 (with 0 being equivalent to 1).</p><p>Note that most process resource limits configured with these options are per-process, and\n        processes may fork in order to acquire a new set of resources that are accounted independently of the\n        original process, and may thus escape limits set. Also note that <code class=\"varname\">LimitRSS=</code> is not\n        implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource\n        controls listed in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.resource-control</span>(5)</span></a>\n        over these per-process limits, as they apply to services as a whole, may be altered dynamically at\n        runtime, and are generally more expressive. For example, <code class=\"varname\">MemoryMax=</code> is a more\n        powerful (and working) replacement for <code class=\"varname\">LimitRSS=</code>.</p><p>Resource limits not configured explicitly for a unit default to the value configured in the various\n        <code class=\"varname\">DefaultLimitCPU=</code>, <code class=\"varname\">DefaultLimitFSIZE=</code>, … options available in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd-system.conf</span>(5)</span></a>, and –\n        if not configured there – the kernel or per-user defaults, as defined by the OS (the latter only for user\n        services, see below).</p><p>For system units these resource limits may be chosen freely. When these settings are configured\n        in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be\n        used to raise the limits above those set for the user manager itself when it was first invoked, as\n        the user's service manager generally lacks the privileges to do so. In user context these\n        configuration options are hence only useful to lower the limits passed in or to raise the soft limit\n        to the maximum of the hard limit as configured for the user. To raise the user's limits further, the\n        available configuration mechanisms differ between operating systems, but typically require\n        privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by\n        setting limits on the system service encapsulating the user's service manager, i.e. the user's\n        instance of <code class=\"filename\">user@.service</code>. After making such changes, make sure to restart the\n        user's service manager.</p><div class=\"table\"><a target=\"__blank\" name=\"id-1.12.2.1.17.5\"></a><p class=\"title\"><b>Table&nbsp;1.&nbsp;Resource limit directives, their equivalent <span class=\"command\">ulimit</span> shell commands and the unit used</b></p><div class=\"table-contents\"><table class=\"table\" summary=\"Resource limit directives, their equivalent ulimit shell commands and the unit used\" border=\"1\"><colgroup><col class=\"directive\"><col class=\"equivalent\"><col class=\"unit\"></colgroup><thead><tr><th>Directive</th><th><span class=\"command\"><strong>ulimit</strong></span> equivalent</th><th>Unit</th></tr></thead><tbody><tr><td>LimitCPU=</td><td>ulimit -t</td><td>Seconds</td></tr><tr><td>LimitFSIZE=</td><td>ulimit -f</td><td>Bytes</td></tr><tr><td>LimitDATA=</td><td>ulimit -d</td><td>Bytes</td></tr><tr><td>LimitSTACK=</td><td>ulimit -s</td><td>Bytes</td></tr><tr><td>LimitCORE=</td><td>ulimit -c</td><td>Bytes</td></tr><tr><td>LimitRSS=</td><td>ulimit -m</td><td>Bytes</td></tr><tr><td>LimitNOFILE=</td><td>ulimit -n</td><td>Number of File Descriptors</td></tr><tr><td>LimitAS=</td><td>ulimit -v</td><td>Bytes</td></tr><tr><td>LimitNPROC=</td><td>ulimit -u</td><td>Number of Processes</td></tr><tr><td>LimitMEMLOCK=</td><td>ulimit -l</td><td>Bytes</td></tr><tr><td>LimitLOCKS=</td><td>ulimit -x</td><td>Number of Locks</td></tr><tr><td>LimitSIGPENDING=</td><td>ulimit -i</td><td>Number of Queued Signals</td></tr><tr><td>LimitMSGQUEUE=</td><td>ulimit -q</td><td>Bytes</td></tr><tr><td>LimitNICE=</td><td>ulimit -e</td><td>Nice Level</td></tr><tr><td>LimitRTPRIO=</td><td>ulimit -r</td><td>Realtime Priority</td></tr><tr><td>LimitRTTIME=</td><td>No equivalent</td><td>Microseconds</td></tr></tbody></table></div></div><br class=\"table-break\">",
                "LimitLOCKS": "<p>Set soft and hard limits on various resources for executed processes. See\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/setrlimit.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">setrlimit</span>(2)</span></a> for\n        details on the resource limit concept. Resource limits may be specified in two formats: either as\n        single value to set a specific soft and hard limit to the same value, or as colon-separated pair\n        <code class=\"option\">soft:hard</code> to set both limits individually (e.g. \"<code class=\"literal\">LimitAS=4G:16G</code>\").\n        Use the string <code class=\"option\">infinity</code> to configure no limit on a specific resource. The\n        multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits\n        measured in bytes (e.g. \"<code class=\"literal\">LimitAS=16G</code>\"). For the limits referring to time values, the\n        usual time units ms, s, min, h and so on may be used (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.time.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.time</span>(7)</span></a> for\n        details). Note that if no time unit is specified for <code class=\"varname\">LimitCPU=</code> the default unit of\n        seconds is implied, while for <code class=\"varname\">LimitRTTIME=</code> the default unit of microseconds is\n        implied. Also, note that the effective granularity of the limits might influence their\n        enforcement. For example, time limits specified for <code class=\"varname\">LimitCPU=</code> will be rounded up\n        implicitly to multiples of 1s. For <code class=\"varname\">LimitNICE=</code> the value may be specified in two\n        syntaxes: if prefixed with \"<code class=\"literal\">+</code>\" or \"<code class=\"literal\">-</code>\", the value is understood as\n        regular Linux nice value in the range -20..19. If not prefixed like this the value is understood as\n        raw resource limit parameter in the range 0..40 (with 0 being equivalent to 1).</p><p>Note that most process resource limits configured with these options are per-process, and\n        processes may fork in order to acquire a new set of resources that are accounted independently of the\n        original process, and may thus escape limits set. Also note that <code class=\"varname\">LimitRSS=</code> is not\n        implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource\n        controls listed in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.resource-control</span>(5)</span></a>\n        over these per-process limits, as they apply to services as a whole, may be altered dynamically at\n        runtime, and are generally more expressive. For example, <code class=\"varname\">MemoryMax=</code> is a more\n        powerful (and working) replacement for <code class=\"varname\">LimitRSS=</code>.</p><p>Resource limits not configured explicitly for a unit default to the value configured in the various\n        <code class=\"varname\">DefaultLimitCPU=</code>, <code class=\"varname\">DefaultLimitFSIZE=</code>, … options available in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd-system.conf</span>(5)</span></a>, and –\n        if not configured there – the kernel or per-user defaults, as defined by the OS (the latter only for user\n        services, see below).</p><p>For system units these resource limits may be chosen freely. When these settings are configured\n        in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be\n        used to raise the limits above those set for the user manager itself when it was first invoked, as\n        the user's service manager generally lacks the privileges to do so. In user context these\n        configuration options are hence only useful to lower the limits passed in or to raise the soft limit\n        to the maximum of the hard limit as configured for the user. To raise the user's limits further, the\n        available configuration mechanisms differ between operating systems, but typically require\n        privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by\n        setting limits on the system service encapsulating the user's service manager, i.e. the user's\n        instance of <code class=\"filename\">user@.service</code>. After making such changes, make sure to restart the\n        user's service manager.</p><div class=\"table\"><a target=\"__blank\" name=\"id-1.12.2.1.17.5\"></a><p class=\"title\"><b>Table&nbsp;1.&nbsp;Resource limit directives, their equivalent <span class=\"command\">ulimit</span> shell commands and the unit used</b></p><div class=\"table-contents\"><table class=\"table\" summary=\"Resource limit directives, their equivalent ulimit shell commands and the unit used\" border=\"1\"><colgroup><col class=\"directive\"><col class=\"equivalent\"><col class=\"unit\"></colgroup><thead><tr><th>Directive</th><th><span class=\"command\"><strong>ulimit</strong></span> equivalent</th><th>Unit</th></tr></thead><tbody><tr><td>LimitCPU=</td><td>ulimit -t</td><td>Seconds</td></tr><tr><td>LimitFSIZE=</td><td>ulimit -f</td><td>Bytes</td></tr><tr><td>LimitDATA=</td><td>ulimit -d</td><td>Bytes</td></tr><tr><td>LimitSTACK=</td><td>ulimit -s</td><td>Bytes</td></tr><tr><td>LimitCORE=</td><td>ulimit -c</td><td>Bytes</td></tr><tr><td>LimitRSS=</td><td>ulimit -m</td><td>Bytes</td></tr><tr><td>LimitNOFILE=</td><td>ulimit -n</td><td>Number of File Descriptors</td></tr><tr><td>LimitAS=</td><td>ulimit -v</td><td>Bytes</td></tr><tr><td>LimitNPROC=</td><td>ulimit -u</td><td>Number of Processes</td></tr><tr><td>LimitMEMLOCK=</td><td>ulimit -l</td><td>Bytes</td></tr><tr><td>LimitLOCKS=</td><td>ulimit -x</td><td>Number of Locks</td></tr><tr><td>LimitSIGPENDING=</td><td>ulimit -i</td><td>Number of Queued Signals</td></tr><tr><td>LimitMSGQUEUE=</td><td>ulimit -q</td><td>Bytes</td></tr><tr><td>LimitNICE=</td><td>ulimit -e</td><td>Nice Level</td></tr><tr><td>LimitRTPRIO=</td><td>ulimit -r</td><td>Realtime Priority</td></tr><tr><td>LimitRTTIME=</td><td>No equivalent</td><td>Microseconds</td></tr></tbody></table></div></div><br class=\"table-break\">",
                "LimitSIGPENDING": "<p>Set soft and hard limits on various resources for executed processes. See\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/setrlimit.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">setrlimit</span>(2)</span></a> for\n        details on the resource limit concept. Resource limits may be specified in two formats: either as\n        single value to set a specific soft and hard limit to the same value, or as colon-separated pair\n        <code class=\"option\">soft:hard</code> to set both limits individually (e.g. \"<code class=\"literal\">LimitAS=4G:16G</code>\").\n        Use the string <code class=\"option\">infinity</code> to configure no limit on a specific resource. The\n        multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits\n        measured in bytes (e.g. \"<code class=\"literal\">LimitAS=16G</code>\"). For the limits referring to time values, the\n        usual time units ms, s, min, h and so on may be used (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.time.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.time</span>(7)</span></a> for\n        details). Note that if no time unit is specified for <code class=\"varname\">LimitCPU=</code> the default unit of\n        seconds is implied, while for <code class=\"varname\">LimitRTTIME=</code> the default unit of microseconds is\n        implied. Also, note that the effective granularity of the limits might influence their\n        enforcement. For example, time limits specified for <code class=\"varname\">LimitCPU=</code> will be rounded up\n        implicitly to multiples of 1s. For <code class=\"varname\">LimitNICE=</code> the value may be specified in two\n        syntaxes: if prefixed with \"<code class=\"literal\">+</code>\" or \"<code class=\"literal\">-</code>\", the value is understood as\n        regular Linux nice value in the range -20..19. If not prefixed like this the value is understood as\n        raw resource limit parameter in the range 0..40 (with 0 being equivalent to 1).</p><p>Note that most process resource limits configured with these options are per-process, and\n        processes may fork in order to acquire a new set of resources that are accounted independently of the\n        original process, and may thus escape limits set. Also note that <code class=\"varname\">LimitRSS=</code> is not\n        implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource\n        controls listed in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.resource-control</span>(5)</span></a>\n        over these per-process limits, as they apply to services as a whole, may be altered dynamically at\n        runtime, and are generally more expressive. For example, <code class=\"varname\">MemoryMax=</code> is a more\n        powerful (and working) replacement for <code class=\"varname\">LimitRSS=</code>.</p><p>Resource limits not configured explicitly for a unit default to the value configured in the various\n        <code class=\"varname\">DefaultLimitCPU=</code>, <code class=\"varname\">DefaultLimitFSIZE=</code>, … options available in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd-system.conf</span>(5)</span></a>, and –\n        if not configured there – the kernel or per-user defaults, as defined by the OS (the latter only for user\n        services, see below).</p><p>For system units these resource limits may be chosen freely. When these settings are configured\n        in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be\n        used to raise the limits above those set for the user manager itself when it was first invoked, as\n        the user's service manager generally lacks the privileges to do so. In user context these\n        configuration options are hence only useful to lower the limits passed in or to raise the soft limit\n        to the maximum of the hard limit as configured for the user. To raise the user's limits further, the\n        available configuration mechanisms differ between operating systems, but typically require\n        privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by\n        setting limits on the system service encapsulating the user's service manager, i.e. the user's\n        instance of <code class=\"filename\">user@.service</code>. After making such changes, make sure to restart the\n        user's service manager.</p><div class=\"table\"><a target=\"__blank\" name=\"id-1.12.2.1.17.5\"></a><p class=\"title\"><b>Table&nbsp;1.&nbsp;Resource limit directives, their equivalent <span class=\"command\">ulimit</span> shell commands and the unit used</b></p><div class=\"table-contents\"><table class=\"table\" summary=\"Resource limit directives, their equivalent ulimit shell commands and the unit used\" border=\"1\"><colgroup><col class=\"directive\"><col class=\"equivalent\"><col class=\"unit\"></colgroup><thead><tr><th>Directive</th><th><span class=\"command\"><strong>ulimit</strong></span> equivalent</th><th>Unit</th></tr></thead><tbody><tr><td>LimitCPU=</td><td>ulimit -t</td><td>Seconds</td></tr><tr><td>LimitFSIZE=</td><td>ulimit -f</td><td>Bytes</td></tr><tr><td>LimitDATA=</td><td>ulimit -d</td><td>Bytes</td></tr><tr><td>LimitSTACK=</td><td>ulimit -s</td><td>Bytes</td></tr><tr><td>LimitCORE=</td><td>ulimit -c</td><td>Bytes</td></tr><tr><td>LimitRSS=</td><td>ulimit -m</td><td>Bytes</td></tr><tr><td>LimitNOFILE=</td><td>ulimit -n</td><td>Number of File Descriptors</td></tr><tr><td>LimitAS=</td><td>ulimit -v</td><td>Bytes</td></tr><tr><td>LimitNPROC=</td><td>ulimit -u</td><td>Number of Processes</td></tr><tr><td>LimitMEMLOCK=</td><td>ulimit -l</td><td>Bytes</td></tr><tr><td>LimitLOCKS=</td><td>ulimit -x</td><td>Number of Locks</td></tr><tr><td>LimitSIGPENDING=</td><td>ulimit -i</td><td>Number of Queued Signals</td></tr><tr><td>LimitMSGQUEUE=</td><td>ulimit -q</td><td>Bytes</td></tr><tr><td>LimitNICE=</td><td>ulimit -e</td><td>Nice Level</td></tr><tr><td>LimitRTPRIO=</td><td>ulimit -r</td><td>Realtime Priority</td></tr><tr><td>LimitRTTIME=</td><td>No equivalent</td><td>Microseconds</td></tr></tbody></table></div></div><br class=\"table-break\">",
                "LimitMSGQUEUE": "<p>Set soft and hard limits on various resources for executed processes. See\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/setrlimit.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">setrlimit</span>(2)</span></a> for\n        details on the resource limit concept. Resource limits may be specified in two formats: either as\n        single value to set a specific soft and hard limit to the same value, or as colon-separated pair\n        <code class=\"option\">soft:hard</code> to set both limits individually (e.g. \"<code class=\"literal\">LimitAS=4G:16G</code>\").\n        Use the string <code class=\"option\">infinity</code> to configure no limit on a specific resource. The\n        multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits\n        measured in bytes (e.g. \"<code class=\"literal\">LimitAS=16G</code>\"). For the limits referring to time values, the\n        usual time units ms, s, min, h and so on may be used (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.time.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.time</span>(7)</span></a> for\n        details). Note that if no time unit is specified for <code class=\"varname\">LimitCPU=</code> the default unit of\n        seconds is implied, while for <code class=\"varname\">LimitRTTIME=</code> the default unit of microseconds is\n        implied. Also, note that the effective granularity of the limits might influence their\n        enforcement. For example, time limits specified for <code class=\"varname\">LimitCPU=</code> will be rounded up\n        implicitly to multiples of 1s. For <code class=\"varname\">LimitNICE=</code> the value may be specified in two\n        syntaxes: if prefixed with \"<code class=\"literal\">+</code>\" or \"<code class=\"literal\">-</code>\", the value is understood as\n        regular Linux nice value in the range -20..19. If not prefixed like this the value is understood as\n        raw resource limit parameter in the range 0..40 (with 0 being equivalent to 1).</p><p>Note that most process resource limits configured with these options are per-process, and\n        processes may fork in order to acquire a new set of resources that are accounted independently of the\n        original process, and may thus escape limits set. Also note that <code class=\"varname\">LimitRSS=</code> is not\n        implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource\n        controls listed in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.resource-control</span>(5)</span></a>\n        over these per-process limits, as they apply to services as a whole, may be altered dynamically at\n        runtime, and are generally more expressive. For example, <code class=\"varname\">MemoryMax=</code> is a more\n        powerful (and working) replacement for <code class=\"varname\">LimitRSS=</code>.</p><p>Resource limits not configured explicitly for a unit default to the value configured in the various\n        <code class=\"varname\">DefaultLimitCPU=</code>, <code class=\"varname\">DefaultLimitFSIZE=</code>, … options available in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd-system.conf</span>(5)</span></a>, and –\n        if not configured there – the kernel or per-user defaults, as defined by the OS (the latter only for user\n        services, see below).</p><p>For system units these resource limits may be chosen freely. When these settings are configured\n        in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be\n        used to raise the limits above those set for the user manager itself when it was first invoked, as\n        the user's service manager generally lacks the privileges to do so. In user context these\n        configuration options are hence only useful to lower the limits passed in or to raise the soft limit\n        to the maximum of the hard limit as configured for the user. To raise the user's limits further, the\n        available configuration mechanisms differ between operating systems, but typically require\n        privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by\n        setting limits on the system service encapsulating the user's service manager, i.e. the user's\n        instance of <code class=\"filename\">user@.service</code>. After making such changes, make sure to restart the\n        user's service manager.</p><div class=\"table\"><a target=\"__blank\" name=\"id-1.12.2.1.17.5\"></a><p class=\"title\"><b>Table&nbsp;1.&nbsp;Resource limit directives, their equivalent <span class=\"command\">ulimit</span> shell commands and the unit used</b></p><div class=\"table-contents\"><table class=\"table\" summary=\"Resource limit directives, their equivalent ulimit shell commands and the unit used\" border=\"1\"><colgroup><col class=\"directive\"><col class=\"equivalent\"><col class=\"unit\"></colgroup><thead><tr><th>Directive</th><th><span class=\"command\"><strong>ulimit</strong></span> equivalent</th><th>Unit</th></tr></thead><tbody><tr><td>LimitCPU=</td><td>ulimit -t</td><td>Seconds</td></tr><tr><td>LimitFSIZE=</td><td>ulimit -f</td><td>Bytes</td></tr><tr><td>LimitDATA=</td><td>ulimit -d</td><td>Bytes</td></tr><tr><td>LimitSTACK=</td><td>ulimit -s</td><td>Bytes</td></tr><tr><td>LimitCORE=</td><td>ulimit -c</td><td>Bytes</td></tr><tr><td>LimitRSS=</td><td>ulimit -m</td><td>Bytes</td></tr><tr><td>LimitNOFILE=</td><td>ulimit -n</td><td>Number of File Descriptors</td></tr><tr><td>LimitAS=</td><td>ulimit -v</td><td>Bytes</td></tr><tr><td>LimitNPROC=</td><td>ulimit -u</td><td>Number of Processes</td></tr><tr><td>LimitMEMLOCK=</td><td>ulimit -l</td><td>Bytes</td></tr><tr><td>LimitLOCKS=</td><td>ulimit -x</td><td>Number of Locks</td></tr><tr><td>LimitSIGPENDING=</td><td>ulimit -i</td><td>Number of Queued Signals</td></tr><tr><td>LimitMSGQUEUE=</td><td>ulimit -q</td><td>Bytes</td></tr><tr><td>LimitNICE=</td><td>ulimit -e</td><td>Nice Level</td></tr><tr><td>LimitRTPRIO=</td><td>ulimit -r</td><td>Realtime Priority</td></tr><tr><td>LimitRTTIME=</td><td>No equivalent</td><td>Microseconds</td></tr></tbody></table></div></div><br class=\"table-break\">",
                "LimitNICE": "<p>Set soft and hard limits on various resources for executed processes. See\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/setrlimit.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">setrlimit</span>(2)</span></a> for\n        details on the resource limit concept. Resource limits may be specified in two formats: either as\n        single value to set a specific soft and hard limit to the same value, or as colon-separated pair\n        <code class=\"option\">soft:hard</code> to set both limits individually (e.g. \"<code class=\"literal\">LimitAS=4G:16G</code>\").\n        Use the string <code class=\"option\">infinity</code> to configure no limit on a specific resource. The\n        multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits\n        measured in bytes (e.g. \"<code class=\"literal\">LimitAS=16G</code>\"). For the limits referring to time values, the\n        usual time units ms, s, min, h and so on may be used (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.time.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.time</span>(7)</span></a> for\n        details). Note that if no time unit is specified for <code class=\"varname\">LimitCPU=</code> the default unit of\n        seconds is implied, while for <code class=\"varname\">LimitRTTIME=</code> the default unit of microseconds is\n        implied. Also, note that the effective granularity of the limits might influence their\n        enforcement. For example, time limits specified for <code class=\"varname\">LimitCPU=</code> will be rounded up\n        implicitly to multiples of 1s. For <code class=\"varname\">LimitNICE=</code> the value may be specified in two\n        syntaxes: if prefixed with \"<code class=\"literal\">+</code>\" or \"<code class=\"literal\">-</code>\", the value is understood as\n        regular Linux nice value in the range -20..19. If not prefixed like this the value is understood as\n        raw resource limit parameter in the range 0..40 (with 0 being equivalent to 1).</p><p>Note that most process resource limits configured with these options are per-process, and\n        processes may fork in order to acquire a new set of resources that are accounted independently of the\n        original process, and may thus escape limits set. Also note that <code class=\"varname\">LimitRSS=</code> is not\n        implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource\n        controls listed in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.resource-control</span>(5)</span></a>\n        over these per-process limits, as they apply to services as a whole, may be altered dynamically at\n        runtime, and are generally more expressive. For example, <code class=\"varname\">MemoryMax=</code> is a more\n        powerful (and working) replacement for <code class=\"varname\">LimitRSS=</code>.</p><p>Resource limits not configured explicitly for a unit default to the value configured in the various\n        <code class=\"varname\">DefaultLimitCPU=</code>, <code class=\"varname\">DefaultLimitFSIZE=</code>, … options available in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd-system.conf</span>(5)</span></a>, and –\n        if not configured there – the kernel or per-user defaults, as defined by the OS (the latter only for user\n        services, see below).</p><p>For system units these resource limits may be chosen freely. When these settings are configured\n        in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be\n        used to raise the limits above those set for the user manager itself when it was first invoked, as\n        the user's service manager generally lacks the privileges to do so. In user context these\n        configuration options are hence only useful to lower the limits passed in or to raise the soft limit\n        to the maximum of the hard limit as configured for the user. To raise the user's limits further, the\n        available configuration mechanisms differ between operating systems, but typically require\n        privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by\n        setting limits on the system service encapsulating the user's service manager, i.e. the user's\n        instance of <code class=\"filename\">user@.service</code>. After making such changes, make sure to restart the\n        user's service manager.</p><div class=\"table\"><a target=\"__blank\" name=\"id-1.12.2.1.17.5\"></a><p class=\"title\"><b>Table&nbsp;1.&nbsp;Resource limit directives, their equivalent <span class=\"command\">ulimit</span> shell commands and the unit used</b></p><div class=\"table-contents\"><table class=\"table\" summary=\"Resource limit directives, their equivalent ulimit shell commands and the unit used\" border=\"1\"><colgroup><col class=\"directive\"><col class=\"equivalent\"><col class=\"unit\"></colgroup><thead><tr><th>Directive</th><th><span class=\"command\"><strong>ulimit</strong></span> equivalent</th><th>Unit</th></tr></thead><tbody><tr><td>LimitCPU=</td><td>ulimit -t</td><td>Seconds</td></tr><tr><td>LimitFSIZE=</td><td>ulimit -f</td><td>Bytes</td></tr><tr><td>LimitDATA=</td><td>ulimit -d</td><td>Bytes</td></tr><tr><td>LimitSTACK=</td><td>ulimit -s</td><td>Bytes</td></tr><tr><td>LimitCORE=</td><td>ulimit -c</td><td>Bytes</td></tr><tr><td>LimitRSS=</td><td>ulimit -m</td><td>Bytes</td></tr><tr><td>LimitNOFILE=</td><td>ulimit -n</td><td>Number of File Descriptors</td></tr><tr><td>LimitAS=</td><td>ulimit -v</td><td>Bytes</td></tr><tr><td>LimitNPROC=</td><td>ulimit -u</td><td>Number of Processes</td></tr><tr><td>LimitMEMLOCK=</td><td>ulimit -l</td><td>Bytes</td></tr><tr><td>LimitLOCKS=</td><td>ulimit -x</td><td>Number of Locks</td></tr><tr><td>LimitSIGPENDING=</td><td>ulimit -i</td><td>Number of Queued Signals</td></tr><tr><td>LimitMSGQUEUE=</td><td>ulimit -q</td><td>Bytes</td></tr><tr><td>LimitNICE=</td><td>ulimit -e</td><td>Nice Level</td></tr><tr><td>LimitRTPRIO=</td><td>ulimit -r</td><td>Realtime Priority</td></tr><tr><td>LimitRTTIME=</td><td>No equivalent</td><td>Microseconds</td></tr></tbody></table></div></div><br class=\"table-break\">",
                "LimitRTPRIO": "<p>Set soft and hard limits on various resources for executed processes. See\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/setrlimit.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">setrlimit</span>(2)</span></a> for\n        details on the resource limit concept. Resource limits may be specified in two formats: either as\n        single value to set a specific soft and hard limit to the same value, or as colon-separated pair\n        <code class=\"option\">soft:hard</code> to set both limits individually (e.g. \"<code class=\"literal\">LimitAS=4G:16G</code>\").\n        Use the string <code class=\"option\">infinity</code> to configure no limit on a specific resource. The\n        multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits\n        measured in bytes (e.g. \"<code class=\"literal\">LimitAS=16G</code>\"). For the limits referring to time values, the\n        usual time units ms, s, min, h and so on may be used (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.time.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.time</span>(7)</span></a> for\n        details). Note that if no time unit is specified for <code class=\"varname\">LimitCPU=</code> the default unit of\n        seconds is implied, while for <code class=\"varname\">LimitRTTIME=</code> the default unit of microseconds is\n        implied. Also, note that the effective granularity of the limits might influence their\n        enforcement. For example, time limits specified for <code class=\"varname\">LimitCPU=</code> will be rounded up\n        implicitly to multiples of 1s. For <code class=\"varname\">LimitNICE=</code> the value may be specified in two\n        syntaxes: if prefixed with \"<code class=\"literal\">+</code>\" or \"<code class=\"literal\">-</code>\", the value is understood as\n        regular Linux nice value in the range -20..19. If not prefixed like this the value is understood as\n        raw resource limit parameter in the range 0..40 (with 0 being equivalent to 1).</p><p>Note that most process resource limits configured with these options are per-process, and\n        processes may fork in order to acquire a new set of resources that are accounted independently of the\n        original process, and may thus escape limits set. Also note that <code class=\"varname\">LimitRSS=</code> is not\n        implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource\n        controls listed in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.resource-control</span>(5)</span></a>\n        over these per-process limits, as they apply to services as a whole, may be altered dynamically at\n        runtime, and are generally more expressive. For example, <code class=\"varname\">MemoryMax=</code> is a more\n        powerful (and working) replacement for <code class=\"varname\">LimitRSS=</code>.</p><p>Resource limits not configured explicitly for a unit default to the value configured in the various\n        <code class=\"varname\">DefaultLimitCPU=</code>, <code class=\"varname\">DefaultLimitFSIZE=</code>, … options available in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd-system.conf</span>(5)</span></a>, and –\n        if not configured there – the kernel or per-user defaults, as defined by the OS (the latter only for user\n        services, see below).</p><p>For system units these resource limits may be chosen freely. When these settings are configured\n        in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be\n        used to raise the limits above those set for the user manager itself when it was first invoked, as\n        the user's service manager generally lacks the privileges to do so. In user context these\n        configuration options are hence only useful to lower the limits passed in or to raise the soft limit\n        to the maximum of the hard limit as configured for the user. To raise the user's limits further, the\n        available configuration mechanisms differ between operating systems, but typically require\n        privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by\n        setting limits on the system service encapsulating the user's service manager, i.e. the user's\n        instance of <code class=\"filename\">user@.service</code>. After making such changes, make sure to restart the\n        user's service manager.</p><div class=\"table\"><a target=\"__blank\" name=\"id-1.12.2.1.17.5\"></a><p class=\"title\"><b>Table&nbsp;1.&nbsp;Resource limit directives, their equivalent <span class=\"command\">ulimit</span> shell commands and the unit used</b></p><div class=\"table-contents\"><table class=\"table\" summary=\"Resource limit directives, their equivalent ulimit shell commands and the unit used\" border=\"1\"><colgroup><col class=\"directive\"><col class=\"equivalent\"><col class=\"unit\"></colgroup><thead><tr><th>Directive</th><th><span class=\"command\"><strong>ulimit</strong></span> equivalent</th><th>Unit</th></tr></thead><tbody><tr><td>LimitCPU=</td><td>ulimit -t</td><td>Seconds</td></tr><tr><td>LimitFSIZE=</td><td>ulimit -f</td><td>Bytes</td></tr><tr><td>LimitDATA=</td><td>ulimit -d</td><td>Bytes</td></tr><tr><td>LimitSTACK=</td><td>ulimit -s</td><td>Bytes</td></tr><tr><td>LimitCORE=</td><td>ulimit -c</td><td>Bytes</td></tr><tr><td>LimitRSS=</td><td>ulimit -m</td><td>Bytes</td></tr><tr><td>LimitNOFILE=</td><td>ulimit -n</td><td>Number of File Descriptors</td></tr><tr><td>LimitAS=</td><td>ulimit -v</td><td>Bytes</td></tr><tr><td>LimitNPROC=</td><td>ulimit -u</td><td>Number of Processes</td></tr><tr><td>LimitMEMLOCK=</td><td>ulimit -l</td><td>Bytes</td></tr><tr><td>LimitLOCKS=</td><td>ulimit -x</td><td>Number of Locks</td></tr><tr><td>LimitSIGPENDING=</td><td>ulimit -i</td><td>Number of Queued Signals</td></tr><tr><td>LimitMSGQUEUE=</td><td>ulimit -q</td><td>Bytes</td></tr><tr><td>LimitNICE=</td><td>ulimit -e</td><td>Nice Level</td></tr><tr><td>LimitRTPRIO=</td><td>ulimit -r</td><td>Realtime Priority</td></tr><tr><td>LimitRTTIME=</td><td>No equivalent</td><td>Microseconds</td></tr></tbody></table></div></div><br class=\"table-break\">",
                "LimitRTTIME": "<p>Set soft and hard limits on various resources for executed processes. See\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/setrlimit.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">setrlimit</span>(2)</span></a> for\n        details on the resource limit concept. Resource limits may be specified in two formats: either as\n        single value to set a specific soft and hard limit to the same value, or as colon-separated pair\n        <code class=\"option\">soft:hard</code> to set both limits individually (e.g. \"<code class=\"literal\">LimitAS=4G:16G</code>\").\n        Use the string <code class=\"option\">infinity</code> to configure no limit on a specific resource. The\n        multiplicative suffixes K, M, G, T, P and E (to the base 1024) may be used for resource limits\n        measured in bytes (e.g. \"<code class=\"literal\">LimitAS=16G</code>\"). For the limits referring to time values, the\n        usual time units ms, s, min, h and so on may be used (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.time.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.time</span>(7)</span></a> for\n        details). Note that if no time unit is specified for <code class=\"varname\">LimitCPU=</code> the default unit of\n        seconds is implied, while for <code class=\"varname\">LimitRTTIME=</code> the default unit of microseconds is\n        implied. Also, note that the effective granularity of the limits might influence their\n        enforcement. For example, time limits specified for <code class=\"varname\">LimitCPU=</code> will be rounded up\n        implicitly to multiples of 1s. For <code class=\"varname\">LimitNICE=</code> the value may be specified in two\n        syntaxes: if prefixed with \"<code class=\"literal\">+</code>\" or \"<code class=\"literal\">-</code>\", the value is understood as\n        regular Linux nice value in the range -20..19. If not prefixed like this the value is understood as\n        raw resource limit parameter in the range 0..40 (with 0 being equivalent to 1).</p><p>Note that most process resource limits configured with these options are per-process, and\n        processes may fork in order to acquire a new set of resources that are accounted independently of the\n        original process, and may thus escape limits set. Also note that <code class=\"varname\">LimitRSS=</code> is not\n        implemented on Linux, and setting it has no effect. Often it is advisable to prefer the resource\n        controls listed in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.resource-control</span>(5)</span></a>\n        over these per-process limits, as they apply to services as a whole, may be altered dynamically at\n        runtime, and are generally more expressive. For example, <code class=\"varname\">MemoryMax=</code> is a more\n        powerful (and working) replacement for <code class=\"varname\">LimitRSS=</code>.</p><p>Resource limits not configured explicitly for a unit default to the value configured in the various\n        <code class=\"varname\">DefaultLimitCPU=</code>, <code class=\"varname\">DefaultLimitFSIZE=</code>, … options available in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd-system.conf</span>(5)</span></a>, and –\n        if not configured there – the kernel or per-user defaults, as defined by the OS (the latter only for user\n        services, see below).</p><p>For system units these resource limits may be chosen freely. When these settings are configured\n        in a user service (i.e. a service run by the per-user instance of the service manager) they cannot be\n        used to raise the limits above those set for the user manager itself when it was first invoked, as\n        the user's service manager generally lacks the privileges to do so. In user context these\n        configuration options are hence only useful to lower the limits passed in or to raise the soft limit\n        to the maximum of the hard limit as configured for the user. To raise the user's limits further, the\n        available configuration mechanisms differ between operating systems, but typically require\n        privileges. In most cases it is possible to configure higher per-user resource limits via PAM or by\n        setting limits on the system service encapsulating the user's service manager, i.e. the user's\n        instance of <code class=\"filename\">user@.service</code>. After making such changes, make sure to restart the\n        user's service manager.</p><div class=\"table\"><a target=\"__blank\" name=\"id-1.12.2.1.17.5\"></a><p class=\"title\"><b>Table&nbsp;1.&nbsp;Resource limit directives, their equivalent <span class=\"command\">ulimit</span> shell commands and the unit used</b></p><div class=\"table-contents\"><table class=\"table\" summary=\"Resource limit directives, their equivalent ulimit shell commands and the unit used\" border=\"1\"><colgroup><col class=\"directive\"><col class=\"equivalent\"><col class=\"unit\"></colgroup><thead><tr><th>Directive</th><th><span class=\"command\"><strong>ulimit</strong></span> equivalent</th><th>Unit</th></tr></thead><tbody><tr><td>LimitCPU=</td><td>ulimit -t</td><td>Seconds</td></tr><tr><td>LimitFSIZE=</td><td>ulimit -f</td><td>Bytes</td></tr><tr><td>LimitDATA=</td><td>ulimit -d</td><td>Bytes</td></tr><tr><td>LimitSTACK=</td><td>ulimit -s</td><td>Bytes</td></tr><tr><td>LimitCORE=</td><td>ulimit -c</td><td>Bytes</td></tr><tr><td>LimitRSS=</td><td>ulimit -m</td><td>Bytes</td></tr><tr><td>LimitNOFILE=</td><td>ulimit -n</td><td>Number of File Descriptors</td></tr><tr><td>LimitAS=</td><td>ulimit -v</td><td>Bytes</td></tr><tr><td>LimitNPROC=</td><td>ulimit -u</td><td>Number of Processes</td></tr><tr><td>LimitMEMLOCK=</td><td>ulimit -l</td><td>Bytes</td></tr><tr><td>LimitLOCKS=</td><td>ulimit -x</td><td>Number of Locks</td></tr><tr><td>LimitSIGPENDING=</td><td>ulimit -i</td><td>Number of Queued Signals</td></tr><tr><td>LimitMSGQUEUE=</td><td>ulimit -q</td><td>Bytes</td></tr><tr><td>LimitNICE=</td><td>ulimit -e</td><td>Nice Level</td></tr><tr><td>LimitRTPRIO=</td><td>ulimit -r</td><td>Realtime Priority</td></tr><tr><td>LimitRTTIME=</td><td>No equivalent</td><td>Microseconds</td></tr></tbody></table></div></div><br class=\"table-break\">",
                "UMask": "<p>Controls the file mode creation mask. Takes an access mode in octal notation. See\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/umask.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">umask</span>(2)</span></a> for\n        details. Defaults to 0022 for system units. For units of the user service manager the default value\n        is inherited from the user instance (whose default is inherited from the system service manager, and\n        thus also is 0022). Hence changing the default value of a user instance, either via\n        <code class=\"varname\">UMask=</code> or via a PAM module, will affect the user instance itself and all user\n        units started by the user instance unless a user unit has specified its own\n        <code class=\"varname\">UMask=</code>.</p>",
                "CoredumpFilter": "<p>Controls which types of memory mappings will be saved if the process dumps core\n        (using the <code class=\"filename\">/proc/<em class=\"replaceable\"><code>pid</code></em>/coredump_filter</code> file). Takes a\n        whitespace-separated combination of mapping type names or numbers (with the default base 16). Mapping\n        type names are <code class=\"constant\">private-anonymous</code>, <code class=\"constant\">shared-anonymous</code>,\n        <code class=\"constant\">private-file-backed</code>, <code class=\"constant\">shared-file-backed</code>,\n        <code class=\"constant\">elf-headers</code>, <code class=\"constant\">private-huge</code>,\n        <code class=\"constant\">shared-huge</code>, <code class=\"constant\">private-dax</code>, <code class=\"constant\">shared-dax</code>,\n        and the special values <code class=\"constant\">all</code> (all types) and <code class=\"constant\">default</code> (the\n        kernel default of \"<code class=\"literal\"><code class=\"constant\">private-anonymous</code>\n        <code class=\"constant\">shared-anonymous</code> <code class=\"constant\">elf-headers</code>\n        <code class=\"constant\">private-huge</code></code>\"). See\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man5/core.5.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">core</span>(5)</span></a>\n        for the meaning of the mapping types. When specified multiple times, all specified masks are\n        ORed. When not set, or if the empty value is assigned, the inherited value is not changed.</p><div class=\"example\"><a target=\"__blank\" name=\"id-1.12.2.3.2.2\"></a><p class=\"title\"><b>Example&nbsp;1.&nbsp;Add DAX pages to the dump filter</b></p><div class=\"example-contents\"><pre class=\"programlisting\">CoredumpFilter=default private-dax shared-dax</pre></div></div><br class=\"example-break\">",
                "KeyringMode": "<p>Controls how the kernel session keyring is set up for the service (see <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/session-keyring.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">session-keyring</span>(7)</span></a> for\n        details on the session keyring). Takes one of <code class=\"option\">inherit</code>, <code class=\"option\">private</code>,\n        <code class=\"option\">shared</code>. If set to <code class=\"option\">inherit</code> no special keyring setup is done, and the kernel's\n        default behaviour is applied. If <code class=\"option\">private</code> is used a new session keyring is allocated when a\n        service process is invoked, and it is not linked up with any user keyring. This is the recommended setting for\n        system services, as this ensures that multiple services running under the same system user ID (in particular\n        the root user) do not share their key material among each other. If <code class=\"option\">shared</code> is used a new\n        session keyring is allocated as for <code class=\"option\">private</code>, but the user keyring of the user configured with\n        <code class=\"varname\">User=</code> is linked into it, so that keys assigned to the user may be requested by the unit's\n        processes. In this modes multiple units running processes under the same user ID may share key material. Unless\n        <code class=\"option\">inherit</code> is selected the unique invocation ID for the unit (see below) is added as a protected\n        key by the name \"<code class=\"literal\">invocation_id</code>\" to the newly created session keyring. Defaults to\n        <code class=\"option\">private</code> for services of the system service manager and to <code class=\"option\">inherit</code> for\n        non-service units and for services of the user service manager.</p>",
                "OOMScoreAdjust": "<p>Sets the adjustment value for the Linux kernel's Out-Of-Memory (OOM) killer score for\n        executed processes. Takes an integer between -1000 (to disable OOM killing of processes of this unit)\n        and 1000 (to make killing of processes of this unit under memory pressure very likely). See <a target=\"__blank\" class=\"ulink\" href=\"https://www.kernel.org/doc/Documentation/filesystems/proc.txt\" target=\"_top\">proc.txt</a> for details. If\n        not specified defaults to the OOM score adjustment level of the service manager itself, which is\n        normally at 0.</p><p>Use the <code class=\"varname\">OOMPolicy=</code> setting of service units to configure how the service\n        manager shall react to the kernel OOM killer terminating a process of the service.  See\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.service.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.service</span>(5)</span></a>\n        for details.</p>",
                "TimerSlackNSec": "<p>Sets the timer slack in nanoseconds for the executed processes. The timer slack controls the\n        accuracy of wake-ups triggered by timers. See\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/prctl.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">prctl</span>(2)</span></a> for more\n        information. Note that in contrast to most other time span definitions this parameter takes an integer value in\n        nano-seconds if no unit is specified. The usual time units are understood too.</p>",
                "Personality": "<p>Controls which kernel architecture <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/uname.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">uname</span>(2)</span></a> shall report,\n        when invoked by unit processes. Takes one of the architecture identifiers <code class=\"constant\">x86</code>,\n        <code class=\"constant\">x86-64</code>, <code class=\"constant\">ppc</code>, <code class=\"constant\">ppc-le</code>, <code class=\"constant\">ppc64</code>,\n        <code class=\"constant\">ppc64-le</code>, <code class=\"constant\">s390</code> or <code class=\"constant\">s390x</code>. Which personality\n        architectures are supported depends on the system architecture. Usually the 64bit versions of the various\n        system architectures support their immediate 32bit personality architecture counterpart, but no others. For\n        example, <code class=\"constant\">x86-64</code> systems support the <code class=\"constant\">x86-64</code> and\n        <code class=\"constant\">x86</code> personalities but no others. The personality feature is useful when running 32-bit\n        services on a 64-bit host system. If not specified, the personality is left unmodified and thus reflects the\n        personality of the host system's kernel.</p>",
                "IgnoreSIGPIPE": "<p>Takes a boolean argument. If true, causes <code class=\"constant\">SIGPIPE</code> to be ignored in the\n        executed process. Defaults to true because <code class=\"constant\">SIGPIPE</code> generally is useful only in shell\n        pipelines.</p>",
                "Nice": "<p>Sets the default nice level (scheduling priority) for executed processes. Takes an integer\n        between -20 (highest priority) and 19 (lowest priority). See\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/setpriority.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">setpriority</span>(2)</span></a> for\n        details.</p>",
                "CPUSchedulingPolicy": "<p>Sets the CPU scheduling policy for executed processes. Takes one of <code class=\"option\">other</code>,\n        <code class=\"option\">batch</code>, <code class=\"option\">idle</code>, <code class=\"option\">fifo</code> or <code class=\"option\">rr</code>. See\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/sched_setscheduler.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">sched_setscheduler</span>(2)</span></a> for\n        details.</p>",
                "CPUSchedulingPriority": "<p>Sets the CPU scheduling priority for executed processes. The available priority range depends\n        on the selected CPU scheduling policy (see above). For real-time scheduling policies an integer between 1\n        (lowest priority) and 99 (highest priority) can be used. See\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/sched_setscheduler.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">sched_setscheduler</span>(2)</span></a> for\n        details. </p>",
                "CPUSchedulingResetOnFork": "<p>Takes a boolean argument. If true, elevated CPU scheduling priorities and policies will be\n        reset when the executed processes fork, and can hence not leak into child processes. See\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/sched_setscheduler.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">sched_setscheduler</span>(2)</span></a> for\n        details. Defaults to false.</p>",
                "CPUAffinity": "<p>Controls the CPU affinity of the executed processes. Takes a list of CPU indices or ranges\n        separated by either whitespace or commas. Alternatively, takes a special \"numa\" value in which case systemd\n        automatically derives allowed CPU range based on the value of <code class=\"varname\">NUMAMask=</code> option. CPU ranges\n        are specified by the lower and upper CPU indices separated by a dash. This option may be specified more than\n        once, in which case the specified CPU affinity masks are merged. If the empty string is assigned, the mask\n        is reset, all assignments prior to this will have no effect. See\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/sched_setaffinity.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">sched_setaffinity</span>(2)</span></a> for\n        details.</p>",
                "NUMAPolicy": "<p>Controls the NUMA memory policy of the executed processes. Takes a policy type, one of:\n        <code class=\"option\">default</code>, <code class=\"option\">preferred</code>, <code class=\"option\">bind</code>, <code class=\"option\">interleave</code> and\n        <code class=\"option\">local</code>. A list of NUMA nodes that should be associated with the policy must be specified\n        in <code class=\"varname\">NUMAMask=</code>. For more details on each policy please see,\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/set_mempolicy.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">set_mempolicy</span>(2)</span></a>. For overall\n        overview of NUMA support in Linux see,\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/numa.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">numa</span>(7)</span></a>.\n        </p>",
                "NUMAMask": "<p>Controls the NUMA node list which will be applied alongside with selected NUMA policy.\n        Takes a list of NUMA nodes and has the same syntax as a list of CPUs for <code class=\"varname\">CPUAffinity=</code>\n        option. Note that the list of NUMA nodes is not required for <code class=\"option\">default</code> and <code class=\"option\">local</code>\n        policies and for <code class=\"option\">preferred</code> policy we expect a single NUMA node.</p>",
                "IOSchedulingClass": "<p>Sets the I/O scheduling class for executed processes. Takes an integer between 0 and 3 or one\n        of the strings <code class=\"option\">none</code>, <code class=\"option\">realtime</code>, <code class=\"option\">best-effort</code> or\n        <code class=\"option\">idle</code>. If the empty string is assigned to this option, all prior assignments to both\n        <code class=\"varname\">IOSchedulingClass=</code> and <code class=\"varname\">IOSchedulingPriority=</code> have no effect. See\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/ioprio_set.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">ioprio_set</span>(2)</span></a> for\n        details.</p>",
                "IOSchedulingPriority": "<p>Sets the I/O scheduling priority for executed processes. Takes an integer between 0 (highest\n        priority) and 7 (lowest priority). The available priorities depend on the selected I/O scheduling class (see\n        above). If the empty string is assigned to this option, all prior assignments to both\n        <code class=\"varname\">IOSchedulingClass=</code> and <code class=\"varname\">IOSchedulingPriority=</code> have no effect.\n        See <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/ioprio_set.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">ioprio_set</span>(2)</span></a> for\n        details.</p>",
                "ProtectSystem": "<p>Takes a boolean argument or the special values \"<code class=\"literal\">full</code>\" or\n        \"<code class=\"literal\">strict</code>\". If true, mounts the <code class=\"filename\">/usr</code> and the boot loader\n        directories (<code class=\"filename\">/boot</code> and <code class=\"filename\">/efi</code>) read-only for processes\n        invoked by this unit. If set to \"<code class=\"literal\">full</code>\", the <code class=\"filename\">/etc</code> directory is\n        mounted read-only, too. If set to \"<code class=\"literal\">strict</code>\" the entire file system hierarchy is\n        mounted read-only, except for the API file system subtrees <code class=\"filename\">/dev</code>,\n        <code class=\"filename\">/proc</code> and <code class=\"filename\">/sys</code> (protect these directories using\n        <code class=\"varname\">PrivateDevices=</code>, <code class=\"varname\">ProtectKernelTunables=</code>,\n        <code class=\"varname\">ProtectControlGroups=</code>). This setting ensures that any modification of the vendor-supplied\n        operating system (and optionally its configuration, and local mounts) is prohibited for the service.  It is\n        recommended to enable this setting for all long-running services, unless they are involved with system updates\n        or need to modify the operating system in other ways. If this option is used,\n        <code class=\"varname\">ReadWritePaths=</code> may be used to exclude specific directories from being made read-only. This\n        setting is implied if <code class=\"varname\">DynamicUser=</code> is set. This setting cannot ensure protection in all\n        cases. In general it has the same limitations as <code class=\"varname\">ReadOnlyPaths=</code>, see below. Defaults to\n        off.</p>",
                "ProtectHome": "<p>Takes a boolean argument or the special values \"<code class=\"literal\">read-only</code>\" or\n        \"<code class=\"literal\">tmpfs</code>\". If true, the directories <code class=\"filename\">/home</code>,\n        <code class=\"filename\">/root</code>, and <code class=\"filename\">/run/user</code> are made inaccessible and empty for\n        processes invoked by this unit. If set to \"<code class=\"literal\">read-only</code>\", the three directories are\n        made read-only instead. If set to \"<code class=\"literal\">tmpfs</code>\", temporary file systems are mounted on the\n        three directories in read-only mode. The value \"<code class=\"literal\">tmpfs</code>\" is useful to hide home\n        directories not relevant to the processes invoked by the unit, while still allowing necessary\n        directories to be made visible when listed in <code class=\"varname\">BindPaths=</code> or\n        <code class=\"varname\">BindReadOnlyPaths=</code>.</p><p>Setting this to \"<code class=\"literal\">yes</code>\" is mostly equivalent to set the three directories in\n        <code class=\"varname\">InaccessiblePaths=</code>. Similarly, \"<code class=\"literal\">read-only</code>\" is mostly equivalent to\n        <code class=\"varname\">ReadOnlyPaths=</code>, and \"<code class=\"literal\">tmpfs</code>\" is mostly equivalent to\n        <code class=\"varname\">TemporaryFileSystem=</code> with \"<code class=\"literal\">:ro</code>\".</p><p>It is recommended to enable this setting for all long-running services (in particular\n        network-facing ones), to ensure they cannot get access to private user data, unless the services\n        actually require access to the user's private data. This setting is implied if\n        <code class=\"varname\">DynamicUser=</code> is set. This setting cannot ensure protection in all cases. In\n        general it has the same limitations as <code class=\"varname\">ReadOnlyPaths=</code>, see below.</p><p><a target=\"__blank\" name=\"singular\"></a>This option is only available for system services and is not supported for services\nrunning in per-user instances of the service manager.</p>",
                "RuntimeDirectory": "<p>These options take a whitespace-separated list of directory names. The specified directory\n        names must be relative, and may not include \"<code class=\"literal\">..</code>\". If set, one or more\n        directories by the specified names will be created (including their parents) below the locations\n        defined in the following table, when the unit is started. Also, the corresponding environment variable\n        is defined with the full path of directories. If multiple directories are set, then in the environment variable\n        the paths are concatenated with colon (\"<code class=\"literal\">:</code>\").</p><div class=\"table\"><a target=\"__blank\" name=\"id-1.14.4.3.6.2\"></a><p class=\"title\"><b>Table&nbsp;2.&nbsp;Automatic directory creation and environment variables</b></p><div class=\"table-contents\"><table class=\"table\" summary=\"Automatic directory creation and environment variables\" border=\"1\"><colgroup><col><col><col><col></colgroup><thead><tr><th>Directory</th><th>Below path for system units</th><th>Below path for user units</th><th>Environment variable set</th></tr></thead><tbody><tr><td><code class=\"varname\">RuntimeDirectory=</code></td><td><code class=\"filename\">/run/</code></td><td><code class=\"varname\">$XDG_RUNTIME_DIR</code></td><td><code class=\"varname\">$RUNTIME_DIRECTORY</code></td></tr><tr><td><code class=\"varname\">StateDirectory=</code></td><td><code class=\"filename\">/var/lib/</code></td><td><code class=\"varname\">$XDG_CONFIG_HOME</code></td><td><code class=\"varname\">$STATE_DIRECTORY</code></td></tr><tr><td><code class=\"varname\">CacheDirectory=</code></td><td><code class=\"filename\">/var/cache/</code></td><td><code class=\"varname\">$XDG_CACHE_HOME</code></td><td><code class=\"varname\">$CACHE_DIRECTORY</code></td></tr><tr><td><code class=\"varname\">LogsDirectory=</code></td><td><code class=\"filename\">/var/log/</code></td><td><code class=\"varname\">$XDG_CONFIG_HOME</code><code class=\"filename\">/log/</code></td><td><code class=\"varname\">$LOGS_DIRECTORY</code></td></tr><tr><td><code class=\"varname\">ConfigurationDirectory=</code></td><td><code class=\"filename\">/etc/</code></td><td><code class=\"varname\">$XDG_CONFIG_HOME</code></td><td><code class=\"varname\">$CONFIGURATION_DIRECTORY</code></td></tr></tbody></table></div></div><br class=\"table-break\"><p>In case of <code class=\"varname\">RuntimeDirectory=</code> the innermost subdirectories are removed when\n        the unit is stopped. It is possible to preserve the specified directories in this case if\n        <code class=\"varname\">RuntimeDirectoryPreserve=</code> is configured to <code class=\"option\">restart</code> or\n        <code class=\"option\">yes</code> (see below). The directories specified with <code class=\"varname\">StateDirectory=</code>,\n        <code class=\"varname\">CacheDirectory=</code>, <code class=\"varname\">LogsDirectory=</code>,\n        <code class=\"varname\">ConfigurationDirectory=</code> are not removed when the unit is stopped.</p><p>Except in case of <code class=\"varname\">ConfigurationDirectory=</code>, the innermost specified directories will be\n        owned by the user and group specified in <code class=\"varname\">User=</code> and <code class=\"varname\">Group=</code>. If the\n        specified directories already exist and their owning user or group do not match the configured ones, all files\n        and directories below the specified directories as well as the directories themselves will have their file\n        ownership recursively changed to match what is configured. As an optimization, if the specified directories are\n        already owned by the right user and group, files and directories below of them are left as-is, even if they do\n        not match what is requested. The innermost specified directories will have their access mode adjusted to the\n        what is specified in <code class=\"varname\">RuntimeDirectoryMode=</code>, <code class=\"varname\">StateDirectoryMode=</code>,\n        <code class=\"varname\">CacheDirectoryMode=</code>, <code class=\"varname\">LogsDirectoryMode=</code> and\n        <code class=\"varname\">ConfigurationDirectoryMode=</code>.</p><p>These options imply <code class=\"varname\">BindPaths=</code> for the specified paths. When combined with\n        <code class=\"varname\">RootDirectory=</code> or <code class=\"varname\">RootImage=</code> these paths always reside on the host and\n        are mounted from there into the unit's file system namespace.</p><p>If <code class=\"varname\">DynamicUser=</code> is used in conjunction with\n        <code class=\"varname\">StateDirectory=</code>, the logic for <code class=\"varname\">CacheDirectory=</code> and\n        <code class=\"varname\">LogsDirectory=</code> is slightly altered: the directories are created below\n        <code class=\"filename\">/var/lib/private</code>, <code class=\"filename\">/var/cache/private</code> and\n        <code class=\"filename\">/var/log/private</code>, respectively, which are host directories made inaccessible to\n        unprivileged users, which ensures that access to these directories cannot be gained through dynamic\n        user ID recycling. Symbolic links are created to hide this difference in behaviour. Both from\n        perspective of the host and from inside the unit, the relevant directories hence always appear\n        directly below <code class=\"filename\">/var/lib</code>, <code class=\"filename\">/var/cache</code> and\n        <code class=\"filename\">/var/log</code>.</p><p>Use <code class=\"varname\">RuntimeDirectory=</code> to manage one or more runtime directories for the unit and bind\n        their lifetime to the daemon runtime. This is particularly useful for unprivileged daemons that cannot create\n        runtime directories in <code class=\"filename\">/run</code> due to lack of privileges, and to make sure the runtime\n        directory is cleaned up automatically after use. For runtime directories that require more complex or different\n        configuration or lifetime guarantees, please consider using\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">tmpfiles.d</span>(5)</span></a>.</p><p>The directories defined by these options are always created under the standard paths used by systemd\n        (<code class=\"filename\">/var</code>, <code class=\"filename\">/run</code>, <code class=\"filename\">/etc</code>, …). If the service needs\n        directories in a different location, a different mechanism has to be used to create them.</p><p><a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">tmpfiles.d</span>(5)</span></a> provides\n        functionality that overlaps with these options. Using these options is recommended, because the lifetime of\n        the directories is tied directly to the lifetime of the unit, and it is not necessary to ensure that the\n        <code class=\"filename\">tmpfiles.d</code> configuration is executed before the unit is started.</p><p>To remove any of the directories created by these settings, use the <span class=\"command\"><strong>systemctl clean\n        …</strong></span> command on the relevant units, see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemctl.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemctl</span>(1)</span></a> for\n        details.</p><p>Example: if a system service unit has the following,\n        </p><pre class=\"programlisting\">RuntimeDirectory=foo/bar baz</pre><p>\n        the service manager creates <code class=\"filename\">/run/foo</code> (if it does not exist),\n\n        <code class=\"filename\">/run/foo/bar</code>, and <code class=\"filename\">/run/baz</code>. The\n        directories <code class=\"filename\">/run/foo/bar</code> and\n        <code class=\"filename\">/run/baz</code> except <code class=\"filename\">/run/foo</code> are\n        owned by the user and group specified in <code class=\"varname\">User=</code> and <code class=\"varname\">Group=</code>, and removed\n        when the service is stopped.</p><p>Example: if a system service unit has the following,\n        </p><pre class=\"programlisting\">RuntimeDirectory=foo/bar\nStateDirectory=aaa/bbb ccc</pre><p>\n        then the environment variable \"<code class=\"literal\">RUNTIME_DIRECTORY</code>\" is set with \"<code class=\"literal\">/run/foo/bar</code>\", and\n        \"<code class=\"literal\">STATE_DIRECTORY</code>\" is set with \"<code class=\"literal\">/var/lib/aaa/bbb:/var/lib/ccc</code>\".</p>",
                "StateDirectory": "<p>These options take a whitespace-separated list of directory names. The specified directory\n        names must be relative, and may not include \"<code class=\"literal\">..</code>\". If set, one or more\n        directories by the specified names will be created (including their parents) below the locations\n        defined in the following table, when the unit is started. Also, the corresponding environment variable\n        is defined with the full path of directories. If multiple directories are set, then in the environment variable\n        the paths are concatenated with colon (\"<code class=\"literal\">:</code>\").</p><div class=\"table\"><a target=\"__blank\" name=\"id-1.14.4.3.6.2\"></a><p class=\"title\"><b>Table&nbsp;2.&nbsp;Automatic directory creation and environment variables</b></p><div class=\"table-contents\"><table class=\"table\" summary=\"Automatic directory creation and environment variables\" border=\"1\"><colgroup><col><col><col><col></colgroup><thead><tr><th>Directory</th><th>Below path for system units</th><th>Below path for user units</th><th>Environment variable set</th></tr></thead><tbody><tr><td><code class=\"varname\">RuntimeDirectory=</code></td><td><code class=\"filename\">/run/</code></td><td><code class=\"varname\">$XDG_RUNTIME_DIR</code></td><td><code class=\"varname\">$RUNTIME_DIRECTORY</code></td></tr><tr><td><code class=\"varname\">StateDirectory=</code></td><td><code class=\"filename\">/var/lib/</code></td><td><code class=\"varname\">$XDG_CONFIG_HOME</code></td><td><code class=\"varname\">$STATE_DIRECTORY</code></td></tr><tr><td><code class=\"varname\">CacheDirectory=</code></td><td><code class=\"filename\">/var/cache/</code></td><td><code class=\"varname\">$XDG_CACHE_HOME</code></td><td><code class=\"varname\">$CACHE_DIRECTORY</code></td></tr><tr><td><code class=\"varname\">LogsDirectory=</code></td><td><code class=\"filename\">/var/log/</code></td><td><code class=\"varname\">$XDG_CONFIG_HOME</code><code class=\"filename\">/log/</code></td><td><code class=\"varname\">$LOGS_DIRECTORY</code></td></tr><tr><td><code class=\"varname\">ConfigurationDirectory=</code></td><td><code class=\"filename\">/etc/</code></td><td><code class=\"varname\">$XDG_CONFIG_HOME</code></td><td><code class=\"varname\">$CONFIGURATION_DIRECTORY</code></td></tr></tbody></table></div></div><br class=\"table-break\"><p>In case of <code class=\"varname\">RuntimeDirectory=</code> the innermost subdirectories are removed when\n        the unit is stopped. It is possible to preserve the specified directories in this case if\n        <code class=\"varname\">RuntimeDirectoryPreserve=</code> is configured to <code class=\"option\">restart</code> or\n        <code class=\"option\">yes</code> (see below). The directories specified with <code class=\"varname\">StateDirectory=</code>,\n        <code class=\"varname\">CacheDirectory=</code>, <code class=\"varname\">LogsDirectory=</code>,\n        <code class=\"varname\">ConfigurationDirectory=</code> are not removed when the unit is stopped.</p><p>Except in case of <code class=\"varname\">ConfigurationDirectory=</code>, the innermost specified directories will be\n        owned by the user and group specified in <code class=\"varname\">User=</code> and <code class=\"varname\">Group=</code>. If the\n        specified directories already exist and their owning user or group do not match the configured ones, all files\n        and directories below the specified directories as well as the directories themselves will have their file\n        ownership recursively changed to match what is configured. As an optimization, if the specified directories are\n        already owned by the right user and group, files and directories below of them are left as-is, even if they do\n        not match what is requested. The innermost specified directories will have their access mode adjusted to the\n        what is specified in <code class=\"varname\">RuntimeDirectoryMode=</code>, <code class=\"varname\">StateDirectoryMode=</code>,\n        <code class=\"varname\">CacheDirectoryMode=</code>, <code class=\"varname\">LogsDirectoryMode=</code> and\n        <code class=\"varname\">ConfigurationDirectoryMode=</code>.</p><p>These options imply <code class=\"varname\">BindPaths=</code> for the specified paths. When combined with\n        <code class=\"varname\">RootDirectory=</code> or <code class=\"varname\">RootImage=</code> these paths always reside on the host and\n        are mounted from there into the unit's file system namespace.</p><p>If <code class=\"varname\">DynamicUser=</code> is used in conjunction with\n        <code class=\"varname\">StateDirectory=</code>, the logic for <code class=\"varname\">CacheDirectory=</code> and\n        <code class=\"varname\">LogsDirectory=</code> is slightly altered: the directories are created below\n        <code class=\"filename\">/var/lib/private</code>, <code class=\"filename\">/var/cache/private</code> and\n        <code class=\"filename\">/var/log/private</code>, respectively, which are host directories made inaccessible to\n        unprivileged users, which ensures that access to these directories cannot be gained through dynamic\n        user ID recycling. Symbolic links are created to hide this difference in behaviour. Both from\n        perspective of the host and from inside the unit, the relevant directories hence always appear\n        directly below <code class=\"filename\">/var/lib</code>, <code class=\"filename\">/var/cache</code> and\n        <code class=\"filename\">/var/log</code>.</p><p>Use <code class=\"varname\">RuntimeDirectory=</code> to manage one or more runtime directories for the unit and bind\n        their lifetime to the daemon runtime. This is particularly useful for unprivileged daemons that cannot create\n        runtime directories in <code class=\"filename\">/run</code> due to lack of privileges, and to make sure the runtime\n        directory is cleaned up automatically after use. For runtime directories that require more complex or different\n        configuration or lifetime guarantees, please consider using\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">tmpfiles.d</span>(5)</span></a>.</p><p>The directories defined by these options are always created under the standard paths used by systemd\n        (<code class=\"filename\">/var</code>, <code class=\"filename\">/run</code>, <code class=\"filename\">/etc</code>, …). If the service needs\n        directories in a different location, a different mechanism has to be used to create them.</p><p><a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">tmpfiles.d</span>(5)</span></a> provides\n        functionality that overlaps with these options. Using these options is recommended, because the lifetime of\n        the directories is tied directly to the lifetime of the unit, and it is not necessary to ensure that the\n        <code class=\"filename\">tmpfiles.d</code> configuration is executed before the unit is started.</p><p>To remove any of the directories created by these settings, use the <span class=\"command\"><strong>systemctl clean\n        …</strong></span> command on the relevant units, see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemctl.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemctl</span>(1)</span></a> for\n        details.</p><p>Example: if a system service unit has the following,\n        </p><pre class=\"programlisting\">RuntimeDirectory=foo/bar baz</pre><p>\n        the service manager creates <code class=\"filename\">/run/foo</code> (if it does not exist),\n\n        <code class=\"filename\">/run/foo/bar</code>, and <code class=\"filename\">/run/baz</code>. The\n        directories <code class=\"filename\">/run/foo/bar</code> and\n        <code class=\"filename\">/run/baz</code> except <code class=\"filename\">/run/foo</code> are\n        owned by the user and group specified in <code class=\"varname\">User=</code> and <code class=\"varname\">Group=</code>, and removed\n        when the service is stopped.</p><p>Example: if a system service unit has the following,\n        </p><pre class=\"programlisting\">RuntimeDirectory=foo/bar\nStateDirectory=aaa/bbb ccc</pre><p>\n        then the environment variable \"<code class=\"literal\">RUNTIME_DIRECTORY</code>\" is set with \"<code class=\"literal\">/run/foo/bar</code>\", and\n        \"<code class=\"literal\">STATE_DIRECTORY</code>\" is set with \"<code class=\"literal\">/var/lib/aaa/bbb:/var/lib/ccc</code>\".</p>",
                "CacheDirectory": "<p>These options take a whitespace-separated list of directory names. The specified directory\n        names must be relative, and may not include \"<code class=\"literal\">..</code>\". If set, one or more\n        directories by the specified names will be created (including their parents) below the locations\n        defined in the following table, when the unit is started. Also, the corresponding environment variable\n        is defined with the full path of directories. If multiple directories are set, then in the environment variable\n        the paths are concatenated with colon (\"<code class=\"literal\">:</code>\").</p><div class=\"table\"><a target=\"__blank\" name=\"id-1.14.4.3.6.2\"></a><p class=\"title\"><b>Table&nbsp;2.&nbsp;Automatic directory creation and environment variables</b></p><div class=\"table-contents\"><table class=\"table\" summary=\"Automatic directory creation and environment variables\" border=\"1\"><colgroup><col><col><col><col></colgroup><thead><tr><th>Directory</th><th>Below path for system units</th><th>Below path for user units</th><th>Environment variable set</th></tr></thead><tbody><tr><td><code class=\"varname\">RuntimeDirectory=</code></td><td><code class=\"filename\">/run/</code></td><td><code class=\"varname\">$XDG_RUNTIME_DIR</code></td><td><code class=\"varname\">$RUNTIME_DIRECTORY</code></td></tr><tr><td><code class=\"varname\">StateDirectory=</code></td><td><code class=\"filename\">/var/lib/</code></td><td><code class=\"varname\">$XDG_CONFIG_HOME</code></td><td><code class=\"varname\">$STATE_DIRECTORY</code></td></tr><tr><td><code class=\"varname\">CacheDirectory=</code></td><td><code class=\"filename\">/var/cache/</code></td><td><code class=\"varname\">$XDG_CACHE_HOME</code></td><td><code class=\"varname\">$CACHE_DIRECTORY</code></td></tr><tr><td><code class=\"varname\">LogsDirectory=</code></td><td><code class=\"filename\">/var/log/</code></td><td><code class=\"varname\">$XDG_CONFIG_HOME</code><code class=\"filename\">/log/</code></td><td><code class=\"varname\">$LOGS_DIRECTORY</code></td></tr><tr><td><code class=\"varname\">ConfigurationDirectory=</code></td><td><code class=\"filename\">/etc/</code></td><td><code class=\"varname\">$XDG_CONFIG_HOME</code></td><td><code class=\"varname\">$CONFIGURATION_DIRECTORY</code></td></tr></tbody></table></div></div><br class=\"table-break\"><p>In case of <code class=\"varname\">RuntimeDirectory=</code> the innermost subdirectories are removed when\n        the unit is stopped. It is possible to preserve the specified directories in this case if\n        <code class=\"varname\">RuntimeDirectoryPreserve=</code> is configured to <code class=\"option\">restart</code> or\n        <code class=\"option\">yes</code> (see below). The directories specified with <code class=\"varname\">StateDirectory=</code>,\n        <code class=\"varname\">CacheDirectory=</code>, <code class=\"varname\">LogsDirectory=</code>,\n        <code class=\"varname\">ConfigurationDirectory=</code> are not removed when the unit is stopped.</p><p>Except in case of <code class=\"varname\">ConfigurationDirectory=</code>, the innermost specified directories will be\n        owned by the user and group specified in <code class=\"varname\">User=</code> and <code class=\"varname\">Group=</code>. If the\n        specified directories already exist and their owning user or group do not match the configured ones, all files\n        and directories below the specified directories as well as the directories themselves will have their file\n        ownership recursively changed to match what is configured. As an optimization, if the specified directories are\n        already owned by the right user and group, files and directories below of them are left as-is, even if they do\n        not match what is requested. The innermost specified directories will have their access mode adjusted to the\n        what is specified in <code class=\"varname\">RuntimeDirectoryMode=</code>, <code class=\"varname\">StateDirectoryMode=</code>,\n        <code class=\"varname\">CacheDirectoryMode=</code>, <code class=\"varname\">LogsDirectoryMode=</code> and\n        <code class=\"varname\">ConfigurationDirectoryMode=</code>.</p><p>These options imply <code class=\"varname\">BindPaths=</code> for the specified paths. When combined with\n        <code class=\"varname\">RootDirectory=</code> or <code class=\"varname\">RootImage=</code> these paths always reside on the host and\n        are mounted from there into the unit's file system namespace.</p><p>If <code class=\"varname\">DynamicUser=</code> is used in conjunction with\n        <code class=\"varname\">StateDirectory=</code>, the logic for <code class=\"varname\">CacheDirectory=</code> and\n        <code class=\"varname\">LogsDirectory=</code> is slightly altered: the directories are created below\n        <code class=\"filename\">/var/lib/private</code>, <code class=\"filename\">/var/cache/private</code> and\n        <code class=\"filename\">/var/log/private</code>, respectively, which are host directories made inaccessible to\n        unprivileged users, which ensures that access to these directories cannot be gained through dynamic\n        user ID recycling. Symbolic links are created to hide this difference in behaviour. Both from\n        perspective of the host and from inside the unit, the relevant directories hence always appear\n        directly below <code class=\"filename\">/var/lib</code>, <code class=\"filename\">/var/cache</code> and\n        <code class=\"filename\">/var/log</code>.</p><p>Use <code class=\"varname\">RuntimeDirectory=</code> to manage one or more runtime directories for the unit and bind\n        their lifetime to the daemon runtime. This is particularly useful for unprivileged daemons that cannot create\n        runtime directories in <code class=\"filename\">/run</code> due to lack of privileges, and to make sure the runtime\n        directory is cleaned up automatically after use. For runtime directories that require more complex or different\n        configuration or lifetime guarantees, please consider using\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">tmpfiles.d</span>(5)</span></a>.</p><p>The directories defined by these options are always created under the standard paths used by systemd\n        (<code class=\"filename\">/var</code>, <code class=\"filename\">/run</code>, <code class=\"filename\">/etc</code>, …). If the service needs\n        directories in a different location, a different mechanism has to be used to create them.</p><p><a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">tmpfiles.d</span>(5)</span></a> provides\n        functionality that overlaps with these options. Using these options is recommended, because the lifetime of\n        the directories is tied directly to the lifetime of the unit, and it is not necessary to ensure that the\n        <code class=\"filename\">tmpfiles.d</code> configuration is executed before the unit is started.</p><p>To remove any of the directories created by these settings, use the <span class=\"command\"><strong>systemctl clean\n        …</strong></span> command on the relevant units, see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemctl.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemctl</span>(1)</span></a> for\n        details.</p><p>Example: if a system service unit has the following,\n        </p><pre class=\"programlisting\">RuntimeDirectory=foo/bar baz</pre><p>\n        the service manager creates <code class=\"filename\">/run/foo</code> (if it does not exist),\n\n        <code class=\"filename\">/run/foo/bar</code>, and <code class=\"filename\">/run/baz</code>. The\n        directories <code class=\"filename\">/run/foo/bar</code> and\n        <code class=\"filename\">/run/baz</code> except <code class=\"filename\">/run/foo</code> are\n        owned by the user and group specified in <code class=\"varname\">User=</code> and <code class=\"varname\">Group=</code>, and removed\n        when the service is stopped.</p><p>Example: if a system service unit has the following,\n        </p><pre class=\"programlisting\">RuntimeDirectory=foo/bar\nStateDirectory=aaa/bbb ccc</pre><p>\n        then the environment variable \"<code class=\"literal\">RUNTIME_DIRECTORY</code>\" is set with \"<code class=\"literal\">/run/foo/bar</code>\", and\n        \"<code class=\"literal\">STATE_DIRECTORY</code>\" is set with \"<code class=\"literal\">/var/lib/aaa/bbb:/var/lib/ccc</code>\".</p>",
                "LogsDirectory": "<p>These options take a whitespace-separated list of directory names. The specified directory\n        names must be relative, and may not include \"<code class=\"literal\">..</code>\". If set, one or more\n        directories by the specified names will be created (including their parents) below the locations\n        defined in the following table, when the unit is started. Also, the corresponding environment variable\n        is defined with the full path of directories. If multiple directories are set, then in the environment variable\n        the paths are concatenated with colon (\"<code class=\"literal\">:</code>\").</p><div class=\"table\"><a target=\"__blank\" name=\"id-1.14.4.3.6.2\"></a><p class=\"title\"><b>Table&nbsp;2.&nbsp;Automatic directory creation and environment variables</b></p><div class=\"table-contents\"><table class=\"table\" summary=\"Automatic directory creation and environment variables\" border=\"1\"><colgroup><col><col><col><col></colgroup><thead><tr><th>Directory</th><th>Below path for system units</th><th>Below path for user units</th><th>Environment variable set</th></tr></thead><tbody><tr><td><code class=\"varname\">RuntimeDirectory=</code></td><td><code class=\"filename\">/run/</code></td><td><code class=\"varname\">$XDG_RUNTIME_DIR</code></td><td><code class=\"varname\">$RUNTIME_DIRECTORY</code></td></tr><tr><td><code class=\"varname\">StateDirectory=</code></td><td><code class=\"filename\">/var/lib/</code></td><td><code class=\"varname\">$XDG_CONFIG_HOME</code></td><td><code class=\"varname\">$STATE_DIRECTORY</code></td></tr><tr><td><code class=\"varname\">CacheDirectory=</code></td><td><code class=\"filename\">/var/cache/</code></td><td><code class=\"varname\">$XDG_CACHE_HOME</code></td><td><code class=\"varname\">$CACHE_DIRECTORY</code></td></tr><tr><td><code class=\"varname\">LogsDirectory=</code></td><td><code class=\"filename\">/var/log/</code></td><td><code class=\"varname\">$XDG_CONFIG_HOME</code><code class=\"filename\">/log/</code></td><td><code class=\"varname\">$LOGS_DIRECTORY</code></td></tr><tr><td><code class=\"varname\">ConfigurationDirectory=</code></td><td><code class=\"filename\">/etc/</code></td><td><code class=\"varname\">$XDG_CONFIG_HOME</code></td><td><code class=\"varname\">$CONFIGURATION_DIRECTORY</code></td></tr></tbody></table></div></div><br class=\"table-break\"><p>In case of <code class=\"varname\">RuntimeDirectory=</code> the innermost subdirectories are removed when\n        the unit is stopped. It is possible to preserve the specified directories in this case if\n        <code class=\"varname\">RuntimeDirectoryPreserve=</code> is configured to <code class=\"option\">restart</code> or\n        <code class=\"option\">yes</code> (see below). The directories specified with <code class=\"varname\">StateDirectory=</code>,\n        <code class=\"varname\">CacheDirectory=</code>, <code class=\"varname\">LogsDirectory=</code>,\n        <code class=\"varname\">ConfigurationDirectory=</code> are not removed when the unit is stopped.</p><p>Except in case of <code class=\"varname\">ConfigurationDirectory=</code>, the innermost specified directories will be\n        owned by the user and group specified in <code class=\"varname\">User=</code> and <code class=\"varname\">Group=</code>. If the\n        specified directories already exist and their owning user or group do not match the configured ones, all files\n        and directories below the specified directories as well as the directories themselves will have their file\n        ownership recursively changed to match what is configured. As an optimization, if the specified directories are\n        already owned by the right user and group, files and directories below of them are left as-is, even if they do\n        not match what is requested. The innermost specified directories will have their access mode adjusted to the\n        what is specified in <code class=\"varname\">RuntimeDirectoryMode=</code>, <code class=\"varname\">StateDirectoryMode=</code>,\n        <code class=\"varname\">CacheDirectoryMode=</code>, <code class=\"varname\">LogsDirectoryMode=</code> and\n        <code class=\"varname\">ConfigurationDirectoryMode=</code>.</p><p>These options imply <code class=\"varname\">BindPaths=</code> for the specified paths. When combined with\n        <code class=\"varname\">RootDirectory=</code> or <code class=\"varname\">RootImage=</code> these paths always reside on the host and\n        are mounted from there into the unit's file system namespace.</p><p>If <code class=\"varname\">DynamicUser=</code> is used in conjunction with\n        <code class=\"varname\">StateDirectory=</code>, the logic for <code class=\"varname\">CacheDirectory=</code> and\n        <code class=\"varname\">LogsDirectory=</code> is slightly altered: the directories are created below\n        <code class=\"filename\">/var/lib/private</code>, <code class=\"filename\">/var/cache/private</code> and\n        <code class=\"filename\">/var/log/private</code>, respectively, which are host directories made inaccessible to\n        unprivileged users, which ensures that access to these directories cannot be gained through dynamic\n        user ID recycling. Symbolic links are created to hide this difference in behaviour. Both from\n        perspective of the host and from inside the unit, the relevant directories hence always appear\n        directly below <code class=\"filename\">/var/lib</code>, <code class=\"filename\">/var/cache</code> and\n        <code class=\"filename\">/var/log</code>.</p><p>Use <code class=\"varname\">RuntimeDirectory=</code> to manage one or more runtime directories for the unit and bind\n        their lifetime to the daemon runtime. This is particularly useful for unprivileged daemons that cannot create\n        runtime directories in <code class=\"filename\">/run</code> due to lack of privileges, and to make sure the runtime\n        directory is cleaned up automatically after use. For runtime directories that require more complex or different\n        configuration or lifetime guarantees, please consider using\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">tmpfiles.d</span>(5)</span></a>.</p><p>The directories defined by these options are always created under the standard paths used by systemd\n        (<code class=\"filename\">/var</code>, <code class=\"filename\">/run</code>, <code class=\"filename\">/etc</code>, …). If the service needs\n        directories in a different location, a different mechanism has to be used to create them.</p><p><a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">tmpfiles.d</span>(5)</span></a> provides\n        functionality that overlaps with these options. Using these options is recommended, because the lifetime of\n        the directories is tied directly to the lifetime of the unit, and it is not necessary to ensure that the\n        <code class=\"filename\">tmpfiles.d</code> configuration is executed before the unit is started.</p><p>To remove any of the directories created by these settings, use the <span class=\"command\"><strong>systemctl clean\n        …</strong></span> command on the relevant units, see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemctl.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemctl</span>(1)</span></a> for\n        details.</p><p>Example: if a system service unit has the following,\n        </p><pre class=\"programlisting\">RuntimeDirectory=foo/bar baz</pre><p>\n        the service manager creates <code class=\"filename\">/run/foo</code> (if it does not exist),\n\n        <code class=\"filename\">/run/foo/bar</code>, and <code class=\"filename\">/run/baz</code>. The\n        directories <code class=\"filename\">/run/foo/bar</code> and\n        <code class=\"filename\">/run/baz</code> except <code class=\"filename\">/run/foo</code> are\n        owned by the user and group specified in <code class=\"varname\">User=</code> and <code class=\"varname\">Group=</code>, and removed\n        when the service is stopped.</p><p>Example: if a system service unit has the following,\n        </p><pre class=\"programlisting\">RuntimeDirectory=foo/bar\nStateDirectory=aaa/bbb ccc</pre><p>\n        then the environment variable \"<code class=\"literal\">RUNTIME_DIRECTORY</code>\" is set with \"<code class=\"literal\">/run/foo/bar</code>\", and\n        \"<code class=\"literal\">STATE_DIRECTORY</code>\" is set with \"<code class=\"literal\">/var/lib/aaa/bbb:/var/lib/ccc</code>\".</p>",
                "ConfigurationDirectory": "<p>These options take a whitespace-separated list of directory names. The specified directory\n        names must be relative, and may not include \"<code class=\"literal\">..</code>\". If set, one or more\n        directories by the specified names will be created (including their parents) below the locations\n        defined in the following table, when the unit is started. Also, the corresponding environment variable\n        is defined with the full path of directories. If multiple directories are set, then in the environment variable\n        the paths are concatenated with colon (\"<code class=\"literal\">:</code>\").</p><div class=\"table\"><a target=\"__blank\" name=\"id-1.14.4.3.6.2\"></a><p class=\"title\"><b>Table&nbsp;2.&nbsp;Automatic directory creation and environment variables</b></p><div class=\"table-contents\"><table class=\"table\" summary=\"Automatic directory creation and environment variables\" border=\"1\"><colgroup><col><col><col><col></colgroup><thead><tr><th>Directory</th><th>Below path for system units</th><th>Below path for user units</th><th>Environment variable set</th></tr></thead><tbody><tr><td><code class=\"varname\">RuntimeDirectory=</code></td><td><code class=\"filename\">/run/</code></td><td><code class=\"varname\">$XDG_RUNTIME_DIR</code></td><td><code class=\"varname\">$RUNTIME_DIRECTORY</code></td></tr><tr><td><code class=\"varname\">StateDirectory=</code></td><td><code class=\"filename\">/var/lib/</code></td><td><code class=\"varname\">$XDG_CONFIG_HOME</code></td><td><code class=\"varname\">$STATE_DIRECTORY</code></td></tr><tr><td><code class=\"varname\">CacheDirectory=</code></td><td><code class=\"filename\">/var/cache/</code></td><td><code class=\"varname\">$XDG_CACHE_HOME</code></td><td><code class=\"varname\">$CACHE_DIRECTORY</code></td></tr><tr><td><code class=\"varname\">LogsDirectory=</code></td><td><code class=\"filename\">/var/log/</code></td><td><code class=\"varname\">$XDG_CONFIG_HOME</code><code class=\"filename\">/log/</code></td><td><code class=\"varname\">$LOGS_DIRECTORY</code></td></tr><tr><td><code class=\"varname\">ConfigurationDirectory=</code></td><td><code class=\"filename\">/etc/</code></td><td><code class=\"varname\">$XDG_CONFIG_HOME</code></td><td><code class=\"varname\">$CONFIGURATION_DIRECTORY</code></td></tr></tbody></table></div></div><br class=\"table-break\"><p>In case of <code class=\"varname\">RuntimeDirectory=</code> the innermost subdirectories are removed when\n        the unit is stopped. It is possible to preserve the specified directories in this case if\n        <code class=\"varname\">RuntimeDirectoryPreserve=</code> is configured to <code class=\"option\">restart</code> or\n        <code class=\"option\">yes</code> (see below). The directories specified with <code class=\"varname\">StateDirectory=</code>,\n        <code class=\"varname\">CacheDirectory=</code>, <code class=\"varname\">LogsDirectory=</code>,\n        <code class=\"varname\">ConfigurationDirectory=</code> are not removed when the unit is stopped.</p><p>Except in case of <code class=\"varname\">ConfigurationDirectory=</code>, the innermost specified directories will be\n        owned by the user and group specified in <code class=\"varname\">User=</code> and <code class=\"varname\">Group=</code>. If the\n        specified directories already exist and their owning user or group do not match the configured ones, all files\n        and directories below the specified directories as well as the directories themselves will have their file\n        ownership recursively changed to match what is configured. As an optimization, if the specified directories are\n        already owned by the right user and group, files and directories below of them are left as-is, even if they do\n        not match what is requested. The innermost specified directories will have their access mode adjusted to the\n        what is specified in <code class=\"varname\">RuntimeDirectoryMode=</code>, <code class=\"varname\">StateDirectoryMode=</code>,\n        <code class=\"varname\">CacheDirectoryMode=</code>, <code class=\"varname\">LogsDirectoryMode=</code> and\n        <code class=\"varname\">ConfigurationDirectoryMode=</code>.</p><p>These options imply <code class=\"varname\">BindPaths=</code> for the specified paths. When combined with\n        <code class=\"varname\">RootDirectory=</code> or <code class=\"varname\">RootImage=</code> these paths always reside on the host and\n        are mounted from there into the unit's file system namespace.</p><p>If <code class=\"varname\">DynamicUser=</code> is used in conjunction with\n        <code class=\"varname\">StateDirectory=</code>, the logic for <code class=\"varname\">CacheDirectory=</code> and\n        <code class=\"varname\">LogsDirectory=</code> is slightly altered: the directories are created below\n        <code class=\"filename\">/var/lib/private</code>, <code class=\"filename\">/var/cache/private</code> and\n        <code class=\"filename\">/var/log/private</code>, respectively, which are host directories made inaccessible to\n        unprivileged users, which ensures that access to these directories cannot be gained through dynamic\n        user ID recycling. Symbolic links are created to hide this difference in behaviour. Both from\n        perspective of the host and from inside the unit, the relevant directories hence always appear\n        directly below <code class=\"filename\">/var/lib</code>, <code class=\"filename\">/var/cache</code> and\n        <code class=\"filename\">/var/log</code>.</p><p>Use <code class=\"varname\">RuntimeDirectory=</code> to manage one or more runtime directories for the unit and bind\n        their lifetime to the daemon runtime. This is particularly useful for unprivileged daemons that cannot create\n        runtime directories in <code class=\"filename\">/run</code> due to lack of privileges, and to make sure the runtime\n        directory is cleaned up automatically after use. For runtime directories that require more complex or different\n        configuration or lifetime guarantees, please consider using\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">tmpfiles.d</span>(5)</span></a>.</p><p>The directories defined by these options are always created under the standard paths used by systemd\n        (<code class=\"filename\">/var</code>, <code class=\"filename\">/run</code>, <code class=\"filename\">/etc</code>, …). If the service needs\n        directories in a different location, a different mechanism has to be used to create them.</p><p><a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">tmpfiles.d</span>(5)</span></a> provides\n        functionality that overlaps with these options. Using these options is recommended, because the lifetime of\n        the directories is tied directly to the lifetime of the unit, and it is not necessary to ensure that the\n        <code class=\"filename\">tmpfiles.d</code> configuration is executed before the unit is started.</p><p>To remove any of the directories created by these settings, use the <span class=\"command\"><strong>systemctl clean\n        …</strong></span> command on the relevant units, see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemctl.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemctl</span>(1)</span></a> for\n        details.</p><p>Example: if a system service unit has the following,\n        </p><pre class=\"programlisting\">RuntimeDirectory=foo/bar baz</pre><p>\n        the service manager creates <code class=\"filename\">/run/foo</code> (if it does not exist),\n\n        <code class=\"filename\">/run/foo/bar</code>, and <code class=\"filename\">/run/baz</code>. The\n        directories <code class=\"filename\">/run/foo/bar</code> and\n        <code class=\"filename\">/run/baz</code> except <code class=\"filename\">/run/foo</code> are\n        owned by the user and group specified in <code class=\"varname\">User=</code> and <code class=\"varname\">Group=</code>, and removed\n        when the service is stopped.</p><p>Example: if a system service unit has the following,\n        </p><pre class=\"programlisting\">RuntimeDirectory=foo/bar\nStateDirectory=aaa/bbb ccc</pre><p>\n        then the environment variable \"<code class=\"literal\">RUNTIME_DIRECTORY</code>\" is set with \"<code class=\"literal\">/run/foo/bar</code>\", and\n        \"<code class=\"literal\">STATE_DIRECTORY</code>\" is set with \"<code class=\"literal\">/var/lib/aaa/bbb:/var/lib/ccc</code>\".</p>",
                "RuntimeDirectoryMode": "<p>Specifies the access mode of the directories specified in <code class=\"varname\">RuntimeDirectory=</code>,\n        <code class=\"varname\">StateDirectory=</code>, <code class=\"varname\">CacheDirectory=</code>, <code class=\"varname\">LogsDirectory=</code>, or\n        <code class=\"varname\">ConfigurationDirectory=</code>, respectively, as an octal number.  Defaults to\n        <code class=\"constant\">0755</code>. See \"Permissions\" in <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/path_resolution.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">path_resolution</span>(7)</span></a> for a\n        discussion of the meaning of permission bits.</p>",
                "StateDirectoryMode": "<p>Specifies the access mode of the directories specified in <code class=\"varname\">RuntimeDirectory=</code>,\n        <code class=\"varname\">StateDirectory=</code>, <code class=\"varname\">CacheDirectory=</code>, <code class=\"varname\">LogsDirectory=</code>, or\n        <code class=\"varname\">ConfigurationDirectory=</code>, respectively, as an octal number.  Defaults to\n        <code class=\"constant\">0755</code>. See \"Permissions\" in <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/path_resolution.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">path_resolution</span>(7)</span></a> for a\n        discussion of the meaning of permission bits.</p>",
                "CacheDirectoryMode": "<p>Specifies the access mode of the directories specified in <code class=\"varname\">RuntimeDirectory=</code>,\n        <code class=\"varname\">StateDirectory=</code>, <code class=\"varname\">CacheDirectory=</code>, <code class=\"varname\">LogsDirectory=</code>, or\n        <code class=\"varname\">ConfigurationDirectory=</code>, respectively, as an octal number.  Defaults to\n        <code class=\"constant\">0755</code>. See \"Permissions\" in <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/path_resolution.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">path_resolution</span>(7)</span></a> for a\n        discussion of the meaning of permission bits.</p>",
                "LogsDirectoryMode": "<p>Specifies the access mode of the directories specified in <code class=\"varname\">RuntimeDirectory=</code>,\n        <code class=\"varname\">StateDirectory=</code>, <code class=\"varname\">CacheDirectory=</code>, <code class=\"varname\">LogsDirectory=</code>, or\n        <code class=\"varname\">ConfigurationDirectory=</code>, respectively, as an octal number.  Defaults to\n        <code class=\"constant\">0755</code>. See \"Permissions\" in <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/path_resolution.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">path_resolution</span>(7)</span></a> for a\n        discussion of the meaning of permission bits.</p>",
                "ConfigurationDirectoryMode": "<p>Specifies the access mode of the directories specified in <code class=\"varname\">RuntimeDirectory=</code>,\n        <code class=\"varname\">StateDirectory=</code>, <code class=\"varname\">CacheDirectory=</code>, <code class=\"varname\">LogsDirectory=</code>, or\n        <code class=\"varname\">ConfigurationDirectory=</code>, respectively, as an octal number.  Defaults to\n        <code class=\"constant\">0755</code>. See \"Permissions\" in <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/path_resolution.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">path_resolution</span>(7)</span></a> for a\n        discussion of the meaning of permission bits.</p>",
                "RuntimeDirectoryPreserve": "<p>Takes a boolean argument or <code class=\"option\">restart</code>.  If set to <code class=\"option\">no</code> (the\n        default), the directories specified in <code class=\"varname\">RuntimeDirectory=</code> are always removed when the service\n        stops. If set to <code class=\"option\">restart</code> the directories are preserved when the service is both automatically\n        and manually restarted. Here, the automatic restart means the operation specified in\n        <code class=\"varname\">Restart=</code>, and manual restart means the one triggered by <span class=\"command\"><strong>systemctl restart\n        foo.service</strong></span>. If set to <code class=\"option\">yes</code>, then the directories are not removed when the service is\n        stopped. Note that since the runtime directory <code class=\"filename\">/run</code> is a mount point of\n        \"<code class=\"literal\">tmpfs</code>\", then for system services the directories specified in\n        <code class=\"varname\">RuntimeDirectory=</code> are removed when the system is rebooted.</p>",
                "TimeoutCleanSec": "<p>Configures a timeout on the clean-up operation requested through <span class=\"command\"><strong>systemctl\n        clean …</strong></span>, see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemctl.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemctl</span>(1)</span></a> for\n        details. Takes the usual time values and defaults to <code class=\"constant\">infinity</code>, i.e. by default\n        no timeout is applied. If a timeout is configured the clean operation will be aborted forcibly when\n        the timeout is reached, potentially leaving resources on disk.</p>",
                "ReadWritePaths": "<p>Sets up a new file system namespace for executed processes. These options may be used to limit\n        access a process might have to the file system hierarchy. Each setting takes a space-separated list of paths\n        relative to the host's root directory (i.e. the system running the service manager).  Note that if paths\n        contain symlinks, they are resolved relative to the root directory set with\n        <code class=\"varname\">RootDirectory=</code>/<code class=\"varname\">RootImage=</code>.</p><p>Paths listed in <code class=\"varname\">ReadWritePaths=</code> are accessible from within the namespace\n        with the same access modes as from outside of it. Paths listed in <code class=\"varname\">ReadOnlyPaths=</code>\n        are accessible for reading only, writing will be refused even if the usual file access controls would\n        permit this. Nest <code class=\"varname\">ReadWritePaths=</code> inside of <code class=\"varname\">ReadOnlyPaths=</code> in\n        order to provide writable subdirectories within read-only directories. Use\n        <code class=\"varname\">ReadWritePaths=</code> in order to allow-list specific paths for write access if\n        <code class=\"varname\">ProtectSystem=strict</code> is used.</p><p>Paths listed in <code class=\"varname\">InaccessiblePaths=</code> will be made inaccessible for processes inside\n        the namespace along with everything below them in the file system hierarchy. This may be more restrictive than\n        desired, because it is not possible to nest <code class=\"varname\">ReadWritePaths=</code>, <code class=\"varname\">ReadOnlyPaths=</code>,\n        <code class=\"varname\">BindPaths=</code>, or <code class=\"varname\">BindReadOnlyPaths=</code> inside it. For a more flexible option,\n        see <code class=\"varname\">TemporaryFileSystem=</code>.</p><p>Non-directory paths may be specified as well. These options may be specified more than once,\n        in which case all paths listed will have limited access from within the namespace. If the empty string is\n        assigned to this option, the specific list is reset, and all prior assignments have no effect.</p><p>Paths in <code class=\"varname\">ReadWritePaths=</code>, <code class=\"varname\">ReadOnlyPaths=</code> and\n        <code class=\"varname\">InaccessiblePaths=</code> may be prefixed with \"<code class=\"literal\">-</code>\", in which case they will be\n        ignored when they do not exist. If prefixed with \"<code class=\"literal\">+</code>\" the paths are taken relative to the root\n        directory of the unit, as configured with <code class=\"varname\">RootDirectory=</code>/<code class=\"varname\">RootImage=</code>,\n        instead of relative to the root directory of the host (see above). When combining \"<code class=\"literal\">-</code>\" and\n        \"<code class=\"literal\">+</code>\" on the same path make sure to specify \"<code class=\"literal\">-</code>\" first, and \"<code class=\"literal\">+</code>\"\n        second.</p><p>Note that these settings will disconnect propagation of mounts from the unit's processes to the\n        host. This means that this setting may not be used for services which shall be able to install mount points in\n        the main mount namespace. For <code class=\"varname\">ReadWritePaths=</code> and <code class=\"varname\">ReadOnlyPaths=</code>\n        propagation in the other direction is not affected, i.e. mounts created on the host generally appear in the\n        unit processes' namespace, and mounts removed on the host also disappear there too. In particular, note that\n        mount propagation from host to unit will result in unmodified mounts to be created in the unit's namespace,\n        i.e. writable mounts appearing on the host will be writable in the unit's namespace too, even when propagated\n        below a path marked with <code class=\"varname\">ReadOnlyPaths=</code>! Restricting access with these options hence does\n        not extend to submounts of a directory that are created later on. This means the lock-down offered by that\n        setting is not complete, and does not offer full protection. </p><p>Note that the effect of these settings may be undone by privileged processes. In order to set up an\n        effective sandboxed environment for a unit it is thus recommended to combine these settings with either\n        <code class=\"varname\">CapabilityBoundingSet=~CAP_SYS_ADMIN</code> or\n        <code class=\"varname\">SystemCallFilter=~@mount</code>.</p><p><a target=\"__blank\" name=\"plural\"></a>These options are only available for system services and are not supported for services\nrunning in per-user instances of the service manager.</p>",
                "ReadOnlyPaths": "<p>Sets up a new file system namespace for executed processes. These options may be used to limit\n        access a process might have to the file system hierarchy. Each setting takes a space-separated list of paths\n        relative to the host's root directory (i.e. the system running the service manager).  Note that if paths\n        contain symlinks, they are resolved relative to the root directory set with\n        <code class=\"varname\">RootDirectory=</code>/<code class=\"varname\">RootImage=</code>.</p><p>Paths listed in <code class=\"varname\">ReadWritePaths=</code> are accessible from within the namespace\n        with the same access modes as from outside of it. Paths listed in <code class=\"varname\">ReadOnlyPaths=</code>\n        are accessible for reading only, writing will be refused even if the usual file access controls would\n        permit this. Nest <code class=\"varname\">ReadWritePaths=</code> inside of <code class=\"varname\">ReadOnlyPaths=</code> in\n        order to provide writable subdirectories within read-only directories. Use\n        <code class=\"varname\">ReadWritePaths=</code> in order to allow-list specific paths for write access if\n        <code class=\"varname\">ProtectSystem=strict</code> is used.</p><p>Paths listed in <code class=\"varname\">InaccessiblePaths=</code> will be made inaccessible for processes inside\n        the namespace along with everything below them in the file system hierarchy. This may be more restrictive than\n        desired, because it is not possible to nest <code class=\"varname\">ReadWritePaths=</code>, <code class=\"varname\">ReadOnlyPaths=</code>,\n        <code class=\"varname\">BindPaths=</code>, or <code class=\"varname\">BindReadOnlyPaths=</code> inside it. For a more flexible option,\n        see <code class=\"varname\">TemporaryFileSystem=</code>.</p><p>Non-directory paths may be specified as well. These options may be specified more than once,\n        in which case all paths listed will have limited access from within the namespace. If the empty string is\n        assigned to this option, the specific list is reset, and all prior assignments have no effect.</p><p>Paths in <code class=\"varname\">ReadWritePaths=</code>, <code class=\"varname\">ReadOnlyPaths=</code> and\n        <code class=\"varname\">InaccessiblePaths=</code> may be prefixed with \"<code class=\"literal\">-</code>\", in which case they will be\n        ignored when they do not exist. If prefixed with \"<code class=\"literal\">+</code>\" the paths are taken relative to the root\n        directory of the unit, as configured with <code class=\"varname\">RootDirectory=</code>/<code class=\"varname\">RootImage=</code>,\n        instead of relative to the root directory of the host (see above). When combining \"<code class=\"literal\">-</code>\" and\n        \"<code class=\"literal\">+</code>\" on the same path make sure to specify \"<code class=\"literal\">-</code>\" first, and \"<code class=\"literal\">+</code>\"\n        second.</p><p>Note that these settings will disconnect propagation of mounts from the unit's processes to the\n        host. This means that this setting may not be used for services which shall be able to install mount points in\n        the main mount namespace. For <code class=\"varname\">ReadWritePaths=</code> and <code class=\"varname\">ReadOnlyPaths=</code>\n        propagation in the other direction is not affected, i.e. mounts created on the host generally appear in the\n        unit processes' namespace, and mounts removed on the host also disappear there too. In particular, note that\n        mount propagation from host to unit will result in unmodified mounts to be created in the unit's namespace,\n        i.e. writable mounts appearing on the host will be writable in the unit's namespace too, even when propagated\n        below a path marked with <code class=\"varname\">ReadOnlyPaths=</code>! Restricting access with these options hence does\n        not extend to submounts of a directory that are created later on. This means the lock-down offered by that\n        setting is not complete, and does not offer full protection. </p><p>Note that the effect of these settings may be undone by privileged processes. In order to set up an\n        effective sandboxed environment for a unit it is thus recommended to combine these settings with either\n        <code class=\"varname\">CapabilityBoundingSet=~CAP_SYS_ADMIN</code> or\n        <code class=\"varname\">SystemCallFilter=~@mount</code>.</p><p><a target=\"__blank\" name=\"plural\"></a>These options are only available for system services and are not supported for services\nrunning in per-user instances of the service manager.</p>",
                "InaccessiblePaths": "<p>Sets up a new file system namespace for executed processes. These options may be used to limit\n        access a process might have to the file system hierarchy. Each setting takes a space-separated list of paths\n        relative to the host's root directory (i.e. the system running the service manager).  Note that if paths\n        contain symlinks, they are resolved relative to the root directory set with\n        <code class=\"varname\">RootDirectory=</code>/<code class=\"varname\">RootImage=</code>.</p><p>Paths listed in <code class=\"varname\">ReadWritePaths=</code> are accessible from within the namespace\n        with the same access modes as from outside of it. Paths listed in <code class=\"varname\">ReadOnlyPaths=</code>\n        are accessible for reading only, writing will be refused even if the usual file access controls would\n        permit this. Nest <code class=\"varname\">ReadWritePaths=</code> inside of <code class=\"varname\">ReadOnlyPaths=</code> in\n        order to provide writable subdirectories within read-only directories. Use\n        <code class=\"varname\">ReadWritePaths=</code> in order to allow-list specific paths for write access if\n        <code class=\"varname\">ProtectSystem=strict</code> is used.</p><p>Paths listed in <code class=\"varname\">InaccessiblePaths=</code> will be made inaccessible for processes inside\n        the namespace along with everything below them in the file system hierarchy. This may be more restrictive than\n        desired, because it is not possible to nest <code class=\"varname\">ReadWritePaths=</code>, <code class=\"varname\">ReadOnlyPaths=</code>,\n        <code class=\"varname\">BindPaths=</code>, or <code class=\"varname\">BindReadOnlyPaths=</code> inside it. For a more flexible option,\n        see <code class=\"varname\">TemporaryFileSystem=</code>.</p><p>Non-directory paths may be specified as well. These options may be specified more than once,\n        in which case all paths listed will have limited access from within the namespace. If the empty string is\n        assigned to this option, the specific list is reset, and all prior assignments have no effect.</p><p>Paths in <code class=\"varname\">ReadWritePaths=</code>, <code class=\"varname\">ReadOnlyPaths=</code> and\n        <code class=\"varname\">InaccessiblePaths=</code> may be prefixed with \"<code class=\"literal\">-</code>\", in which case they will be\n        ignored when they do not exist. If prefixed with \"<code class=\"literal\">+</code>\" the paths are taken relative to the root\n        directory of the unit, as configured with <code class=\"varname\">RootDirectory=</code>/<code class=\"varname\">RootImage=</code>,\n        instead of relative to the root directory of the host (see above). When combining \"<code class=\"literal\">-</code>\" and\n        \"<code class=\"literal\">+</code>\" on the same path make sure to specify \"<code class=\"literal\">-</code>\" first, and \"<code class=\"literal\">+</code>\"\n        second.</p><p>Note that these settings will disconnect propagation of mounts from the unit's processes to the\n        host. This means that this setting may not be used for services which shall be able to install mount points in\n        the main mount namespace. For <code class=\"varname\">ReadWritePaths=</code> and <code class=\"varname\">ReadOnlyPaths=</code>\n        propagation in the other direction is not affected, i.e. mounts created on the host generally appear in the\n        unit processes' namespace, and mounts removed on the host also disappear there too. In particular, note that\n        mount propagation from host to unit will result in unmodified mounts to be created in the unit's namespace,\n        i.e. writable mounts appearing on the host will be writable in the unit's namespace too, even when propagated\n        below a path marked with <code class=\"varname\">ReadOnlyPaths=</code>! Restricting access with these options hence does\n        not extend to submounts of a directory that are created later on. This means the lock-down offered by that\n        setting is not complete, and does not offer full protection. </p><p>Note that the effect of these settings may be undone by privileged processes. In order to set up an\n        effective sandboxed environment for a unit it is thus recommended to combine these settings with either\n        <code class=\"varname\">CapabilityBoundingSet=~CAP_SYS_ADMIN</code> or\n        <code class=\"varname\">SystemCallFilter=~@mount</code>.</p><p><a target=\"__blank\" name=\"plural\"></a>These options are only available for system services and are not supported for services\nrunning in per-user instances of the service manager.</p>",
                "TemporaryFileSystem": "<p>Takes a space-separated list of mount points for temporary file systems (tmpfs). If set, a new file\n        system namespace is set up for executed processes, and a temporary file system is mounted on each mount point.\n        This option may be specified more than once, in which case temporary file systems are mounted on all listed mount\n        points. If the empty string is assigned to this option, the list is reset, and all prior assignments have no effect.\n        Each mount point may optionally be suffixed with a colon (\"<code class=\"literal\">:</code>\") and mount options such as\n        \"<code class=\"literal\">size=10%</code>\" or \"<code class=\"literal\">ro</code>\". By default, each temporary file system is mounted\n        with \"<code class=\"literal\">nodev,strictatime,mode=0755</code>\". These can be disabled by explicitly specifying the corresponding\n        mount options, e.g., \"<code class=\"literal\">dev</code>\" or \"<code class=\"literal\">nostrictatime</code>\".</p><p>This is useful to hide files or directories not relevant to the processes invoked by the unit, while necessary\n        files or directories can be still accessed by combining with <code class=\"varname\">BindPaths=</code> or\n        <code class=\"varname\">BindReadOnlyPaths=</code>:</p><p>Example: if a unit has the following,\n        </p><pre class=\"programlisting\">TemporaryFileSystem=/var:ro\nBindReadOnlyPaths=/var/lib/systemd</pre><p>\n        then the invoked processes by the unit cannot see any files or directories under <code class=\"filename\">/var</code> except for\n        <code class=\"filename\">/var/lib/systemd</code> or its contents.</p><p><a target=\"__blank\" name=\"singular\"></a>This option is only available for system services and is not supported for services\nrunning in per-user instances of the service manager.</p>",
                "PrivateTmp": "<p>Takes a boolean argument. If true, sets up a new file system namespace for the executed\n        processes and mounts private <code class=\"filename\">/tmp/</code> and <code class=\"filename\">/var/tmp/</code> directories inside it\n        that are not shared by processes outside of the namespace. This is useful to secure access to temporary files of\n        the process, but makes sharing between processes via <code class=\"filename\">/tmp</code> or <code class=\"filename\">/var/tmp</code>\n        impossible. If this is enabled, all temporary files created by a service in these directories will be removed\n        after the service is stopped.  Defaults to false. It is possible to run two or more units within the same\n        private <code class=\"filename\">/tmp</code> and <code class=\"filename\">/var/tmp</code> namespace by using the\n        <code class=\"varname\">JoinsNamespaceOf=</code> directive, see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.unit.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.unit</span>(5)</span></a> for\n        details. This setting is implied if <code class=\"varname\">DynamicUser=</code> is set. For this setting the same\n        restrictions regarding mount propagation and privileges apply as for <code class=\"varname\">ReadOnlyPaths=</code> and\n        related calls, see above. Enabling this setting has the side effect of adding <code class=\"varname\">Requires=</code> and\n        <code class=\"varname\">After=</code> dependencies on all mount units necessary to access <code class=\"filename\">/tmp</code> and\n        <code class=\"filename\">/var/tmp</code>. Moreover an implicitly <code class=\"varname\">After=</code> ordering on\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd-tmpfiles-setup.service.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd-tmpfiles-setup.service</span>(8)</span></a>\n        is added.</p><p>Note that the implementation of this setting might be impossible (for example if mount namespaces are not\n        available), and the unit should be written in a way that does not solely rely on this setting for\n        security.</p><p><a target=\"__blank\" name=\"singular\"></a>This option is only available for system services and is not supported for services\nrunning in per-user instances of the service manager.</p>",
                "PrivateDevices": "<p>Takes a boolean argument. If true, sets up a new <code class=\"filename\">/dev</code> mount for the\n        executed processes and only adds API pseudo devices such as <code class=\"filename\">/dev/null</code>,\n        <code class=\"filename\">/dev/zero</code> or <code class=\"filename\">/dev/random</code> (as well as the pseudo TTY subsystem) to it,\n        but no physical devices such as <code class=\"filename\">/dev/sda</code>, system memory <code class=\"filename\">/dev/mem</code>,\n        system ports <code class=\"filename\">/dev/port</code> and others. This is useful to securely turn off physical device\n        access by the executed process. Defaults to false. Enabling this option will install a system call filter to\n        block low-level I/O system calls that are grouped in the <code class=\"varname\">@raw-io</code> set, will also remove\n        <code class=\"constant\">CAP_MKNOD</code> and <code class=\"constant\">CAP_SYS_RAWIO</code> from the capability bounding set for the\n        unit (see above), and set <code class=\"varname\">DevicePolicy=closed</code> (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.resource-control</span>(5)</span></a>\n        for details). Note that using this setting will disconnect propagation of mounts from the service to the host\n        (propagation in the opposite direction continues to work).  This means that this setting may not be used for\n        services which shall be able to install mount points in the main mount namespace. The new\n        <code class=\"filename\">/dev</code> will be mounted read-only and 'noexec'. The latter may break old programs which try\n        to set up executable memory by using\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/mmap.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">mmap</span>(2)</span></a> of\n        <code class=\"filename\">/dev/zero</code> instead of using <code class=\"constant\">MAP_ANON</code>. For this setting the same\n        restrictions regarding mount propagation and privileges apply as for <code class=\"varname\">ReadOnlyPaths=</code> and\n        related calls, see above.  If turned on and if running in user mode, or in system mode, but without the\n        <code class=\"constant\">CAP_SYS_ADMIN</code> capability (e.g. setting <code class=\"varname\">User=</code>),\n        <code class=\"varname\">NoNewPrivileges=yes</code> is implied.</p><p>Note that the implementation of this setting might be impossible (for example if mount namespaces are not\n        available), and the unit should be written in a way that does not solely rely on this setting for\n        security.</p><p><a target=\"__blank\" name=\"singular\"></a>This option is only available for system services and is not supported for services\nrunning in per-user instances of the service manager.</p>",
                "PrivateNetwork": "<p>Takes a boolean argument. If true, sets up a new network namespace for the executed processes\n        and configures only the loopback network device \"<code class=\"literal\">lo</code>\" inside it. No other network devices will\n        be available to the executed process. This is useful to turn off network access by the executed process.\n        Defaults to false. It is possible to run two or more units within the same private network namespace by using\n        the <code class=\"varname\">JoinsNamespaceOf=</code> directive, see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.unit.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.unit</span>(5)</span></a> for\n        details. Note that this option will disconnect all socket families from the host, including\n        <code class=\"constant\">AF_NETLINK</code> and <code class=\"constant\">AF_UNIX</code>. Effectively, for\n        <code class=\"constant\">AF_NETLINK</code> this means that device configuration events received from\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd-udevd.service.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd-udevd.service</span>(8)</span></a> are\n        not delivered to the unit's processes. And for <code class=\"constant\">AF_UNIX</code> this has the effect that\n        <code class=\"constant\">AF_UNIX</code> sockets in the abstract socket namespace of the host will become unavailable to\n        the unit's processes (however, those located in the file system will continue to be accessible).</p><p>Note that the implementation of this setting might be impossible (for example if network namespaces are\n        not available), and the unit should be written in a way that does not solely rely on this setting for\n        security.</p><p>When this option is used on a socket unit any sockets bound on behalf of this unit will be\n        bound within a private network namespace. This may be combined with\n        <code class=\"varname\">JoinsNamespaceOf=</code> to listen on sockets inside of network namespaces of other\n        services.</p><p><a target=\"__blank\" name=\"singular\"></a>This option is only available for system services and is not supported for services\nrunning in per-user instances of the service manager.</p>",
                "NetworkNamespacePath": "<p>Takes an absolute file system path refererring to a Linux network namespace\n        pseudo-file (i.e. a file like <code class=\"filename\">/proc/$PID/ns/net</code> or a bind mount or symlink to\n        one). When set the invoked processes are added to the network namespace referenced by that path. The\n        path has to point to a valid namespace file at the moment the processes are forked off. If this\n        option is used <code class=\"varname\">PrivateNetwork=</code> has no effect. If this option is used together with\n        <code class=\"varname\">JoinsNamespaceOf=</code> then it only has an effect if this unit is started before any of\n        the listed units that have <code class=\"varname\">PrivateNetwork=</code> or\n        <code class=\"varname\">NetworkNamespacePath=</code> configured, as otherwise the network namespace of those\n        units is reused.</p><p>When this option is used on a socket unit any sockets bound on behalf of this unit will be\n        bound within the specified network namespace.</p><p><a target=\"__blank\" name=\"singular\"></a>This option is only available for system services and is not supported for services\nrunning in per-user instances of the service manager.</p>",
                "PrivateUsers": "<p>Takes a boolean argument. If true, sets up a new user namespace for the executed processes and\n        configures a minimal user and group mapping, that maps the \"<code class=\"literal\">root</code>\" user and group as well as\n        the unit's own user and group to themselves and everything else to the \"<code class=\"literal\">nobody</code>\" user and\n        group. This is useful to securely detach the user and group databases used by the unit from the rest of the\n        system, and thus to create an effective sandbox environment. All files, directories, processes, IPC objects and\n        other resources owned by users/groups not equaling \"<code class=\"literal\">root</code>\" or the unit's own will stay visible\n        from within the unit but appear owned by the \"<code class=\"literal\">nobody</code>\" user and group. If this mode is enabled,\n        all unit processes are run without privileges in the host user namespace (regardless if the unit's own\n        user/group is \"<code class=\"literal\">root</code>\" or not). Specifically this means that the process will have zero process\n        capabilities on the host's user namespace, but full capabilities within the service's user namespace. Settings\n        such as <code class=\"varname\">CapabilityBoundingSet=</code> will affect only the latter, and there's no way to acquire\n        additional capabilities in the host's user namespace. Defaults to off.</p><p>When this setting is set up by a per-user instance of the service manager, the mapping of the\n        \"<code class=\"literal\">root</code>\" user and group to itself is omitted (unless the user manager is root).\n        Additionally, in the per-user instance manager case, the\n        user namespace will be set up before most other namespaces. This means that combining\n        <code class=\"varname\">PrivateUsers=</code><code class=\"option\">true</code> with other namespaces will enable use of features not\n        normally supported by the per-user instances of the service manager.</p><p>This setting is particularly useful in conjunction with\n        <code class=\"varname\">RootDirectory=</code>/<code class=\"varname\">RootImage=</code>, as the need to synchronize the user and group\n        databases in the root directory and on the host is reduced, as the only users and groups who need to be matched\n        are \"<code class=\"literal\">root</code>\", \"<code class=\"literal\">nobody</code>\" and the unit's own user and group.</p><p>Note that the implementation of this setting might be impossible (for example if user namespaces are not\n        available), and the unit should be written in a way that does not solely rely on this setting for\n        security.</p>",
                "ProtectHostname": "<p>Takes a boolean argument. When set, sets up a new UTS namespace for the executed\n        processes. In addition, changing hostname or domainname is prevented. Defaults to off.</p><p>Note that the implementation of this setting might be impossible (for example if UTS namespaces\n        are not available), and the unit should be written in a way that does not solely rely on this setting\n        for security.</p><p>Note that when this option is enabled for a service hostname changes no longer propagate from\n        the system into the service, it is hence not suitable for services that need to take notice of system\n        hostname changes dynamically.</p><p><a target=\"__blank\" name=\"singular\"></a>This option is only available for system services and is not supported for services\nrunning in per-user instances of the service manager.</p>",
                "ProtectClock": "<p>Takes a boolean argument. If set, writes to the hardware clock or system clock will be denied.\n        It is recommended to turn this on for most services that do not need modify the clock. Defaults to off. Enabling\n        this option removes <code class=\"constant\">CAP_SYS_TIME</code> and <code class=\"constant\">CAP_WAKE_ALARM</code> from the\n        capability bounding set for this unit, installs a system call filter to block calls that can set the\n        clock, and <code class=\"varname\">DeviceAllow=char-rtc r</code> is implied. This ensures <code class=\"filename\">/dev/rtc0</code>,\n        <code class=\"filename\">/dev/rtc1</code>, etc. are made read-only to the service. See\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.resource-control</span>(5)</span></a>\n        for the details about <code class=\"varname\">DeviceAllow=</code>.</p><p><a target=\"__blank\" name=\"singular\"></a>This option is only available for system services and is not supported for services\nrunning in per-user instances of the service manager.</p>",
                "ProtectKernelTunables": "<p>Takes a boolean argument. If true, kernel variables accessible through\n        <code class=\"filename\">/proc/sys</code>, <code class=\"filename\">/sys</code>, <code class=\"filename\">/proc/sysrq-trigger</code>,\n        <code class=\"filename\">/proc/latency_stats</code>, <code class=\"filename\">/proc/acpi</code>,\n        <code class=\"filename\">/proc/timer_stats</code>, <code class=\"filename\">/proc/fs</code> and <code class=\"filename\">/proc/irq</code> will\n        be made read-only to all processes of the unit. Usually, tunable kernel variables should be initialized only at\n        boot-time, for example with the\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/sysctl.d.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">sysctl.d</span>(5)</span></a> mechanism. Few\n        services need to write to these at runtime; it is hence recommended to turn this on for most services. For this\n        setting the same restrictions regarding mount propagation and privileges apply as for\n        <code class=\"varname\">ReadOnlyPaths=</code> and related calls, see above. Defaults to off.  If turned on and if running\n        in user mode, or in system mode, but without the <code class=\"constant\">CAP_SYS_ADMIN</code> capability (e.g.  services\n        for which <code class=\"varname\">User=</code> is set), <code class=\"varname\">NoNewPrivileges=yes</code> is implied. Note that this\n        option does not prevent indirect changes to kernel tunables effected by IPC calls to other processes. However,\n        <code class=\"varname\">InaccessiblePaths=</code> may be used to make relevant IPC file system objects inaccessible. If\n        <code class=\"varname\">ProtectKernelTunables=</code> is set, <code class=\"varname\">MountAPIVFS=yes</code> is\n        implied.</p><p><a target=\"__blank\" name=\"singular\"></a>This option is only available for system services and is not supported for services\nrunning in per-user instances of the service manager.</p>",
                "ProtectKernelModules": "<p>Takes a boolean argument. If true, explicit module loading will be denied. This allows\n        module load and unload operations to be turned off on modular kernels. It is recommended to turn this on for most services\n        that do not need special file systems or extra kernel modules to work. Defaults to off. Enabling this option\n        removes <code class=\"constant\">CAP_SYS_MODULE</code> from the capability bounding set for the unit, and installs a\n        system call filter to block module system calls, also <code class=\"filename\">/usr/lib/modules</code> is made\n        inaccessible. For this setting the same restrictions regarding mount propagation and privileges apply as for\n        <code class=\"varname\">ReadOnlyPaths=</code> and related calls, see above.  Note that limited automatic module loading due\n        to user configuration or kernel mapping tables might still happen as side effect of requested user operations,\n        both privileged and unprivileged. To disable module auto-load feature please see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/sysctl.d.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">sysctl.d</span>(5)</span></a>\n        <code class=\"constant\">kernel.modules_disabled</code> mechanism and\n        <code class=\"filename\">/proc/sys/kernel/modules_disabled</code> documentation.  If turned on and if running in user\n        mode, or in system mode, but without the <code class=\"constant\">CAP_SYS_ADMIN</code> capability (e.g. setting\n        <code class=\"varname\">User=</code>), <code class=\"varname\">NoNewPrivileges=yes</code> is implied.</p><p><a target=\"__blank\" name=\"singular\"></a>This option is only available for system services and is not supported for services\nrunning in per-user instances of the service manager.</p>",
                "ProtectKernelLogs": "<p>Takes a boolean argument. If true, access to the kernel log ring buffer will be denied. It is\n        recommended to turn this on for most services that do not need to read from or write to the kernel log ring\n        buffer. Enabling this option removes <code class=\"constant\">CAP_SYSLOG</code> from the capability bounding set for this\n        unit, and installs a system call filter to block the\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/syslog.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">syslog</span>(2)</span></a>\n        system call (not to be confused with the libc API\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man3/syslog.3.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">syslog</span>(3)</span></a>\n        for userspace logging). The kernel exposes its log buffer to userspace via <code class=\"filename\">/dev/kmsg</code> and\n        <code class=\"filename\">/proc/kmsg</code>. If enabled, these are made inaccessible to all the processes in the unit.</p><p><a target=\"__blank\" name=\"singular\"></a>This option is only available for system services and is not supported for services\nrunning in per-user instances of the service manager.</p>",
                "ProtectControlGroups": "<p>Takes a boolean argument. If true, the Linux Control Groups (<a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/cgroups.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">cgroups</span>(7)</span></a>) hierarchies\n        accessible through <code class=\"filename\">/sys/fs/cgroup</code> will be made read-only to all processes of the\n        unit. Except for container managers no services should require write access to the control groups hierarchies;\n        it is hence recommended to turn this on for most services. For this setting the same restrictions regarding\n        mount propagation and privileges apply as for <code class=\"varname\">ReadOnlyPaths=</code> and related calls, see\n        above. Defaults to off. If <code class=\"varname\">ProtectControlGroups=</code> is set, <code class=\"varname\">MountAPIVFS=yes</code>\n        is implied.</p><p><a target=\"__blank\" name=\"singular\"></a>This option is only available for system services and is not supported for services\nrunning in per-user instances of the service manager.</p>",
                "RestrictAddressFamilies": "<p>Restricts the set of socket address families accessible to the processes of this\n        unit. Takes a space-separated list of address family names to allow-list, such as\n        <code class=\"constant\">AF_UNIX</code>, <code class=\"constant\">AF_INET</code> or <code class=\"constant\">AF_INET6</code>. When\n        prefixed with <code class=\"constant\">~</code> the listed address families will be applied as deny list,\n        otherwise as allow list.  Note that this restricts access to the <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/socket.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">socket</span>(2)</span></a>\n        system call only. Sockets passed into the process by other means (for example, by using socket\n        activation with socket units, see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.socket.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.socket</span>(5)</span></a>)\n        are unaffected. Also, sockets created with <code class=\"function\">socketpair()</code> (which creates connected\n        AF_UNIX sockets only) are unaffected. Note that this option has no effect on 32-bit x86, s390, s390x,\n        mips, mips-le, ppc, ppc-le, ppc64, ppc64-le and is ignored (but works correctly on other ABIs,\n        including x86-64). Note that on systems supporting multiple ABIs (such as x86/x86-64) it is\n        recommended to turn off alternative ABIs for services, so that they cannot be used to circumvent the\n        restrictions of this option. Specifically, it is recommended to combine this option with\n        <code class=\"varname\">SystemCallArchitectures=native</code> or similar. If running in user mode, or in system\n        mode, but without the <code class=\"constant\">CAP_SYS_ADMIN</code> capability (e.g. setting\n        <code class=\"varname\">User=nobody</code>), <code class=\"varname\">NoNewPrivileges=yes</code> is implied. By default, no\n        restrictions apply, all address families are accessible to processes. If assigned the empty string,\n        any previous address family restriction changes are undone. This setting does not affect commands\n        prefixed with \"<code class=\"literal\">+</code>\".</p><p>Use this option to limit exposure of processes to remote access, in particular via exotic and sensitive\n        network protocols, such as <code class=\"constant\">AF_PACKET</code>. Note that in most cases, the local\n        <code class=\"constant\">AF_UNIX</code> address family should be included in the configured allow list as it is frequently\n        used for local communication, including for\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/syslog.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">syslog</span>(2)</span></a>\n        logging.</p>",
                "RestrictNamespaces": "<p>Restricts access to Linux namespace functionality for the processes of this unit. For details\n        about Linux namespaces, see <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/namespaces.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">namespaces</span>(7)</span></a>. Either\n        takes a boolean argument, or a space-separated list of namespace type identifiers. If false (the default), no\n        restrictions on namespace creation and switching are made. If true, access to any kind of namespacing is\n        prohibited. Otherwise, a space-separated list of namespace type identifiers must be specified, consisting of\n        any combination of: <code class=\"constant\">cgroup</code>, <code class=\"constant\">ipc</code>, <code class=\"constant\">net</code>,\n        <code class=\"constant\">mnt</code>, <code class=\"constant\">pid</code>, <code class=\"constant\">user</code> and <code class=\"constant\">uts</code>. Any\n        namespace type listed is made accessible to the unit's processes, access to namespace types not listed is\n        prohibited (allow-listing). By prepending the list with a single tilde character (\"<code class=\"literal\">~</code>\") the\n        effect may be inverted: only the listed namespace types will be made inaccessible, all unlisted ones are\n        permitted (deny-listing). If the empty string is assigned, the default namespace restrictions are applied,\n        which is equivalent to false. This option may appear more than once, in which case the namespace types are\n        merged by <code class=\"constant\">OR</code>, or by <code class=\"constant\">AND</code> if the lines are prefixed with\n        \"<code class=\"literal\">~</code>\" (see examples below). Internally, this setting limits access to the\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/unshare.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">unshare</span>(2)</span></a>,\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/clone.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">clone</span>(2)</span></a> and\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/setns.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">setns</span>(2)</span></a> system calls, taking\n        the specified flags parameters into account. Note that — if this option is used — in addition to restricting\n        creation and switching of the specified types of namespaces (or all of them, if true) access to the\n        <code class=\"function\">setns()</code> system call with a zero flags parameter is prohibited.  This setting is only\n        supported on x86, x86-64, mips, mips-le, mips64, mips64-le, mips64-n32, mips64-le-n32, ppc64, ppc64-le, s390\n        and s390x, and enforces no restrictions on other architectures. If running in user mode, or in system mode, but\n        without the <code class=\"constant\">CAP_SYS_ADMIN</code> capability (e.g. setting <code class=\"varname\">User=</code>),\n        <code class=\"varname\">NoNewPrivileges=yes</code> is implied.</p><p>Example: if a unit has the following,\n        </p><pre class=\"programlisting\">RestrictNamespaces=cgroup ipc\nRestrictNamespaces=cgroup net</pre><p>\n        then <code class=\"constant\">cgroup</code>, <code class=\"constant\">ipc</code>, and <code class=\"constant\">net</code> are set.\n        If the second line is prefixed with \"<code class=\"literal\">~</code>\", e.g.,\n        </p><pre class=\"programlisting\">RestrictNamespaces=cgroup ipc\nRestrictNamespaces=~cgroup net</pre><p>\n        then, only <code class=\"constant\">ipc</code> is set.</p>",
                "LockPersonality": "<p>Takes a boolean argument. If set, locks down the <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/personality.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">personality</span>(2)</span></a> system\n        call so that the kernel execution domain may not be changed from the default or the personality selected with\n        <code class=\"varname\">Personality=</code> directive. This may be useful to improve security, because odd personality\n        emulations may be poorly tested and source of vulnerabilities. If running in user mode, or in system mode, but\n        without the <code class=\"constant\">CAP_SYS_ADMIN</code> capability (e.g. setting <code class=\"varname\">User=</code>),\n        <code class=\"varname\">NoNewPrivileges=yes</code> is implied.</p>",
                "MemoryDenyWriteExecute": "<p>Takes a boolean argument. If set, attempts to create memory mappings that are writable and\n        executable at the same time, or to change existing memory mappings to become executable, or mapping shared\n        memory segments as executable are prohibited.  Specifically, a system call filter is added that rejects\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/mmap.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">mmap</span>(2)</span></a> system calls with both\n        <code class=\"constant\">PROT_EXEC</code> and <code class=\"constant\">PROT_WRITE</code> set,\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/mprotect.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">mprotect</span>(2)</span></a> or\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/pkey_mprotect.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">pkey_mprotect</span>(2)</span></a> system calls\n        with <code class=\"constant\">PROT_EXEC</code> set and\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/shmat.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">shmat</span>(2)</span></a> system calls with\n        <code class=\"constant\">SHM_EXEC</code> set. Note that this option is incompatible with programs and libraries that\n        generate program code dynamically at runtime, including JIT execution engines, executable stacks, and code\n        \"trampoline\" feature of various C compilers. This option improves service security, as it makes harder for\n        software exploits to change running code dynamically. However, the protection can be circumvented, if\n        the service can write to a filesystem, which is not mounted with <code class=\"constant\">noexec</code> (such as\n        <code class=\"filename\">/dev/shm</code>), or it can use <code class=\"function\">memfd_create()</code>.  This can be\n        prevented by making such file systems inaccessible to the service\n        (e.g. <code class=\"varname\">InaccessiblePaths=/dev/shm</code>) and installing further system call filters\n        (<code class=\"varname\">SystemCallFilter=~memfd_create</code>). Note that this feature is fully available on\n        x86-64, and partially on x86. Specifically, the <code class=\"function\">shmat()</code> protection is not\n        available on x86. Note that on systems supporting multiple ABIs (such as x86/x86-64) it is\n        recommended to turn off alternative ABIs for services, so that they cannot be used to circumvent the\n        restrictions of this option. Specifically, it is recommended to combine this option with\n        <code class=\"varname\">SystemCallArchitectures=native</code> or similar. If running in user mode, or in system\n        mode, but without the <code class=\"constant\">CAP_SYS_ADMIN</code> capability (e.g. setting\n        <code class=\"varname\">User=</code>), <code class=\"varname\">NoNewPrivileges=yes</code> is implied.</p>",
                "RestrictRealtime": "<p>Takes a boolean argument. If set, any attempts to enable realtime scheduling in a process of\n        the unit are refused. This restricts access to realtime task scheduling policies such as\n        <code class=\"constant\">SCHED_FIFO</code>, <code class=\"constant\">SCHED_RR</code> or <code class=\"constant\">SCHED_DEADLINE</code>. See\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/sched.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">sched</span>(7)</span></a>\n        for details about these scheduling policies. If running in user mode, or in system mode, but without the\n        <code class=\"constant\">CAP_SYS_ADMIN</code> capability (e.g. setting <code class=\"varname\">User=</code>),\n        <code class=\"varname\">NoNewPrivileges=yes</code> is implied. Realtime scheduling policies may be used to monopolize CPU\n        time for longer periods of time, and may hence be used to lock up or otherwise trigger Denial-of-Service\n        situations on the system. It is hence recommended to restrict access to realtime scheduling to the few programs\n        that actually require them. Defaults to off.</p>",
                "RestrictSUIDSGID": "<p>Takes a boolean argument. If set, any attempts to set the set-user-ID (SUID) or\n        set-group-ID (SGID) bits on files or directories will be denied (for details on these bits see\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/inode.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">inode</span>(7)</span></a>). If\n        running in user mode, or in system mode, but without the <code class=\"constant\">CAP_SYS_ADMIN</code>\n        capability (e.g. setting <code class=\"varname\">User=</code>), <code class=\"varname\">NoNewPrivileges=yes</code> is\n        implied. As the SUID/SGID bits are mechanisms to elevate privileges, and allows users to acquire the\n        identity of other users, it is recommended to restrict creation of SUID/SGID files to the few\n        programs that actually require them. Note that this restricts marking of any type of file system\n        object with these bits, including both regular files and directories (where the SGID is a different\n        meaning than for files, see documentation). This option is implied if <code class=\"varname\">DynamicUser=</code>\n        is enabled. Defaults to off.</p>",
                "RemoveIPC": "<p>Takes a boolean parameter. If set, all System V and POSIX IPC objects owned by the user and\n        group the processes of this unit are run as are removed when the unit is stopped. This setting only has an\n        effect if at least one of <code class=\"varname\">User=</code>, <code class=\"varname\">Group=</code> and\n        <code class=\"varname\">DynamicUser=</code> are used. It has no effect on IPC objects owned by the root user. Specifically,\n        this removes System V semaphores, as well as System V and POSIX shared memory segments and message queues. If\n        multiple units use the same user or group the IPC objects are removed when the last of these units is\n        stopped. This setting is implied if <code class=\"varname\">DynamicUser=</code> is set.</p><p><a target=\"__blank\" name=\"singular\"></a>This option is only available for system services and is not supported for services\nrunning in per-user instances of the service manager.</p>",
                "PrivateMounts": "<p>Takes a boolean parameter. If set, the processes of this unit will be run in their own private\n        file system (mount) namespace with all mount propagation from the processes towards the host's main file system\n        namespace turned off. This means any file system mount points established or removed by the unit's processes\n        will be private to them and not be visible to the host. However, file system mount points established or\n        removed on the host will be propagated to the unit's processes. See <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/mount_namespaces.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">mount_namespaces</span>(7)</span></a> for\n        details on file system namespaces. Defaults to off.</p><p>When turned on, this executes three operations for each invoked process: a new\n        <code class=\"constant\">CLONE_NEWNS</code> namespace is created, after which all existing mounts are remounted to\n        <code class=\"constant\">MS_SLAVE</code> to disable propagation from the unit's processes to the host (but leaving\n        propagation in the opposite direction in effect). Finally, the mounts are remounted again to the propagation\n        mode configured with <code class=\"varname\">MountFlags=</code>, see below.</p><p>File system namespaces are set up individually for each process forked off by the service manager. Mounts\n        established in the namespace of the process created by <code class=\"varname\">ExecStartPre=</code> will hence be cleaned\n        up automatically as soon as that process exits and will not be available to subsequent processes forked off for\n        <code class=\"varname\">ExecStart=</code> (and similar applies to the various other commands configured for\n        units). Similarly, <code class=\"varname\">JoinsNamespaceOf=</code> does not permit sharing kernel mount namespaces between\n        units, it only enables sharing of the <code class=\"filename\">/tmp/</code> and <code class=\"filename\">/var/tmp/</code>\n        directories.</p><p>Other file system namespace unit settings — <code class=\"varname\">PrivateMounts=</code>,\n        <code class=\"varname\">PrivateTmp=</code>, <code class=\"varname\">PrivateDevices=</code>, <code class=\"varname\">ProtectSystem=</code>,\n        <code class=\"varname\">ProtectHome=</code>, <code class=\"varname\">ReadOnlyPaths=</code>, <code class=\"varname\">InaccessiblePaths=</code>,\n        <code class=\"varname\">ReadWritePaths=</code>, … — also enable file system namespacing in a fashion equivalent to this\n        option. Hence it is primarily useful to explicitly request this behaviour if none of the other settings are\n        used.</p><p><a target=\"__blank\" name=\"singular\"></a>This option is only available for system services and is not supported for services\nrunning in per-user instances of the service manager.</p>",
                "MountFlags": "<p>Takes a mount propagation setting: <code class=\"option\">shared</code>, <code class=\"option\">slave</code> or\n        <code class=\"option\">private</code>, which controls whether file system mount points in the file system namespaces set up\n        for this unit's processes will receive or propagate mounts and unmounts from other file system namespaces. See\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/mount.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">mount</span>(2)</span></a>\n        for details on mount propagation, and the three propagation flags in particular.</p><p>This setting only controls the <span class=\"emphasis\"><em>final</em></span> propagation setting in effect on all mount\n        points of the file system namespace created for each process of this unit. Other file system namespacing unit\n        settings (see the discussion in <code class=\"varname\">PrivateMounts=</code> above) will implicitly disable mount and\n        unmount propagation from the unit's processes towards the host by changing the propagation setting of all mount\n        points in the unit's file system namespace to <code class=\"option\">slave</code> first. Setting this option to\n        <code class=\"option\">shared</code> does not reestablish propagation in that case.</p><p>If not set – but file system namespaces are enabled through another file system namespace unit setting –\n        <code class=\"option\">shared</code> mount propagation is used, but — as mentioned — as <code class=\"option\">slave</code> is applied\n        first, propagation from the unit's processes to the host is still turned off.</p><p>It is not recommended to use <code class=\"option\">private</code> mount propagation for units, as this means\n        temporary mounts (such as removable media) of the host will stay mounted and thus indefinitely busy in forked\n        off processes, as unmount propagation events won't be received by the file system namespace of the unit.</p><p>Usually, it is best to leave this setting unmodified, and use higher level file system namespacing\n        options instead, in particular <code class=\"varname\">PrivateMounts=</code>, see above.</p><p><a target=\"__blank\" name=\"singular\"></a>This option is only available for system services and is not supported for services\nrunning in per-user instances of the service manager.</p>",
                "SystemCallFilter": "<p>Takes a space-separated list of system call names. If this setting is used, all\n        system calls executed by the unit processes except for the listed ones will result in immediate\n        process termination with the <code class=\"constant\">SIGSYS</code> signal (allow-listing). (See\n        <code class=\"varname\">SystemCallErrorNumber=</code> below for changing the default action). If the first\n        character of the list is \"<code class=\"literal\">~</code>\", the effect is inverted: only the listed system calls\n        will result in immediate process termination (deny-listing). Deny-listed system calls and system call\n        groups may optionally be suffixed with a colon (\"<code class=\"literal\">:</code>\") and \"<code class=\"literal\">errno</code>\"\n        error number (between 0 and 4095) or errno name such as <code class=\"constant\">EPERM</code>,\n        <code class=\"constant\">EACCES</code> or <code class=\"constant\">EUCLEAN</code> (see <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man3/errno.3.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">errno</span>(3)</span></a> for a\n        full list). This value will be returned when a deny-listed system call is triggered, instead of\n        terminating the processes immediately.  This value takes precedence over the one given in\n        <code class=\"varname\">SystemCallErrorNumber=</code>, see below.  If running in user mode, or in system mode,\n        but without the <code class=\"constant\">CAP_SYS_ADMIN</code> capability (e.g. setting\n        <code class=\"varname\">User=nobody</code>), <code class=\"varname\">NoNewPrivileges=yes</code> is implied. This feature\n        makes use of the Secure Computing Mode 2 interfaces of the kernel ('seccomp filtering') and is useful\n        for enforcing a minimal sandboxing environment. Note that the <code class=\"function\">execve</code>,\n        <code class=\"function\">exit</code>, <code class=\"function\">exit_group</code>, <code class=\"function\">getrlimit</code>,\n        <code class=\"function\">rt_sigreturn</code>, <code class=\"function\">sigreturn</code> system calls and the system calls\n        for querying time and sleeping are implicitly allow-listed and do not need to be listed\n        explicitly. This option may be specified more than once, in which case the filter masks are\n        merged. If the empty string is assigned, the filter is reset, all prior assignments will have no\n        effect. This does not affect commands prefixed with \"<code class=\"literal\">+</code>\".</p><p>Note that on systems supporting multiple ABIs (such as x86/x86-64) it is recommended to turn off\n        alternative ABIs for services, so that they cannot be used to circumvent the restrictions of this\n        option. Specifically, it is recommended to combine this option with\n        <code class=\"varname\">SystemCallArchitectures=native</code> or similar.</p><p>Note that strict system call filters may impact execution and error handling code paths of the service\n        invocation. Specifically, access to the <code class=\"function\">execve</code> system call is required for the execution\n        of the service binary — if it is blocked service invocation will necessarily fail. Also, if execution of the\n        service binary fails for some reason (for example: missing service executable), the error handling logic might\n        require access to an additional set of system calls in order to process and log this failure correctly. It\n        might be necessary to temporarily disable system call filters in order to simplify debugging of such\n        failures.</p><p>If you specify both types of this option (i.e.  allow-listing and deny-listing), the first\n        encountered will take precedence and will dictate the default action (termination or approval of a\n        system call). Then the next occurrences of this option will add or delete the listed system calls\n        from the set of the filtered system calls, depending of its type and the default action. (For\n        example, if you have started with an allow list rule for <code class=\"function\">read</code> and\n        <code class=\"function\">write</code>, and right after it add a deny list rule for <code class=\"function\">write</code>,\n        then <code class=\"function\">write</code> will be removed from the set.)</p><p>As the number of possible system calls is large, predefined sets of system calls are provided.  A set\n        starts with \"<code class=\"literal\">@</code>\" character, followed by name of the set.\n\n        </p><div class=\"table\"><a target=\"__blank\" name=\"id-1.15.2.1.2.5.2\"></a><p class=\"title\"><b>Table&nbsp;3.&nbsp;Currently predefined system call sets</b></p><div class=\"table-contents\"><table class=\"table\" summary=\"Currently predefined system call sets\" border=\"1\"><colgroup><col class=\"set\"><col class=\"description\"></colgroup><thead><tr><th>Set</th><th>Description</th></tr></thead><tbody><tr><td>@aio</td><td>Asynchronous I/O (<a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/io_setup.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">io_setup</span>(2)</span></a>, <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/io_submit.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">io_submit</span>(2)</span></a>, and related calls)</td></tr><tr><td>@basic-io</td><td>System calls for basic I/O: reading, writing, seeking, file descriptor duplication and closing (<a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/read.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">read</span>(2)</span></a>, <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/write.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">write</span>(2)</span></a>, and related calls)</td></tr><tr><td>@chown</td><td>Changing file ownership (<a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/chown.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">chown</span>(2)</span></a>, <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/fchownat.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">fchownat</span>(2)</span></a>, and related calls)</td></tr><tr><td>@clock</td><td>System calls for changing the system clock (<a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/adjtimex.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">adjtimex</span>(2)</span></a>, <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/settimeofday.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">settimeofday</span>(2)</span></a>, and related calls)</td></tr><tr><td>@cpu-emulation</td><td>System calls for CPU emulation functionality (<a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/vm86.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">vm86</span>(2)</span></a> and related calls)</td></tr><tr><td>@debug</td><td>Debugging, performance monitoring and tracing functionality (<a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/ptrace.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">ptrace</span>(2)</span></a>, <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/perf_event_open.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">perf_event_open</span>(2)</span></a> and related calls)</td></tr><tr><td>@file-system</td><td>File system operations: opening, creating files and directories for read and write, renaming and removing them, reading file properties, or creating hard and symbolic links</td></tr><tr><td>@io-event</td><td>Event loop system calls (<a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/poll.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">poll</span>(2)</span></a>, <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/select.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">select</span>(2)</span></a>, <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/epoll.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">epoll</span>(7)</span></a>, <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/eventfd.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">eventfd</span>(2)</span></a> and related calls)</td></tr><tr><td>@ipc</td><td>Pipes, SysV IPC, POSIX Message Queues and other IPC (<a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/mq_overview.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">mq_overview</span>(7)</span></a>, <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/svipc.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">svipc</span>(7)</span></a>)</td></tr><tr><td>@keyring</td><td>Kernel keyring access (<a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/keyctl.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">keyctl</span>(2)</span></a> and related calls)</td></tr><tr><td>@memlock</td><td>Locking of memory in RAM (<a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/mlock.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">mlock</span>(2)</span></a>, <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/mlockall.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">mlockall</span>(2)</span></a> and related calls)</td></tr><tr><td>@module</td><td>Loading and unloading of kernel modules (<a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/init_module.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">init_module</span>(2)</span></a>, <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/delete_module.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">delete_module</span>(2)</span></a> and related calls)</td></tr><tr><td>@mount</td><td>Mounting and unmounting of file systems (<a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/mount.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">mount</span>(2)</span></a>, <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/chroot.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">chroot</span>(2)</span></a>, and related calls)</td></tr><tr><td>@network-io</td><td>Socket I/O (including local AF_UNIX): <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/socket.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">socket</span>(7)</span></a>, <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/unix.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">unix</span>(7)</span></a></td></tr><tr><td>@obsolete</td><td>Unusual, obsolete or unimplemented (<a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/create_module.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">create_module</span>(2)</span></a>, <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/gtty.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">gtty</span>(2)</span></a>, …)</td></tr><tr><td>@privileged</td><td>All system calls which need super-user capabilities (<a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/capabilities.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">capabilities</span>(7)</span></a>)</td></tr><tr><td>@process</td><td>Process control, execution, namespaceing operations (<a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/clone.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">clone</span>(2)</span></a>, <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/kill.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">kill</span>(2)</span></a>, <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/namespaces.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">namespaces</span>(7)</span></a>, …)</td></tr><tr><td>@raw-io</td><td>Raw I/O port access (<a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/ioperm.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">ioperm</span>(2)</span></a>, <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/iopl.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">iopl</span>(2)</span></a>, <code class=\"function\">pciconfig_read()</code>, …)</td></tr><tr><td>@reboot</td><td>System calls for rebooting and reboot preparation (<a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/reboot.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">reboot</span>(2)</span></a>, <code class=\"function\">kexec()</code>, …)</td></tr><tr><td>@resources</td><td>System calls for changing resource limits, memory and scheduling parameters (<a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/setrlimit.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">setrlimit</span>(2)</span></a>, <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/setpriority.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">setpriority</span>(2)</span></a>, …)</td></tr><tr><td>@setuid</td><td>System calls for changing user ID and group ID credentials, (<a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/setuid.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">setuid</span>(2)</span></a>, <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/setgid.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">setgid</span>(2)</span></a>, <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/setresuid.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">setresuid</span>(2)</span></a>, …)</td></tr><tr><td>@signal</td><td>System calls for manipulating and handling process signals (<a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/signal.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">signal</span>(2)</span></a>, <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/sigprocmask.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">sigprocmask</span>(2)</span></a>, …)</td></tr><tr><td>@swap</td><td>System calls for enabling/disabling swap devices (<a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/swapon.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">swapon</span>(2)</span></a>, <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/swapoff.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">swapoff</span>(2)</span></a>)</td></tr><tr><td>@sync</td><td>Synchronizing files and memory to disk (<a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/fsync.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">fsync</span>(2)</span></a>, <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/msync.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">msync</span>(2)</span></a>, and related calls)</td></tr><tr><td>@system-service</td><td>A reasonable set of system calls used by common system services, excluding any special purpose calls. This is the recommended starting point for allow-listing system calls for system services, as it contains what is typically needed by system services, but excludes overly specific interfaces. For example, the following APIs are excluded: \"<code class=\"literal\">@clock</code>\", \"<code class=\"literal\">@mount</code>\", \"<code class=\"literal\">@swap</code>\", \"<code class=\"literal\">@reboot</code>\".</td></tr><tr><td>@timer</td><td>System calls for scheduling operations by time (<a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/alarm.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">alarm</span>(2)</span></a>, <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/timer_create.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">timer_create</span>(2)</span></a>, …)</td></tr></tbody></table></div></div><p><br class=\"table-break\">\n\n        Note, that as new system calls are added to the kernel, additional system calls might be added to the groups\n        above. Contents of the sets may also change between systemd versions. In addition, the list of system calls\n        depends on the kernel version and architecture for which systemd was compiled. Use\n        <span class=\"command\"><strong>systemd-analyze&nbsp;syscall-filter</strong></span> to list the actual list of system calls in each\n        filter.</p><p>Generally, allow-listing system calls (rather than deny-listing) is the safer mode of\n        operation. It is recommended to enforce system call allow lists for all long-running system\n        services. Specifically, the following lines are a relatively safe basic choice for the majority of\n        system services:</p><pre class=\"programlisting\">[Service]\nSystemCallFilter=@system-service\nSystemCallErrorNumber=EPERM</pre><p>Note that various kernel system calls are defined redundantly: there are multiple system calls\n        for executing the same operation. For example, the <code class=\"function\">pidfd_send_signal()</code> system\n        call may be used to execute operations similar to what can be done with the older\n        <code class=\"function\">kill()</code> system call, hence blocking the latter without the former only provides\n        weak protection. Since new system calls are added regularly to the kernel as development progresses,\n        keeping system call deny lists comprehensive requires constant work. It is thus recommended to use\n        allow-listing instead, which offers the benefit that new system calls are by default implicitly\n        blocked until the allow list is updated.</p><p>Also note that a number of system calls are required to be accessible for the dynamic linker to\n        work. The dynamic linker is required for running most regular programs (specifically: all dynamic ELF\n        binaries, which is how most distributions build packaged programs). This means that blocking these\n        system calls (which include <code class=\"function\">open()</code>, <code class=\"function\">openat()</code> or\n        <code class=\"function\">mmap()</code>) will make most programs typically shipped with generic distributions\n        unusable.</p><p>It is recommended to combine the file system namespacing related options with\n        <code class=\"varname\">SystemCallFilter=~@mount</code>, in order to prohibit the unit's processes to undo the\n        mappings. Specifically these are the options <code class=\"varname\">PrivateTmp=</code>,\n        <code class=\"varname\">PrivateDevices=</code>, <code class=\"varname\">ProtectSystem=</code>, <code class=\"varname\">ProtectHome=</code>,\n        <code class=\"varname\">ProtectKernelTunables=</code>, <code class=\"varname\">ProtectControlGroups=</code>,\n        <code class=\"varname\">ProtectKernelLogs=</code>, <code class=\"varname\">ProtectClock=</code>, <code class=\"varname\">ReadOnlyPaths=</code>,\n        <code class=\"varname\">InaccessiblePaths=</code> and <code class=\"varname\">ReadWritePaths=</code>.</p>",
                "SystemCallErrorNumber": "<p>Takes an \"<code class=\"literal\">errno</code>\" error number (between 1 and 4095) or errno name\n        such as <code class=\"constant\">EPERM</code>, <code class=\"constant\">EACCES</code> or <code class=\"constant\">EUCLEAN</code>, to\n        return when the system call filter configured with <code class=\"varname\">SystemCallFilter=</code> is triggered,\n        instead of terminating the process immediately. See <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man3/errno.3.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">errno</span>(3)</span></a> for a\n        full list of error codes. When this setting is not used, or when the empty string is assigned, the\n        process will be terminated immediately when the filter is triggered.</p>",
                "SystemCallArchitectures": "<p>Takes a space-separated list of architecture identifiers to include in the system call\n        filter. The known architecture identifiers are the same as for <code class=\"varname\">ConditionArchitecture=</code>\n        described in <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.unit.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.unit</span>(5)</span></a>,\n        as well as <code class=\"constant\">x32</code>, <code class=\"constant\">mips64-n32</code>, <code class=\"constant\">mips64-le-n32</code>, and\n        the special identifier <code class=\"constant\">native</code>.  The special identifier <code class=\"constant\">native</code>\n        implicitly maps to the native architecture of the system (or more precisely: to the architecture the system\n        manager is compiled for). If running in user mode, or in system mode, but without the\n        <code class=\"constant\">CAP_SYS_ADMIN</code> capability (e.g. setting <code class=\"varname\">User=nobody</code>),\n        <code class=\"varname\">NoNewPrivileges=yes</code> is implied. By default, this option is set to the empty list, i.e. no\n        filtering is applied.</p><p>If this setting is used, processes of this unit will only be permitted to call native system calls, and\n        system calls of the specified architectures. For the purposes of this option, the x32 architecture is treated\n        as including x86-64 system calls. However, this setting still fulfills its purpose, as explained below, on\n        x32.</p><p>System call filtering is not equally effective on all architectures. For example, on x86\n        filtering of network socket-related calls is not possible, due to ABI limitations — a limitation that x86-64\n        does not have, however. On systems supporting multiple ABIs at the same time — such as x86/x86-64 — it is hence\n        recommended to limit the set of permitted system call architectures so that secondary ABIs may not be used to\n        circumvent the restrictions applied to the native ABI of the system. In particular, setting\n        <code class=\"varname\">SystemCallArchitectures=native</code> is a good choice for disabling non-native ABIs.</p><p>System call architectures may also be restricted system-wide via the\n        <code class=\"varname\">SystemCallArchitectures=</code> option in the global configuration. See\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd-system.conf</span>(5)</span></a> for\n        details.</p>",
                "Environment": "<p>Sets environment variables for executed processes. Takes a space-separated list of variable\n        assignments. This option may be specified more than once, in which case all listed variables will be set. If\n        the same variable is set twice, the later setting will override the earlier setting. If the empty string is\n        assigned to this option, the list of environment variables is reset, all prior assignments have no\n        effect. Variable expansion is not performed inside the strings, however, specifier expansion is possible. The $\n        character has no special meaning. If you need to assign a value containing spaces or the equals sign to a\n        variable, use double quotes (\") for the assignment.</p><p>Example:\n        </p><pre class=\"programlisting\">Environment=\"VAR1=word1 word2\" VAR2=word3 \"VAR3=$word 5 6\"</pre><p>\n        gives three variables \"<code class=\"literal\">VAR1</code>\",\n        \"<code class=\"literal\">VAR2</code>\", \"<code class=\"literal\">VAR3</code>\"\n        with the values \"<code class=\"literal\">word1 word2</code>\",\n        \"<code class=\"literal\">word3</code>\", \"<code class=\"literal\">$word 5 6</code>\".\n        </p><p>\n        See <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/environ.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">environ</span>(7)</span></a> for details\n        about environment variables.</p><p>Note that environment variables are not suitable for passing secrets (such as passwords, key material, …)\n        to service processes. Environment variables set for a unit are exposed to unprivileged clients via D-Bus IPC,\n        and generally not understood as being data that requires protection. Moreover, environment variables are\n        propagated down the process tree, including across security boundaries (such as setuid/setgid executables), and\n        hence might leak to processes that should not have access to the secret data.</p>",
                "EnvironmentFile": "<p>Similar to <code class=\"varname\">Environment=</code> but reads the environment variables from a text\n        file. The text file should contain new-line-separated variable assignments.  Empty lines, lines without an\n        \"<code class=\"literal\">=</code>\" separator, or lines starting with ; or # will be ignored, which may be used for\n        commenting. A line ending with a backslash will be concatenated with the following one, allowing multiline\n        variable definitions. The parser strips leading and trailing whitespace from the values of assignments, unless\n        you use double quotes (\").</p><p><a target=\"__blank\" class=\"ulink\" href=\"https://en.wikipedia.org/wiki/Escape_sequences_in_C#Table_of_escape_sequences\" target=\"_top\">C escapes</a>\n        are supported, but not\n        <a target=\"__blank\" class=\"ulink\" href=\"https://en.wikipedia.org/wiki/Control_character#In_ASCII\" target=\"_top\">most control characters</a>.\n        \"<code class=\"literal\">\\t</code>\" and \"<code class=\"literal\">\\n</code>\" can be used to insert tabs and newlines within\n        <code class=\"varname\">EnvironmentFile=</code>.</p><p>The argument passed should be an absolute filename or wildcard expression, optionally prefixed with\n        \"<code class=\"literal\">-</code>\", which indicates that if the file does not exist, it will not be read and no error or\n        warning message is logged. This option may be specified more than once in which case all specified files are\n        read. If the empty string is assigned to this option, the list of file to read is reset, all prior assignments\n        have no effect.</p><p>The files listed with this directive will be read shortly before the process is executed (more\n        specifically, after all processes from a previous unit state terminated.  This means you can generate these\n        files in one unit state, and read it with this option in the next.  The files are read from the file\n        system of the service manager, before any file system changes like bind mounts take place).</p><p>Settings from these files override settings made with <code class=\"varname\">Environment=</code>. If the same\n        variable is set twice from these files, the files will be read in the order they are specified and the later\n        setting will override the earlier setting.</p>",
                "PassEnvironment": "<p>Pass environment variables set for the system service manager to executed processes. Takes a\n        space-separated list of variable names. This option may be specified more than once, in which case all listed\n        variables will be passed. If the empty string is assigned to this option, the list of environment variables to\n        pass is reset, all prior assignments have no effect. Variables specified that are not set for the system\n        manager will not be passed and will be silently ignored. Note that this option is only relevant for the system\n        service manager, as system services by default do not automatically inherit any environment variables set for\n        the service manager itself. However, in case of the user service manager all environment variables are passed\n        to the executed processes anyway, hence this option is without effect for the user service manager.</p><p>Variables set for invoked processes due to this setting are subject to being overridden by those\n        configured with <code class=\"varname\">Environment=</code> or <code class=\"varname\">EnvironmentFile=</code>.</p><p><a target=\"__blank\" class=\"ulink\" href=\"https://en.wikipedia.org/wiki/Escape_sequences_in_C#Table_of_escape_sequences\" target=\"_top\">C escapes</a>\n        are supported, but not\n        <a target=\"__blank\" class=\"ulink\" href=\"https://en.wikipedia.org/wiki/Control_character#In_ASCII\" target=\"_top\">most control characters</a>.\n        \"<code class=\"literal\">\\t</code>\" and \"<code class=\"literal\">\\n</code>\" can be used to insert tabs and newlines within\n        <code class=\"varname\">EnvironmentFile=</code>.</p><p>Example:\n        </p><pre class=\"programlisting\">PassEnvironment=VAR1 VAR2 VAR3</pre><p>\n        passes three variables \"<code class=\"literal\">VAR1</code>\",\n        \"<code class=\"literal\">VAR2</code>\", \"<code class=\"literal\">VAR3</code>\"\n        with the values set for those variables in PID1.</p><p>\n        See <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/environ.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">environ</span>(7)</span></a> for details\n        about environment variables.</p>",
                "UnsetEnvironment": "<p>Explicitly unset environment variable assignments that would normally be passed from the\n        service manager to invoked processes of this unit. Takes a space-separated list of variable names or variable\n        assignments. This option may be specified more than once, in which case all listed variables/assignments will\n        be unset. If the empty string is assigned to this option, the list of environment variables/assignments to\n        unset is reset. If a variable assignment is specified (that is: a variable name, followed by\n        \"<code class=\"literal\">=</code>\", followed by its value), then any environment variable matching this precise assignment is\n        removed. If a variable name is specified (that is a variable name without any following \"<code class=\"literal\">=</code>\" or\n        value), then any assignment matching the variable name, regardless of its value is removed. Note that the\n        effect of <code class=\"varname\">UnsetEnvironment=</code> is applied as final step when the environment list passed to\n        executed processes is compiled. That means it may undo assignments from any configuration source, including\n        assignments made through <code class=\"varname\">Environment=</code> or <code class=\"varname\">EnvironmentFile=</code>, inherited from\n        the system manager's global set of environment variables, inherited via <code class=\"varname\">PassEnvironment=</code>,\n        set by the service manager itself (such as <code class=\"varname\">$NOTIFY_SOCKET</code> and such), or set by a PAM module\n        (in case <code class=\"varname\">PAMName=</code> is used).</p><p>\n        See <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/environ.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">environ</span>(7)</span></a> for details\n        about environment variables.</p>",
                "StandardInput": "<p>Controls where file descriptor 0 (STDIN) of the executed processes is connected to. Takes one\n        of <code class=\"option\">null</code>, <code class=\"option\">tty</code>, <code class=\"option\">tty-force</code>, <code class=\"option\">tty-fail</code>,\n        <code class=\"option\">data</code>, <code class=\"option\">file:<em class=\"replaceable\"><code>path</code></em></code>, <code class=\"option\">socket</code> or\n        <code class=\"option\">fd:<em class=\"replaceable\"><code>name</code></em></code>.</p><p>If <code class=\"option\">null</code> is selected, standard input will be connected to <code class=\"filename\">/dev/null</code>,\n        i.e. all read attempts by the process will result in immediate EOF.</p><p>If <code class=\"option\">tty</code> is selected, standard input is connected to a TTY (as configured by\n        <code class=\"varname\">TTYPath=</code>, see below) and the executed process becomes the controlling process of the\n        terminal. If the terminal is already being controlled by another process, the executed process waits until the\n        current controlling process releases the terminal.</p><p><code class=\"option\">tty-force</code> is similar to <code class=\"option\">tty</code>, but the executed process is forcefully and\n        immediately made the controlling process of the terminal, potentially removing previous controlling processes\n        from the terminal.</p><p><code class=\"option\">tty-fail</code> is similar to <code class=\"option\">tty</code>, but if the terminal already has a\n        controlling process start-up of the executed process fails.</p><p>The <code class=\"option\">data</code> option may be used to configure arbitrary textual or binary data to pass via\n        standard input to the executed process. The data to pass is configured via\n        <code class=\"varname\">StandardInputText=</code>/<code class=\"varname\">StandardInputData=</code> (see below). Note that the actual\n        file descriptor type passed (memory file, regular file, UNIX pipe, …) might depend on the kernel and available\n        privileges. In any case, the file descriptor is read-only, and when read returns the specified data followed by\n        EOF.</p><p>The <code class=\"option\">file:<em class=\"replaceable\"><code>path</code></em></code> option may be used to connect a specific file\n        system object to standard input. An absolute path following the \"<code class=\"literal\">:</code>\" character is expected,\n        which may refer to a regular file, a FIFO or special file. If an <code class=\"constant\">AF_UNIX</code> socket in the\n        file system is specified, a stream socket is connected to it. The latter is useful for connecting standard\n        input of processes to arbitrary system services.</p><p>The <code class=\"option\">socket</code> option is valid in socket-activated services only, and requires the relevant\n        socket unit file (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.socket.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.socket</span>(5)</span></a> for details)\n        to have <code class=\"varname\">Accept=yes</code> set, or to specify a single socket only. If this option is set, standard\n        input will be connected to the socket the service was activated from, which is primarily useful for\n        compatibility with daemons designed for use with the traditional <a target=\"__blank\" href=\"https://www.freebsd.org/cgi/man.cgi?inetd(8)\"><span class=\"citerefentry\"><span class=\"refentrytitle\">inetd</span>(8)</span></a> socket activation\n        daemon.</p><p>The <code class=\"option\">fd:<em class=\"replaceable\"><code>name</code></em></code> option connects standard input to a specific,\n        named file descriptor provided by a socket unit.  The name may be specified as part of this option, following a\n        \"<code class=\"literal\">:</code>\" character (e.g. \"<code class=\"literal\">fd:foobar</code>\").  If no name is specified, the name\n        \"<code class=\"literal\">stdin</code>\" is implied (i.e. \"<code class=\"literal\">fd</code>\" is equivalent to \"<code class=\"literal\">fd:stdin</code>\").\n        At least one socket unit defining the specified name must be provided via the <code class=\"varname\">Sockets=</code>\n        option, and the file descriptor name may differ from the name of its containing socket unit.  If multiple\n        matches are found, the first one will be used.  See <code class=\"varname\">FileDescriptorName=</code> in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.socket.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.socket</span>(5)</span></a> for more\n        details about named file descriptors and their ordering.</p><p>This setting defaults to <code class=\"option\">null</code>.</p>",
                "StandardOutput": "<p>Controls where file descriptor 1 (stdout) of the executed processes is connected\n        to. Takes one of <code class=\"option\">inherit</code>, <code class=\"option\">null</code>, <code class=\"option\">tty</code>,\n        <code class=\"option\">journal</code>, <code class=\"option\">kmsg</code>, <code class=\"option\">journal+console</code>,\n        <code class=\"option\">kmsg+console</code>, <code class=\"option\">file:<em class=\"replaceable\"><code>path</code></em></code>,\n        <code class=\"option\">append:<em class=\"replaceable\"><code>path</code></em></code>, <code class=\"option\">socket</code> or\n        <code class=\"option\">fd:<em class=\"replaceable\"><code>name</code></em></code>.</p><p><code class=\"option\">inherit</code> duplicates the file descriptor of standard input for standard output.</p><p><code class=\"option\">null</code> connects standard output to <code class=\"filename\">/dev/null</code>, i.e. everything written\n        to it will be lost.</p><p><code class=\"option\">tty</code> connects standard output to a tty (as configured via <code class=\"varname\">TTYPath=</code>,\n        see below). If the TTY is used for output only, the executed process will not become the controlling process of\n        the terminal, and will not fail or wait for other processes to release the terminal.</p><p><code class=\"option\">journal</code> connects standard output with the journal, which is accessible via\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/journalctl.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">journalctl</span>(1)</span></a>. Note\n        that everything that is written to kmsg (see below) is implicitly stored in the journal as well, the\n        specific option listed below is hence a superset of this one. (Also note that any external,\n        additional syslog daemons receive their log data from the journal, too, hence this is the option to\n        use when logging shall be processed with such a daemon.)</p><p><code class=\"option\">kmsg</code> connects standard output with the kernel log buffer which is accessible via\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man1/dmesg.1.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">dmesg</span>(1)</span></a>,\n        in addition to the journal. The journal daemon might be configured to send all logs to kmsg anyway, in which\n        case this option is no different from <code class=\"option\">journal</code>.</p><p><code class=\"option\">journal+console</code> and <code class=\"option\">kmsg+console</code> work in a similar way as the\n        two options above but copy the output to the system console as well.</p><p>The <code class=\"option\">file:<em class=\"replaceable\"><code>path</code></em></code> option may be used to connect a specific file\n        system object to standard output. The semantics are similar to the same option of\n        <code class=\"varname\">StandardInput=</code>, see above. If <em class=\"replaceable\"><code>path</code></em> refers to a regular file\n        on the filesystem, it is opened (created if it doesn't exist yet) for writing at the beginning of the file,\n        but without truncating it.\n        If standard input and output are directed to the same file path, it is opened only once, for reading as well\n        as writing and duplicated. This is particularly useful when the specified path refers to an\n        <code class=\"constant\">AF_UNIX</code> socket in the file system, as in that case only a\n        single stream connection is created for both input and output.</p><p><code class=\"option\">append:<em class=\"replaceable\"><code>path</code></em></code> is similar to\n        <code class=\"option\">file:<em class=\"replaceable\"><code>path</code></em></code> above, but it opens the file in append mode.\n        </p><p><code class=\"option\">socket</code> connects standard output to a socket acquired via socket activation. The\n        semantics are similar to the same option of <code class=\"varname\">StandardInput=</code>, see above.</p><p>The <code class=\"option\">fd:<em class=\"replaceable\"><code>name</code></em></code> option connects standard output to a specific,\n        named file descriptor provided by a socket unit.  A name may be specified as part of this option, following a\n        \"<code class=\"literal\">:</code>\" character (e.g. \"<code class=\"literal\">fd:foobar</code>\").  If no name is specified, the name\n        \"<code class=\"literal\">stdout</code>\" is implied (i.e. \"<code class=\"literal\">fd</code>\" is equivalent to\n        \"<code class=\"literal\">fd:stdout</code>\").  At least one socket unit defining the specified name must be provided via the\n        <code class=\"varname\">Sockets=</code> option, and the file descriptor name may differ from the name of its containing\n        socket unit.  If multiple matches are found, the first one will be used.  See\n        <code class=\"varname\">FileDescriptorName=</code> in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.socket.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.socket</span>(5)</span></a> for more\n        details about named descriptors and their ordering.</p><p>If the standard output (or error output, see below) of a unit is connected to the journal or\n        the kernel log buffer, the unit will implicitly gain a dependency of type <code class=\"varname\">After=</code>\n        on <code class=\"filename\">systemd-journald.socket</code> (also see the \"Implicit Dependencies\" section\n        above). Also note that in this case stdout (or stderr, see below) will be an\n        <code class=\"constant\">AF_UNIX</code> stream socket, and not a pipe or FIFO that can be re-opened. This means\n        when executing shell scripts the construct <span class=\"command\"><strong>echo \"hello\" &gt; /dev/stderr</strong></span> for\n        writing text to stderr will not work. To mitigate this use the construct <span class=\"command\"><strong>echo \"hello\"\n        &gt;&amp;2</strong></span> instead, which is mostly equivalent and avoids this pitfall.</p><p>This setting defaults to the value set with <code class=\"varname\">DefaultStandardOutput=</code> in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd-system.conf</span>(5)</span></a>, which\n        defaults to <code class=\"option\">journal</code>. Note that setting this parameter might result in additional dependencies\n        to be added to the unit (see above).</p>",
                "StandardError": "<p>Controls where file descriptor 2 (stderr) of the executed processes is connected to. The\n        available options are identical to those of <code class=\"varname\">StandardOutput=</code>, with some exceptions: if set to\n        <code class=\"option\">inherit</code> the file descriptor used for standard output is duplicated for standard error, while\n        <code class=\"option\">fd:<em class=\"replaceable\"><code>name</code></em></code> will use a default file descriptor name of\n        \"<code class=\"literal\">stderr</code>\".</p><p>This setting defaults to the value set with <code class=\"varname\">DefaultStandardError=</code> in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd-system.conf.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd-system.conf</span>(5)</span></a>, which\n        defaults to <code class=\"option\">inherit</code>. Note that setting this parameter might result in additional dependencies\n        to be added to the unit (see above).</p>",
                "StandardInputText": "<p>Configures arbitrary textual or binary data to pass via file descriptor 0 (STDIN) to the\n        executed processes. These settings have no effect unless <code class=\"varname\">StandardInput=</code> is set to\n        <code class=\"option\">data</code>. Use this option to embed process input data directly in the unit file.</p><p><code class=\"varname\">StandardInputText=</code> accepts arbitrary textual data. C-style escapes for special\n        characters as well as the usual \"<code class=\"literal\">%</code>\"-specifiers are resolved. Each time this setting is used\n        the specified text is appended to the per-unit data buffer, followed by a newline character (thus every use\n        appends a new line to the end of the buffer). Note that leading and trailing whitespace of lines configured\n        with this option is removed. If an empty line is specified the buffer is cleared (hence, in order to insert an\n        empty line, add an additional \"<code class=\"literal\">\\n</code>\" to the end or beginning of a line).</p><p><code class=\"varname\">StandardInputData=</code> accepts arbitrary binary data, encoded in <a target=\"__blank\" class=\"ulink\" href=\"https://tools.ietf.org/html/rfc2045#section-6.8\" target=\"_top\">Base64</a>. No escape sequences or specifiers are\n        resolved. Any whitespace in the encoded version is ignored during decoding.</p><p>Note that <code class=\"varname\">StandardInputText=</code> and <code class=\"varname\">StandardInputData=</code> operate on the\n        same data buffer, and may be mixed in order to configure both binary and textual data for the same input\n        stream. The textual or binary data is joined strictly in the order the settings appear in the unit\n        file. Assigning an empty string to either will reset the data buffer.</p><p>Please keep in mind that in order to maintain readability long unit file settings may be split into\n        multiple lines, by suffixing each line (except for the last) with a \"<code class=\"literal\">\\</code>\" character (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.unit.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.unit</span>(5)</span></a> for\n        details). This is particularly useful for large data configured with these two options. Example:</p><pre class=\"programlisting\">…\nStandardInput=data\nStandardInputData=SWNrIHNpdHplIGRhIHVuJyBlc3NlIEtsb3BzLAp1ZmYgZWVtYWwga2xvcHAncy4KSWNrIGtpZWtl \\\n                  LCBzdGF1bmUsIHd1bmRyZSBtaXIsCnVmZiBlZW1hbCBqZWh0IHNlIHVmZiBkaWUgVMO8ci4KTmFu \\\n                  dSwgZGVuayBpY2ssIGljayBkZW5rIG5hbnUhCkpldHogaXNzZSB1ZmYsIGVyc2NodCB3YXIgc2Ug \\\n                  enUhCkljayBqZWhlIHJhdXMgdW5kIGJsaWNrZSDigJQKdW5kIHdlciBzdGVodCBkcmF1w59lbj8g \\\n                  SWNrZSEK\n…</pre>",
                "StandardInputData": "<p>Configures arbitrary textual or binary data to pass via file descriptor 0 (STDIN) to the\n        executed processes. These settings have no effect unless <code class=\"varname\">StandardInput=</code> is set to\n        <code class=\"option\">data</code>. Use this option to embed process input data directly in the unit file.</p><p><code class=\"varname\">StandardInputText=</code> accepts arbitrary textual data. C-style escapes for special\n        characters as well as the usual \"<code class=\"literal\">%</code>\"-specifiers are resolved. Each time this setting is used\n        the specified text is appended to the per-unit data buffer, followed by a newline character (thus every use\n        appends a new line to the end of the buffer). Note that leading and trailing whitespace of lines configured\n        with this option is removed. If an empty line is specified the buffer is cleared (hence, in order to insert an\n        empty line, add an additional \"<code class=\"literal\">\\n</code>\" to the end or beginning of a line).</p><p><code class=\"varname\">StandardInputData=</code> accepts arbitrary binary data, encoded in <a target=\"__blank\" class=\"ulink\" href=\"https://tools.ietf.org/html/rfc2045#section-6.8\" target=\"_top\">Base64</a>. No escape sequences or specifiers are\n        resolved. Any whitespace in the encoded version is ignored during decoding.</p><p>Note that <code class=\"varname\">StandardInputText=</code> and <code class=\"varname\">StandardInputData=</code> operate on the\n        same data buffer, and may be mixed in order to configure both binary and textual data for the same input\n        stream. The textual or binary data is joined strictly in the order the settings appear in the unit\n        file. Assigning an empty string to either will reset the data buffer.</p><p>Please keep in mind that in order to maintain readability long unit file settings may be split into\n        multiple lines, by suffixing each line (except for the last) with a \"<code class=\"literal\">\\</code>\" character (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.unit.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.unit</span>(5)</span></a> for\n        details). This is particularly useful for large data configured with these two options. Example:</p><pre class=\"programlisting\">…\nStandardInput=data\nStandardInputData=SWNrIHNpdHplIGRhIHVuJyBlc3NlIEtsb3BzLAp1ZmYgZWVtYWwga2xvcHAncy4KSWNrIGtpZWtl \\\n                  LCBzdGF1bmUsIHd1bmRyZSBtaXIsCnVmZiBlZW1hbCBqZWh0IHNlIHVmZiBkaWUgVMO8ci4KTmFu \\\n                  dSwgZGVuayBpY2ssIGljayBkZW5rIG5hbnUhCkpldHogaXNzZSB1ZmYsIGVyc2NodCB3YXIgc2Ug \\\n                  enUhCkljayBqZWhlIHJhdXMgdW5kIGJsaWNrZSDigJQKdW5kIHdlciBzdGVodCBkcmF1w59lbj8g \\\n                  SWNrZSEK\n…</pre>",
                "LogLevelMax": "<p>Configures filtering by log level of log messages generated by this unit. Takes a\n        <span class=\"command\"><strong>syslog</strong></span> log level, one of <code class=\"option\">emerg</code> (lowest log level, only highest priority\n        messages), <code class=\"option\">alert</code>, <code class=\"option\">crit</code>, <code class=\"option\">err</code>, <code class=\"option\">warning</code>,\n        <code class=\"option\">notice</code>, <code class=\"option\">info</code>, <code class=\"option\">debug</code> (highest log level, also lowest priority\n        messages). See <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man3/syslog.3.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">syslog</span>(3)</span></a> for\n        details. By default no filtering is applied (i.e. the default maximum log level is <code class=\"option\">debug</code>). Use\n        this option to configure the logging system to drop log messages of a specific service above the specified\n        level. For example, set <code class=\"varname\">LogLevelMax=</code><code class=\"option\">info</code> in order to turn off debug logging\n        of a particularly chatty unit. Note that the configured level is applied to any log messages written by any\n        of the processes belonging to this unit, sent via any supported logging protocol. The filtering is applied\n        early in the logging pipeline, before any kind of further processing is done. Moreover, messages which pass\n        through this filter successfully might still be dropped by filters applied at a later stage in the logging\n        subsystem. For example, <code class=\"varname\">MaxLevelStore=</code> configured in\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/journald.conf.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">journald.conf</span>(5)</span></a> might\n        prohibit messages of higher log levels to be stored on disk, even though the per-unit\n        <code class=\"varname\">LogLevelMax=</code> permitted it to be processed.</p>",
                "LogExtraFields": "<p>Configures additional log metadata fields to include in all log records generated by\n        processes associated with this unit. This setting takes one or more journal field assignments in the\n        format \"<code class=\"literal\">FIELD=VALUE</code>\" separated by whitespace. See\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.journal-fields</span>(7)</span></a>\n        for details on the journal field concept. Even though the underlying journal implementation permits\n        binary field values, this setting accepts only valid UTF-8 values. To include space characters in a\n        journal field value, enclose the assignment in double quotes (\"). \n        The usual specifiers are expanded in all assignments (see below). Note that this setting is not only\n        useful for attaching additional metadata to log records of a unit, but given that all fields and\n        values are indexed may also be used to implement cross-unit log record matching. Assign an empty\n        string to reset the list.</p>",
                "LogRateLimitIntervalSec": "<p>Configures the rate limiting that is applied to messages generated by this unit. If, in the\n        time interval defined by <code class=\"varname\">LogRateLimitIntervalSec=</code>, more messages than specified in\n        <code class=\"varname\">LogRateLimitBurst=</code> are logged by a service, all further messages within the interval are\n        dropped until the interval is over. A message about the number of dropped messages is generated. The time\n        specification for <code class=\"varname\">LogRateLimitIntervalSec=</code> may be specified in the following units: \"s\",\n        \"min\", \"h\", \"ms\", \"us\" (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.time.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.time</span>(7)</span></a> for details).\n        The default settings are set by <code class=\"varname\">RateLimitIntervalSec=</code> and <code class=\"varname\">RateLimitBurst=</code>\n        configured in <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/journald.conf.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">journald.conf</span>(5)</span></a>.\n        </p>",
                "LogRateLimitBurst": "<p>Configures the rate limiting that is applied to messages generated by this unit. If, in the\n        time interval defined by <code class=\"varname\">LogRateLimitIntervalSec=</code>, more messages than specified in\n        <code class=\"varname\">LogRateLimitBurst=</code> are logged by a service, all further messages within the interval are\n        dropped until the interval is over. A message about the number of dropped messages is generated. The time\n        specification for <code class=\"varname\">LogRateLimitIntervalSec=</code> may be specified in the following units: \"s\",\n        \"min\", \"h\", \"ms\", \"us\" (see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd.time.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd.time</span>(7)</span></a> for details).\n        The default settings are set by <code class=\"varname\">RateLimitIntervalSec=</code> and <code class=\"varname\">RateLimitBurst=</code>\n        configured in <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/journald.conf.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">journald.conf</span>(5)</span></a>.\n        </p>",
                "LogNamespace": "<p>Run the unit's processes in the specified journal namespace. Expects a short\n        user-defined string identifying the namespace. If not used the processes of the service are run in\n        the default journal namespace, i.e. their log stream is collected and processed by\n        <code class=\"filename\">systemd-journald.service</code>. If this option is used any log data generated by\n        processes of this unit (regardless if via the <code class=\"function\">syslog()</code>, journal native logging\n        or stdout/stderr logging) is collected and processed by an instance of the\n        <code class=\"filename\">systemd-journald@.service</code> template unit, which manages the specified\n        namespace. The log data is stored in a data store independent from the default log namespace's data\n        store. See\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">systemd-journald.service</span>(8)</span></a>\n        for details about journal namespaces.</p><p>Internally, journal namespaces are implemented through Linux mount namespacing and\n        over-mounting the directory that contains the relevant <code class=\"constant\">AF_UNIX</code> sockets used for\n        logging in the unit's mount namespace. Since mount namespaces are used this setting disconnects\n        propagation of mounts from the unit's processes to the host, similar to how\n        <code class=\"varname\">ReadOnlyPaths=</code> and similar settings (see above) work. Journal namespaces may hence\n        not be used for services that need to establish mount points on the host.</p><p>When this option is used the unit will automatically gain ordering and requirement dependencies\n        on the two socket units associated with the <code class=\"filename\">systemd-journald@.service</code> instance\n        so that they are automatically established prior to the unit starting up. Note that when this option\n        is used log output of this service does not appear in the regular\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/journalctl.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">journalctl</span>(1)</span></a>\n        output, unless the <code class=\"option\">--namespace=</code> option is used.</p>",
                "SyslogIdentifier": "<p>Sets the process name (\"<span class=\"command\"><strong>syslog</strong></span> tag\") to prefix log lines sent to\n        the logging system or the kernel log buffer with. If not set, defaults to the process name of the\n        executed process.  This option is only useful when <code class=\"varname\">StandardOutput=</code> or\n        <code class=\"varname\">StandardError=</code> are set to <code class=\"option\">journal</code> or <code class=\"option\">kmsg</code> (or to\n        the same settings in combination with <code class=\"option\">+console</code>) and only applies to log messages\n        written to stdout or stderr.</p>",
                "SyslogFacility": "<p>Sets the <span class=\"command\"><strong>syslog</strong></span> facility identifier to use when logging. One of\n        <code class=\"option\">kern</code>, <code class=\"option\">user</code>, <code class=\"option\">mail</code>, <code class=\"option\">daemon</code>,\n        <code class=\"option\">auth</code>, <code class=\"option\">syslog</code>, <code class=\"option\">lpr</code>, <code class=\"option\">news</code>,\n        <code class=\"option\">uucp</code>, <code class=\"option\">cron</code>, <code class=\"option\">authpriv</code>, <code class=\"option\">ftp</code>,\n        <code class=\"option\">local0</code>, <code class=\"option\">local1</code>, <code class=\"option\">local2</code>, <code class=\"option\">local3</code>,\n        <code class=\"option\">local4</code>, <code class=\"option\">local5</code>, <code class=\"option\">local6</code> or\n        <code class=\"option\">local7</code>. See <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man3/syslog.3.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">syslog</span>(3)</span></a> for\n        details. This option is only useful when <code class=\"varname\">StandardOutput=</code> or\n        <code class=\"varname\">StandardError=</code> are set to <code class=\"option\">journal</code> or <code class=\"option\">kmsg</code> (or to\n        the same settings in combination with <code class=\"option\">+console</code>), and only applies to log messages\n        written to stdout or stderr. Defaults to <code class=\"option\">daemon</code>.</p>",
                "SyslogLevel": "<p>The default <span class=\"command\"><strong>syslog</strong></span> log level to use when logging to the logging system or\n        the kernel log buffer. One of <code class=\"option\">emerg</code>, <code class=\"option\">alert</code>, <code class=\"option\">crit</code>,\n        <code class=\"option\">err</code>, <code class=\"option\">warning</code>, <code class=\"option\">notice</code>, <code class=\"option\">info</code>,\n        <code class=\"option\">debug</code>. See <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man3/syslog.3.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">syslog</span>(3)</span></a> for\n        details. This option is only useful when <code class=\"varname\">StandardOutput=</code> or\n        <code class=\"varname\">StandardError=</code> are set to <code class=\"option\">journal</code> or\n        <code class=\"option\">kmsg</code> (or to the same settings in combination with <code class=\"option\">+console</code>), and only applies\n        to log messages written to stdout or stderr. Note that individual lines output by executed processes may be\n        prefixed with a different log level which can be used to override the default log level specified here. The\n        interpretation of these prefixes may be disabled with <code class=\"varname\">SyslogLevelPrefix=</code>, see below. For\n        details, see <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/sd-daemon.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">sd-daemon</span>(3)</span></a>.\n        Defaults to <code class=\"option\">info</code>.</p>",
                "SyslogLevelPrefix": "<p>Takes a boolean argument. If true and <code class=\"varname\">StandardOutput=</code> or\n        <code class=\"varname\">StandardError=</code> are set to <code class=\"option\">journal</code> or <code class=\"option\">kmsg</code> (or to\n        the same settings in combination with <code class=\"option\">+console</code>), log lines written by the executed\n        process that are prefixed with a log level will be processed with this log level set but the prefix\n        removed. If set to false, the interpretation of these prefixes is disabled and the logged lines are\n        passed on as-is. This only applies to log messages written to stdout or stderr. For details about\n        this prefixing see\n        <a target=\"__blank\" href=\"https://www.freedesktop.org/software/systemd/man/sd-daemon.html#\"><span class=\"citerefentry\"><span class=\"refentrytitle\">sd-daemon</span>(3)</span></a>.\n        Defaults to true.</p>",
                "TTYPath": "<p>Sets the terminal device node to use if standard input, output, or error are connected to a TTY\n        (see above). Defaults to <code class=\"filename\">/dev/console</code>.</p>",
                "TTYReset": "<p>Reset the terminal device specified with <code class=\"varname\">TTYPath=</code> before and after\n        execution.  Defaults to \"<code class=\"literal\">no</code>\".</p>",
                "TTYVHangup": "<p>Disconnect all clients which have opened the terminal device specified with\n        <code class=\"varname\">TTYPath=</code> before and after execution. Defaults to \"<code class=\"literal\">no</code>\".</p>",
                "TTYVTDisallocate": "<p>If the terminal device specified with <code class=\"varname\">TTYPath=</code> is a virtual console\n        terminal, try to deallocate the TTY before and after execution. This ensures that the screen and scrollback\n        buffer is cleared. Defaults to \"<code class=\"literal\">no</code>\".</p>",
                "UtmpIdentifier": "<p>Takes a four character identifier string for an <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man5/utmp.5.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">utmp</span>(5)</span></a> and wtmp entry\n        for this service. This should only be set for services such as <span class=\"command\"><strong>getty</strong></span> implementations (such\n        as <a target=\"__blank\" href=\"http://linux.die.net/man/8/agetty\"><span class=\"citerefentry\"><span class=\"refentrytitle\">agetty</span>(8)</span></a>) where utmp/wtmp\n        entries must be created and cleared before and after execution, or for services that shall be executed as if\n        they were run by a <span class=\"command\"><strong>getty</strong></span> process (see below). If the configured string is longer than four\n        characters, it is truncated and the terminal four characters are used. This setting interprets %I style string\n        replacements. This setting is unset by default, i.e. no utmp/wtmp entries are created or cleaned up for this\n        service.</p>",
                "UtmpMode": "<p>Takes one of \"<code class=\"literal\">init</code>\", \"<code class=\"literal\">login</code>\" or \"<code class=\"literal\">user</code>\". If\n         <code class=\"varname\">UtmpIdentifier=</code> is set, controls which type of <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man5/utmp.5.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">utmp</span>(5)</span></a>/wtmp entries\n         for this service are generated. This setting has no effect unless <code class=\"varname\">UtmpIdentifier=</code> is set\n         too. If \"<code class=\"literal\">init</code>\" is set, only an <code class=\"constant\">INIT_PROCESS</code> entry is generated and the\n         invoked process must implement a <span class=\"command\"><strong>getty</strong></span>-compatible utmp/wtmp logic. If\n         \"<code class=\"literal\">login</code>\" is set, first an <code class=\"constant\">INIT_PROCESS</code> entry, followed by a\n         <code class=\"constant\">LOGIN_PROCESS</code> entry is generated. In this case, the invoked process must implement a\n         <a target=\"__blank\" href=\"http://linux.die.net/man/1/login\"><span class=\"citerefentry\"><span class=\"refentrytitle\">login</span>(1)</span></a>-compatible\n         utmp/wtmp logic. If \"<code class=\"literal\">user</code>\" is set, first an <code class=\"constant\">INIT_PROCESS</code> entry, then a\n         <code class=\"constant\">LOGIN_PROCESS</code> entry and finally a <code class=\"constant\">USER_PROCESS</code> entry is\n         generated. In this case, the invoked process may be any process that is suitable to be run as session\n         leader. Defaults to \"<code class=\"literal\">init</code>\".</p>",
                "KillMode": "<p>Specifies how processes of this unit shall be killed. One of\n        <code class=\"option\">control-group</code>, <code class=\"option\">mixed</code>, <code class=\"option\">process</code>,\n        <code class=\"option\">none</code>.</p><p>If set to <code class=\"option\">control-group</code>, all remaining processes in the control group of this\n        unit will be killed on unit stop (for services: after the stop command is executed, as configured\n        with <code class=\"varname\">ExecStop=</code>). If set to <code class=\"option\">mixed</code>, the\n        <code class=\"constant\">SIGTERM</code> signal (see below) is sent to the main process while the subsequent\n        <code class=\"constant\">SIGKILL</code> signal (see below) is sent to all remaining processes of the unit's\n        control group. If set to <code class=\"option\">process</code>, only the main process itself is killed (not\n        recommended!). If set to <code class=\"option\">none</code>, no process is killed (strongly recommended\n        against!). In this case, only the stop command will be executed on unit stop, but no process will be\n        killed otherwise.  Processes remaining alive after stop are left in their control group and the\n        control group continues to exist after stop unless empty.</p><p>Note that it is not recommended to set <code class=\"varname\">KillMode=</code> to\n        <code class=\"constant\">process</code> or even <code class=\"constant\">none</code>, as this allows processes to escape\n        the service manager's lifecycle and resource management, and to remain running even while their\n        service is considered stopped and is assumed to not consume any resources.</p><p>Processes will first be terminated via <code class=\"constant\">SIGTERM</code> (unless the signal to send\n        is changed via <code class=\"varname\">KillSignal=</code> or <code class=\"varname\">RestartKillSignal=</code>). Optionally,\n        this is immediately followed by a <code class=\"constant\">SIGHUP</code> (if enabled with\n        <code class=\"varname\">SendSIGHUP=</code>). If processes still remain after the main process of a unit has\n        exited or the delay configured via the <code class=\"varname\">TimeoutStopSec=</code> has passed, the termination\n        request is repeated with the <code class=\"constant\">SIGKILL</code> signal or the signal specified via\n        <code class=\"varname\">FinalKillSignal=</code> (unless this is disabled via the <code class=\"varname\">SendSIGKILL=</code>\n        option). See <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man2/kill.2.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">kill</span>(2)</span></a>\n        for more information.</p><p>Defaults to <code class=\"option\">control-group</code>.</p>",
                "KillSignal": "<p>Specifies which signal to use when stopping a service. This controls the signal that\n        is sent as first step of shutting down a unit (see above), and is usually followed by\n        <code class=\"constant\">SIGKILL</code> (see above and below). For a list of valid signals, see\n        <a target=\"__blank\" href=\"http://man7.org/linux/man-pages/man7/signal.7.html\"><span class=\"citerefentry\"><span class=\"refentrytitle\">signal</span>(7)</span></a>.\n        Defaults to <code class=\"constant\">SIGTERM</code>.</p><p>Note that, right after sending the signal specified in this setting, systemd will always send\n        <code class=\"constant\">SIGCONT</code>, to ensure that even suspended tasks can be terminated cleanly.</p>",
                "RestartKillSignal": "<p>Specifies which signal to use when restarting a service. The same as\n        <code class=\"varname\">KillSignal=</code> described above, with the exception that this setting is used in a\n        restart job. Not set by default, and the value of <code class=\"varname\">KillSignal=</code> is used.</p>",
                "SendSIGHUP": "<p>Specifies whether to send\n        <code class=\"constant\">SIGHUP</code> to remaining processes immediately\n        after sending the signal configured with\n        <code class=\"varname\">KillSignal=</code>. This is useful to indicate to\n        shells and shell-like programs that their connection has been\n        severed. Takes a boolean value. Defaults to \"no\".\n        </p>",
                "SendSIGKILL": "<p>Specifies whether to send\n        <code class=\"constant\">SIGKILL</code> (or the signal specified by\n        <code class=\"varname\">FinalKillSignal=</code>) to remaining processes\n        after a timeout, if the normal shutdown procedure left\n        processes of the service around. When disabled, a\n        <code class=\"varname\">KillMode=</code> of <code class=\"constant\">control-group</code>\n        or <code class=\"constant\">mixed</code> service will not restart if\n        processes from prior services exist within the control group.\n        Takes a boolean value. Defaults to \"yes\".\n        </p>",
                "FinalKillSignal": "<p>Specifies which signal to send to remaining\n        processes after a timeout if <code class=\"varname\">SendSIGKILL=</code>\n        is enabled. The signal configured here should be one that is\n        not typically caught and processed by services (<code class=\"constant\">SIGTERM</code>\n        is not suitable). Developers can find it useful to use this to\n        generate a coredump to troubleshoot why a service did not\n        terminate upon receiving the initial <code class=\"constant\">SIGTERM</code>\n        signal. This can be achieved by configuring <code class=\"varname\">LimitCORE=</code>\n        and setting <code class=\"varname\">FinalKillSignal=</code> to either\n        <code class=\"constant\">SIGQUIT</code> or <code class=\"constant\">SIGABRT</code>.\n        Defaults to <code class=\"constant\">SIGKILL</code>.\n        </p>",
                "WatchdogSignal": "<p>Specifies which signal to use to terminate the\n        service when the watchdog timeout expires (enabled through\n        <code class=\"varname\">WatchdogSec=</code>). Defaults to <code class=\"constant\">SIGABRT</code>.\n        </p>"
            },
            install:
                {
                    "Alias":
                        "<p>A space-separated list of additional names this unit shall be installed under. The names listed\n        here must have the same suffix (i.e. type) as the unit filename. This option may be specified more than once,\n        in which case all listed names are used. At installation time, <span class=\"command\"><strong>systemctl enable</strong></span> will create\n        symlinks from these names to the unit filename. Note that not all unit types support such alias names, and this\n        setting is not supported for them. Specifically, mount, slice, swap, and automount units do not support\n        aliasing.</p>",
                    "WantedBy": "<p>This option may be used more than once, or a\n        space-separated list of unit names may be given. A symbolic\n        link is created in the <code class=\"filename\">.wants/</code> or\n        <code class=\"filename\">.requires/</code> directory of each of the\n        listed units when this unit is installed by <span class=\"command\"><strong>systemctl\n        enable</strong></span>. This has the effect that a dependency of\n        type <code class=\"varname\">Wants=</code> or <code class=\"varname\">Requires=</code>\n        is added from the listed unit to the current unit. The primary\n        result is that the current unit will be started when the\n        listed unit is started. See the description of\n        <code class=\"varname\">Wants=</code> and <code class=\"varname\">Requires=</code> in\n        the [Unit] section for details.</p><p><span class=\"command\"><strong>WantedBy=foo.service</strong></span> in a service\n        <code class=\"filename\">bar.service</code> is mostly equivalent to\n        <span class=\"command\"><strong>Alias=foo.service.wants/bar.service</strong></span> in the\n        same file. In case of template units, <span class=\"command\"><strong>systemctl\n        enable</strong></span> must be called with an instance name, and\n        this instance will be added to the\n        <code class=\"filename\">.wants/</code> or\n        <code class=\"filename\">.requires/</code> list of the listed unit. E.g.\n        <span class=\"command\"><strong>WantedBy=getty.target</strong></span> in a service\n        <code class=\"filename\">getty@.service</code> will result in\n        <span class=\"command\"><strong>systemctl enable getty@tty2.service</strong></span>\n        creating a\n        <code class=\"filename\">getty.target.wants/getty@tty2.service</code>\n        link to <code class=\"filename\">getty@.service</code>.\n        </p>",
                    "RequiredBy": "<p>This option may be used more than once, or a\n        space-separated list of unit names may be given. A symbolic\n        link is created in the <code class=\"filename\">.wants/</code> or\n        <code class=\"filename\">.requires/</code> directory of each of the\n        listed units when this unit is installed by <span class=\"command\"><strong>systemctl\n        enable</strong></span>. This has the effect that a dependency of\n        type <code class=\"varname\">Wants=</code> or <code class=\"varname\">Requires=</code>\n        is added from the listed unit to the current unit. The primary\n        result is that the current unit will be started when the\n        listed unit is started. See the description of\n        <code class=\"varname\">Wants=</code> and <code class=\"varname\">Requires=</code> in\n        the [Unit] section for details.</p><p><span class=\"command\"><strong>WantedBy=foo.service</strong></span> in a service\n        <code class=\"filename\">bar.service</code> is mostly equivalent to\n        <span class=\"command\"><strong>Alias=foo.service.wants/bar.service</strong></span> in the\n        same file. In case of template units, <span class=\"command\"><strong>systemctl\n        enable</strong></span> must be called with an instance name, and\n        this instance will be added to the\n        <code class=\"filename\">.wants/</code> or\n        <code class=\"filename\">.requires/</code> list of the listed unit. E.g.\n        <span class=\"command\"><strong>WantedBy=getty.target</strong></span> in a service\n        <code class=\"filename\">getty@.service</code> will result in\n        <span class=\"command\"><strong>systemctl enable getty@tty2.service</strong></span>\n        creating a\n        <code class=\"filename\">getty.target.wants/getty@tty2.service</code>\n        link to <code class=\"filename\">getty@.service</code>.\n        </p>",
                    "Also":
                        "<p>Additional units to install/deinstall when\n        this unit is installed/deinstalled. If the user requests\n        installation/deinstallation of a unit with this option\n        configured, <span class=\"command\"><strong>systemctl enable</strong></span> and\n        <span class=\"command\"><strong>systemctl disable</strong></span> will automatically\n        install/uninstall units listed in this option as well.</p><p>This option may be used more than once, or a\n        space-separated list of unit names may be\n        given.</p>",
                    "DefaultInstance":
                        "<p>In template unit files, this specifies for\n        which instance the unit shall be enabled if the template is\n        enabled without any explicitly set instance. This option has\n        no effect in non-template unit files. The specified string\n        must be usable as instance identifier.</p>"
                }
        };

        $scope.unitVisibleItems = ['Description', 'After', 'Wants'];
        $scope.installVisibleItems = ['WantedBy'];
        $scope.serviceVisibleItems = ['Type', 'ExecStart', 'Restart', 'Environment'];

        $scope.unit = {
            Description: 'This unit will start after internet connection',
            Documentation: [],
            After: ['network.target'],
            Wants: ['network-online.target'],
            Requires: [],
            Requisite: [],
            BindsTo: [],
            PartOf: [],
            Conflicts: [],
            Before: [],
            OnFailure: [],
            PropagatesReloadTo: [],
            ReloadPropagatedFrom: [],
            JoinsNamespaceOf: [],
            RequiresMountsFor: [],
            OnFailureJobMode: 'replace',
            IgnoreOnIsolate: false,
            StopWhenUnneeded: false,
            RefuseManualStart: false,
            RefuseManualStop: false,
            AllowIsolate: false,
            DefaultDependencies: "yes",
            CollectMode: "inactive",
            FailureAction: 'none',
            SuccessAction: 'none',
            FailureActionExitStatus: '',
            SuccessActionExitStatus: '',
            JobTimeoutSec: 'infinity',
            JobRunningTimeoutSec: 'infinity',
            JobTimeoutAction: "",
            JobTimeoutRebootArgument: "",
            StartLimitIntervalSec: "",
            StartLimitBurst: "",
            StartLimitAction: "",
            RebootArgument: "",
            SourcePath: "",
            ConditionArchitecture: "",
            ConditionVirtualization: "",
            ConditionHost: "",
            ConditionKernelCommandLine: "",
            ConditionKernelVersion: "",
            ConditionEnvironment: "",
            ConditionSecurity: "",
            ConditionCapability: "",
            ConditionACPower: "",
            ConditionNeedsUpdate: "",
            ConditionFirstBoot: "",
            ConditionPathExists: "",
            ConditionPathExistsGlob: "",
            ConditionPathIsDirectory: "",
            ConditionPathIsSymbolicLink: "",
            ConditionPathIsMountPoint: "",
            ConditionPathIsReadWrite: "",
            ConditionPathIsEncrypted: "",
            ConditionDirectoryNotEmpty: "",
            ConditionFileNotEmpty: "",
            ConditionFileIsExecutable: "",
            ConditionUser: "",
            ConditionGroup: "",
            ConditionControlGroupController: "",
            ConditionMemory: "",
            ConditionCPUs: "",
            AssertArchitecture: "",
            AssertVirtualization: "",
            AssertHost: "",
            AssertKernelCommandLine: "",
            AssertKernelVersion: "",
            AssertSecurity: "",
            AssertCapability: "",
            AssertACPower: "",
            AssertNeedsUpdate: "",
            AssertFirstBoot: "",
            AssertPathExists: "",
            AssertPathExistsGlob: "",
            AssertPathIsDirectory: "",
            AssertPathIsSymbolicLink: "",
            AssertPathIsMountPoint: "",
            AssertPathIsReadWrite: "",
            AssertDirectoryNotEmpty: "",
            AssertFileNotEmpty: "",
            AssertFileIsExecutable: "",
            AssertUser: "",
            AssertGroup: "",
            AssertControlGroupController: "",
        };
        $scope.install = {
            WantedBy: ['multi-user.target'],
            Alias: "",
            RequiredBy: [],
            Also: [],
            DefaultInstance: "",
        };

        $scope.enums = {
            unit: {
                CollectMode: [
                    'inactive',
                    'inactive-or-failed',

                ],
                FailureAction: [
                    'none',
                    'reboot',
                    'reboot-force',
                    'reboot-immediate',
                    'poweroff',
                    'poweroff-force',
                    'poweroff-immediate',
                    'exit',
                    'exit-force'
                ],
                SuccessAction: [
                    'none',
                    'reboot',
                    'reboot-force',
                    'reboot-immediate',
                    'poweroff',
                    'poweroff-force',
                    'poweroff-immediate',
                    'exit',
                    'exit-force'
                ],
                OnFailureJobMode: [
                    'fail',
                    'replace',
                    'replace-irreversibly',
                    'isolate',
                    'flush',
                    'ignore-dependencies',
                    'ignore-requirements'
                ],
                DefaultDependencies: [
                    'yes',
                    'no'
                ]
            },
            service: {
                Type: [
                    'simple',
                    'exec',
                    'forking',
                    'oneshot',
                    'dbus',
                    'notify',
                    'idle'
                ],
                Restart: [
                    'no',
                    'on-success',
                    'on-failure',
                    'on-abnormal',
                    'on-watchdog',
                    'on-abort',
                    'always',
                ],
                NotifyAccess: [
                    'none',
                    'main',
                    'exec',
                    'all'
                ],
                OOMPolicy: [
                    'continue',
                    'stop',
                    'kill'
                ],
                CPUSchedulingPolicy: [
                    'other',
                    'batch',
                    'idle',
                    'fifo',
                    'rr'
                ],
                IOSchedulingClass: [
                    'none',
                    'realtime',
                    'best-effort',
                    'idle'
                ],
                ProtectSystem: [
                    'true',
                    'false',
                    'full',
                    'strict'
                ],
                ProtectHome: [
                    'true',
                    'false',
                    'read-only',
                    'tmpfs'
                ],
                LogLevelMax: [
                    'emerg',
                    'alert',
                    'crit',
                    'err',
                    'warning',
                    'notice',
                    'info',
                    'debug'
                ],
                SyslogLevel: [
                    'emerg',
                    'alert',
                    'crit',
                    'err',
                    'warning',
                    'notice',
                    'info',
                    'debug'
                ],
                SyslogFacility: [
                    'kern',
                    'user',
                    'mail',
                    'daemon',
                    'auth',
                    'syslog',
                    'lpr',
                    'news',
                    'uucp',
                    'cron',
                    'authpriv',
                    'ftp',
                    'local0',
                    'local1',
                    'local2',
                    'local3',
                    'local4',
                    'local5',
                    'local6',
                    'local7'
                ]
            },
        };

        $scope.showOptionsDialogue = function (ev, section, selectedSection) {

            $mdDialog.show({
                bindToController: true,
                locals: {
                    items: Object.keys($scope[section]),
                    selected: $scope[selectedSection]
                },
                controller: ['$scope', '$mdDialog', 'items', 'selected', function ($scope, $mdDialog, items, selected) {
                    $scope.items = items;
                    $scope.selected = selected;

                    $scope.close = function () {
                        $mdDialog.hide($scope.selected);
                    };
                    $scope.cancel = function () {
                        $mdDialog.cancel();
                    }
                }],
                template: `
        <md-dialog>
         <md-dialog-content>
           <div class="md-dialog-content">
            <md-input-container>
                <label>Options</label>
                <md-select ng-model="selected" multiple>
                    <md-optgroup label="Options">
                        <md-option ng-value="option" ng-repeat="option in items">
                            {{option}}
                        </md-option>
                    </md-optgroup>
                </md-select>
             
             </md-input-container>
             </div>
                
                <md-dialog-actions layout="row">
                <md-button ng-click="cancel()">
                    Cancel
                  </md-button>
                  <span flex></span>
                  <md-button ng-click="close()">
                    Ok
                  </md-button>
                </md-dialog-actions>                
        </md-dialog>`,
                parent: angular.element(document.body),
                targetEvent: ev
            }).then((selected) => {
                $scope[selectedSection] = selected;
            }).catch(console.log);

        };

        $scope.service = {
            Restart: 'always',
            Type: 'simple',
            RemainAfterExit: 'no',
            GuessMainPID: 'yes',
            PIDFile: '',
            BusName: '',
            ExecStart: '',
            ExecStartPre: '',
            ExecStartPost: '',
            ExecCondition: '',
            ExecReload: '',
            ExecStop: '',
            ExecStopPost: '',
            RestartSec: '100ms',
            TimeoutStartSec: '',
            TimeoutStopSec: '',
            TimeoutAbortSec: '',
            TimeoutSec: '',
            TimeoutStartFailureMode: '',
            TimeoutStopFailureMode: '',
            RuntimeMaxSec: '',
            WatchdogSec: '',
            SuccessExitStatus: '',
            RestartPreventExitStatus: true,
            RestartForceExitStatus: '',
            RootDirectoryStartOnly: false,
            NonBlocking: '',
            NotifyAccess: 'none',
            Sockets: '',
            FileDescriptorStoreMax: '',
            USBFunctionDescriptors: '',
            USBFunctionStrings: '',
            OOMPolicy: '',
            WorkingDirectory: '',
            RootDirectory: '',
            RootImage: '',
            RootHash: '',
            RootHashSignature: '',
            RootVerity: '',
            MountAPIVFS: '',
            BindPaths: '',
            BindReadOnlyPaths: '',
            User: '',
            Group: '',
            DynamicUser: '',
            SupplementaryGroups: '',
            PAMName: '',
            CapabilityBoundingSet: '',
            AmbientCapabilities: '',
            NoNewPrivileges: '',
            SecureBits: '',
            SELinuxContext: '',
            AppArmorProfile: '',
            SmackProcessLabel: '',
            LimitCPU: '',
            LimitFSIZE: '',
            LimitDATA: '',
            LimitSTACK: '',
            LimitCORE: '',
            LimitRSS: '',
            LimitNOFILE: '',
            LimitAS: '',
            LimitNPROC: '',
            LimitMEMLOCK: '',
            LimitLOCKS: '',
            LimitSIGPENDING: '',
            LimitMSGQUEUE: '',
            LimitNICE: '',
            LimitRTPRIO: '',
            LimitRTTIME: '',
            UMask: '',
            CoredumpFilter: '',
            KeyringMode: '',
            OOMScoreAdjust: 0,
            TimerSlackNSec: '',
            Personality: '',
            IgnoreSIGPIPE: true,
            Nice: '',
            CPUSchedulingPolicy: '',
            CPUSchedulingPriority: '',
            CPUSchedulingResetOnFork: false,
            CPUAffinity: '',
            NUMAPolicy: '',
            NUMAMask: '',
            IOSchedulingClass: '',
            IOSchedulingPriority: '',
            ProtectSystem: '',
            ProtectHome: '',
            RuntimeDirectory: '',
            StateDirectory: '',
            CacheDirectory: '',
            LogsDirectory: '',
            ConfigurationDirectory: '',
            RuntimeDirectoryMode: '',
            StateDirectoryMode: '',
            CacheDirectoryMode: '',
            LogsDirectoryMode: '',
            ConfigurationDirectoryMode: '',
            RuntimeDirectoryPreserve: '',
            TimeoutCleanSec: '',
            ReadWritePaths: [],
            ReadOnlyPaths: [],
            InaccessiblePaths: [],
            TemporaryFileSystem: '',
            PrivateTmp: '',
            PrivateDevices: [],
            PrivateNetwork: false,
            NetworkNamespacePath: '',
            PrivateUsers: false,
            ProtectHostname: false,
            ProtectClock: false,
            ProtectKernelTunables: false,
            ProtectKernelModules: false,
            ProtectKernelLogs: false,
            ProtectControlGroups: false,
            RestrictAddressFamilies: [],
            RestrictNamespaces: [],
            LockPersonality: false,
            MemoryDenyWriteExecute: false,
            RestrictRealtime: false,
            RestrictSUIDSGID: false,
            RemoveIPC: false,
            PrivateMounts: false,
            MountFlags: '',
            SystemCallFilter: [],
            SystemCallErrorNumber: '',
            SystemCallArchitectures: [],
            Environment: ["'TEST=test'"],
            EnvironmentFile: '',
            PassEnvironment: '',
            UnsetEnvironment: '',
            StandardInput: '',
            StandardOutput: '',
            StandardError: '',
            StandardInputText: '',
            StandardInputData: '',
            LogLevelMax: '',
            LogExtraFields: '',
            LogRateLimitIntervalSec: '',
            LogRateLimitBurst: '',
            LogNamespace: '',
            SyslogIdentifier: '',
            SyslogFacility: '',
            SyslogLevel: '',
            SyslogLevelPrefix: '',
            TTYPath: '',
            TTYReset: '',
            TTYVHangup: '',
            TTYVTDisallocate: '',
            UtmpIdentifier: '',
            UtmpMode: '',
            KillMode: '',
            KillSignal: '',
            RestartKillSignal: '',
            SendSIGHUP: '',
            SendSIGKILL: '',
            FinalKillSignal: '',
            WatchdogSignal: '',
        };

        $scope.addMapVariable = function (section, term) {

            if ($scope.inputKey && $scope.inputVar) {
                $scope[section][term].push("'" + $scope.inputKey + "=" + $scope.inputVar + "'");
                $scope.inputKey = '';
                $scope.inputVar = '';
            }
        };

        $scope.download = function (ev) {

            const confirm = $mdDialog.prompt()
                .title('Service Name')
                .textContent('Insert service file name')
                .placeholder('Service name')
                .ariaLabel('Service')
                .initialValue('example')
                .targetEvent(ev)
                .required(true)
                .ok('Download')
                .cancel('Cancel');

            $mdDialog.show(confirm)
                .then(function (name) {

                    if (!name.endsWith(".service")) {
                        name += ".service";
                    }

                    createFile(name, document.getElementById("preview").innerText);

                }, function () {
                    //Ignore
                });
        };

        function createFile(filename, text) {
            const pom = document.createElement('a');
            pom.setAttribute('href', 'data:text/plain;charset=utf-8,' + encodeURIComponent(text));
            pom.setAttribute('download', filename);

            if (document.createEvent) {
                const event = document.createEvent('MouseEvents');
                event.initEvent('click', true, true);
                pom.dispatchEvent(event);
            } else {
                pom.click();
            }
        }

    }])
    .directive('dPreview', ['$compile', '$interpolate', function ($compile, $interpolate) {
        return {
            scope: false,
            replace: true,
            link: function (scope, iElement, iAttrs) {

                let elementToCompile = '<div id="preview" class="preview"><p class="section">[Unit]<p/>';

                Object.keys(scope.unit).forEach((term) => {
                    elementToCompile += `<p ng-show="unitVisibleItems.includes('${term}')">{{ unitVisibleItems.includes('${term}') ? '${term}=' + (unit.${term}.constructor.name === 'Array' ? unit.${term}.join(' ') : unit.${term} ) : '' }} </p>`;
                });

                elementToCompile += '<p class="section">[Service]</p>'

                Object.keys(scope.service).forEach((term) => {
                    elementToCompile += `<p ng-show="serviceVisibleItems.includes('${term}')">{{ serviceVisibleItems.includes('${term}') ? '${term}=' + (service.${term}.constructor.name === 'Array' ? service.${term}.join(' ') : service.${term} ) : '' }} </p>`;
                });

                elementToCompile += '<p class="section">[Install]</p>'

                Object.keys(scope.install).forEach((term) => {
                    elementToCompile += `<p ng-show="installVisibleItems.includes('${term}')"> {{ installVisibleItems.includes('${term}') ? '${term}=' + (install.${term}.constructor.name === 'Array' ? install.${term}.join(' ') : install.${term} ) : '' }} </p>`;
                });

                elementToCompile += '</div>'

                iElement.append($compile(angular.element(elementToCompile))(scope));
            }
        }
    }])
    .directive('dUnit', ['$compile', function ($compile) {
        return {
            scope: false,
            link: function (scope, iElement, iAttrs) {

                const section = iAttrs.sec;
                const visibleItems = iAttrs.vis;


                Object.keys(scope[section]).forEach((term) => {

                    const helpVarName = section.trim() + term.trim() + 'Help';

                    let elementToCompile;

                    if (section === 'service' && term === 'Environment') {

                        elementToCompile = angular.element(`
                        <div ng-show="${visibleItems}.includes('${term}')" style="padding: 10px; border: 1px dashed grey; margin-bottom: 10px;">

                        ${term}
            
                        <md-input-container class="md-block md-icon-right">
            
                            <md-chips ng-model="${section}.${term}"
                                      md-removable="true"
                                      readonly="true"
                                      style="min-height: 48px; display: inline-block;">
                            </md-chips>
                        </md-input-container>
            
                        <div layout="row">
                            <div flex="40">
                                <md-input-container class="md-block">
                                    <label>Key</label>
                                    <input type="text" ng-model="inputKey">
                                </md-input-container>
                            </div>
                            <div flex="40">
                                <md-input-container class="md-block">
                                    <label>Value</label>
                                    <input type="text" ng-model="inputVar">
                                </md-input-container>
                            </div>
                            <div flex>
                                <md-button ng-click="addMapVariable('${section}', '${term}')">Add</md-button>
                            </div>
                        </div>
                    </div>`);

                    } else if (Array.isArray(scope[section][term])) {

                        elementToCompile = angular.element(`
                      <md-input-container ng-show="${visibleItems}.includes('${term}')" class="md-block md-icon-right">
                        <md-chips ng-model="${section}.${term}" input-aria-label="${term}" md-separator-keys="keys"
                                  placeholder="${term}"
                                   secondary-placeholder="Add another" input-aria-describedby="spaceSeparatorKeyWants">
                        </md-chips>
                        
                        
                                                     <md-button ng-click="${helpVarName}=!${helpVarName}" class="md-icon-button" aria-label="info" style="display:inline-block; margin: 0;
right: 2px;
left: auto;
position: absolute;
top: 0;">
                                   <md-icon ng-class="{'hint': ${helpVarName}}" md-svg-src="info.svg"></md-icon>
                             </md-button>
                           
                            
                            <ng-messages ng-messages="true" ng-if="${helpVarName}" role="alert">
                              <ng-message-default>${scope.docs[section][term]}</ng-message-default>
                            </ng-messages>
                        
                       </md-input-container>`);

                    } else if (typeof scope[section][term] === 'string') {

                        if (scope.enums[section] && scope.enums[section].hasOwnProperty(term)) {


                            elementToCompile = angular.element(`
                            <md-input-container ng-init="${helpVarName}=false"  ng-show="${visibleItems}.includes('${term}')" class="md-block md-icon-right">
                            <label>${term}</label>
                            <md-select ng-model="${section}.${term}">
                                <md-option ng-repeat="option in enums.${section}.${term}" value="{{option}}">
                                    {{option}}
                                </md-option>
                            </md-select>
                            
                          
                             <md-button ng-click="${helpVarName}=!${helpVarName}" class="md-icon-button" aria-label="info" style="display:inline-block; margin: 0;
right: 2px;
left: auto;
position: absolute;
top: 0">
                                  <md-icon ng-class="{'hint': ${helpVarName}}" md-svg-src="info.svg"></md-icon>
                             </md-button>
                           
                            
                            <ng-messages ng-messages="true" ng-if="${helpVarName}" role="alert">
                              <ng-message-default>${scope.docs[section][term]}</ng-message-default>
                            </ng-messages>
                            
                            
                            
                        </md-input-container>`);

                        } else {

                            elementToCompile = angular.element(`
                         <md-input-container ng-show="${visibleItems}.includes('${term}')" class="md-block md-icon-right">
                            <label>${term}</label>
                            <input type="text" ng-model="${section}.${term}">
                            
                            
                                                         <md-button ng-click="${helpVarName}=!${helpVarName}" class="md-icon-button" aria-label="info" style="display:inline-block; margin: 0;
right: 2px;
left: auto;
position: absolute;
top: 0;">
                                   <md-icon ng-class="{'hint': ${helpVarName}}" md-svg-src="info.svg"></md-icon>
                             </md-button>
                           
                            
                            <ng-messages ng-messages="true" ng-if="${helpVarName}" role="alert">
                              <ng-message-default>${scope.docs[section][term]}</ng-message-default>
                            </ng-messages>
                            
                            
                         </md-input-container>
                        `);

                        }

                    } else if (typeof scope[section][term] === 'boolean') {

                        elementToCompile = angular.element(`
                        <md-input-container ng-show="${visibleItems}.includes('${term}')" class="md-block md-icon-right">
                        <md-switch class="md-primary" ng-model="${section}.${term}">
                          ${term}
                        </md-switch>
                        
                                                     <md-button ng-click="${helpVarName}=!${helpVarName}" class="md-icon-button" aria-label="info" style="display:inline-block; margin: 0;
right: 2px;
left: auto;
position: absolute;
top: 0;">
                                   <md-icon ng-class="{'hint': ${helpVarName}}" md-svg-src="info.svg"></md-icon>
                             </md-button>
                           
                            
                            <ng-messages ng-messages="true" ng-if="${helpVarName}" role="alert">
                              <ng-message-default>${scope.docs[section][term]}</ng-message-default>
                            </ng-messages>
                        
                        </md-input-container>                        
                        `);

                    }

                    if (elementToCompile) {
                        iElement.append(elementToCompile);

                        $compile(elementToCompile)(scope);
                    }
                });
            }
        }
    }])
    .config(['$mdThemingProvider', function ($mdThemingProvider) {

        // Configure a dark theme with primary foreground yellow

        $mdThemingProvider.theme('default')
            .primaryPalette('amber')
            .dark();

    }]);