S6-SYSTEMD-UNIT-CONVERSION(7)

NAME
s6-systemd-unit-conversion - how to convert systemd unit files to an s6 installation

DESCRIPTION
Converting a set of services managed by systemd[1] to a set of services managed by s6 is a recurring question on our support channels, and having an automated conversion tool parsing a set of systemd.unit(5) files and outputting a set of directories ( cf. s6-service-directory(7)) or s6-rc service definition directories ( cf. s6-rc-compile(8)) would be useful to people who want to migrate to s6 but have an existing base of services running under systemd.

Unfortunately, automating such a conversion is extremely difficult. The main reason for this is that systemd and s6 are architectured in very different ways: how they view a set of services, how they modelize a machine, what kind of solution they bring to a given problem, and the extent of what they're supposed to manage — there are few similarities between how systemd and s6 operate. As a consequence, the way systemd maps a set of services into unit files is not isomorphic to the way s6 does, so translating a setup between systemd and s6 requires intelligence. It is not possible to write an automated tool that converts a set of services accurately and idiomatically without doing a full, deep system analysis - and writing such a tool would be a huge undertaking.

Fortunately, in practice, most unit files only use a small subset of all the theoretically supported directives: most services that run under systemd can be converted to run under s6 without too much trouble. So, depending on the exact nature of the set of services, it may be possible to write a reasonable converter, that is limited in what it supports but does not require a full understanding of systemd ( or even s6).

This document targets people who think about writing a tool to automatically convert a set of unit files to a set of s6 services and are trying to assess its feasability and difficulty. We analyze all the directives that may appear in a unit file for their services, and rate the difficulty of translating the directive, i.e. the amount of complexity that would need to go into the converter tool if that directive were to be supported.

We rate difficulty on a scale from ‘0’ to ‘10’. A ‘0’ means that the directive is irrelevant to s6 and can be ignored. A ‘1’ means that there is a straightforward, one-for-one way of translating the systemd directive into s6 parlance. A ‘10’ means that the directive is so systemd-specific that it is impossible to express it on an s6 system and the unit file cannot be converted as is. A ‘9’ means that it is theoretically possible to convert, given infinite time and manpower to write a tool that analyzes the systemd-managed system holistically and outputs an equivalent system managed by s6, but in practice nobody's ever going to write such a tool.

We only address directives that can appear in service units, which are the ones that can reasonably be expected to translate to s6 or s6-rc services. We do not address directives that can only appear in other kinds of unit files such as slices, timers, sockets, etc.

  Difficulty by directive
Use this section to answer the question: “ I have this directive in my unit file, how hard would it be to write a converter tool that processes this file? ”

Directives documented in systemd.unit(5)

    [Unit] section

        Description
            0.

        Documentation
            0.

        Wants
            3. Dependencies between services are implemented via s6-rc[1]; in order to implement Wants the converter needs to target s6-rc, which is a reasonable requirement for a complete set of services. However, Wants expresses weak dependencies, which are not supported by the current version of s6-rc, so the exact nature of the dependency needs to be checked by hand.

        Requires
            2. The converter needs to target s6-rc, but Requires dependencies map well to the s6-rc dependency model.

        Requisite
            3. systemd supports a lot of weird types of dependencies that the current version of s6-rc does not ( by design).

        BindsTo
            3. Same.

        PartOf
            3. Same.

        Upholds
            0. In s6, services are upheld by the supervisor, not by other services.

        Conflicts
            5. There are no negative dependencies in the s6 world, and a converter tool would have to implement it on top of the existing system.

        Before
            2. systemd loves to have a zillion of keywords to express slightly different kinds of dependencies, and only a small subset of all the possible combinations are useful.

        After
            2.

        OnFailure
            5. Permanent failure is a very exceptional state in s6, there are no hooks to do something when permanent failure occurs; so a converter would need to add scripting around that.

        OnSuccess
            2. These are oneshot dependencies.

        PropagatesReloadTo
            0. Under s6-rc you can either reload a single service or the whole dependency chain that starts at the service. Other configurations just make no sense.

        ReloadPropagatedFrom
            0. Same.

        PropagatesStopTo
            0. Same with stopping a single service or a dependency chain of services.

        StopPropagatedFrom
            0. Same.

        JoinsNamespaceOf
            8. There are no native s6 tools to manage namespaces.

        RequiresMountsFor
            4. Mounts are not handled in a special way in s6, the converter would have to know what service mounts what filesystem.

        OnFailureJobMode
            6. This is what happens when you mix layers.

        IgnoreOnIsolate
            0.

        StopWhenUnneeded
            0.

        RefuseManualStart
            4. Would need some scripting around. There's no reason to ever use that directive though.

        RefuseManualStop
            1.

        AllowIsolate
            0.

        DefaultDependencies
            2.

        CollectMode
            0.

        FailureAction
            3. Anything involving permanent failure need to be scripted around, because s6 considers that it is an extreme state that requires administrator attention and will stop making automatic decisions.

        SuccessAction
            3. That's a oneshot dependency, but systemd doesn't realize that.

        FailureActionExitStatus
            1.

        SuccessActionExitStatus
            1.

        JobTimeoutSec
            9. s6 has no concept of jobs.

        JobRunningTimeoutSec
            9. Same.

        JobTimeoutAction
            9. Same.

        JobTimeoutRebootArgument
            9. Same.

        StartLimitIntervalSec
            3. s6 does not limit start rate. It can stop a service that has a high death rate: that's the configuration knob that makes sense. That directive can be converted to check death interval instead.

        StartLimitBurst
            3. Same.

        StartLimitAction
            3. Same.

        RebootArgument
            5. Any “system mode” action such as a reboot has no place in an s6 set of services anyway; systemd obviously likes to mix unrelated layers. In the s6 world, the only place where a reboot should occur is s6-linux-init[2], and the related scripting in rc.init files.

        SourcePath
            0.

        Conditions and Asserts
            9. Most of these are tied to the global machine state and absolutely not local to a given set of services. And even for those that are not, what they do is change the whole service manager's behaviour depending on some external dynamic state such as the existence of a file in the filesystem — and that is entirely contrary to the s6 philosophy of making services predictable and reproducible.

    [Install] section
        Any directive under Install can be ignored, since it has no meaning on the run-time behaviour of the service. So the difficulty is 0. However, an automatic converter would need to analyze the whole installed service configuration, e.g. the links in /etc/systemd/system/multi-user.target.wants/, in order to understand the dependencies between services. systemd targets can typically be converted into s6-rc bundles.

Directives documented in systemd.service(5)

    [Service] section

        Type
            Depending on its type, a systemd “service” can translate to wildly different things under s6.

            simple
                1.

            exec
                1.

            forking
                2. This type is strongly discouraged.

            oneshot
                1.

            dbus
                5. This type requires implementing dbus management programs for s6.

            notify
                7. This type requires an implementation of a compatibility server for sd_notify(3), which is heavily tied to the monolithic systemd architecture and is difficult to support in a modular system such as s6. It is much easier to modify the services themselves so they use the s6-notifywhenup(7) s6 readiness notification mechanism instead of sd_notify.

            idle
                0. This type is meaningless under s6 and should be treated like simple.

        ExitType
            Again, it depends on the value.

            main
                1.

            cgroup
                3. This requires implementing, or having access to, command-line cgroup tools.

        RemainAfterExit
            0.

        GuessMainPid
            0. But don't use forking if you can avoid it.

        PIDFile
            2. Same.

        BusName
            5. Avoid type dbus if possible.

        ExecStart
            2, with caveats. This is the bread and butter of service definitions; all your services will likely have such a directive, and the contents of ExecStart will typically go into a run script ( for longruns) or an up file ( for oneshots). However, since systemd hates simplicity, there are a number of transformations that have to happen to the command line before it can be used in a script, and in particular if the command has a special executable prefix. Implementing these has its own difficulty ratings:

            @   1.

            -   1.

            :   2.

            +   5.

            !   3.

            !!  3.

        ExecStartPre
            2. In order to have a strict semantic equivalence with their systemd version, ExecStartPre lines must be implemented as s6-rc oneshots, and the whole unit file must be implemented as a bundle.

        ExecStartPost
            2. Same.

        ExecCondition
            2.

        ExecReload
            0. A reloading command that does not involve restarting the service does not need the service manager as a third-party. systemd cannot help inserting itself where it does not belong.

        ExecStop
            5. s6 only supports terminating services via signals, so if a service needs a specific command to be stopped, the converter needs to target an interface layer on top of s6 with a repository of stop commands; such a layer would likely need to be on top of s6-rc as well and a lot of complexity would ensue. Fortunately, a huge majority of services support termination via signals and it is often easy to avoid relying on ExecStop.

        ExecStopPost
            2. These are the down scripts of the ExecStartPre oneshots.

        RestartSec
            2. s6 has no setting for that, because it aims for maximum uptime; but there are still ways to implement that bad idea.

        TimeoutStartSec
            1.

        TimeoutStopSec
            1.

        TimeoutAbortSec
            7. This would need a watchdog implementation, in the server implementation of sd_notify(3).

        TimeoutSec
            1.

        TimeoutStartFailureMode
            0 for terminate and kill, 7 for abort.

        TimeoutStopFailureMode
            0 for terminate and kill, 7 for abort.

        RuntimeMaxSec
            4. This is the exact opposite of what you need a process supervisor for, so s6 does not implement it. It is best to run such a process ( not a service) outside of any kind of supervision framework.

        RuntimeRandomizedExtraSec
            4. Same.

        WatchdogSec
            7. Requires a watchdog implementation in the very specific systemd way.

        Restart
            Depends on the value.

            no  2, but why use a process supervisor in the first place?

            on-success
                2.

            on-failure
                2.

            on-abnormal
                2.

            on-watchdog
                7. Again, this requires a watchdog implementation.

            on-abort
                2.

            always
                1.

        SuccessExitStatus
            3. This can be easily scripted, but supporting all the systemd formats is annoying.

        RestartPreventExitStatus
            1. This is exactly what s6-permafailon(8) is for.

        RestartForceExitStatus
            2.

        RootDirectoryStartOnly
            2.

        NonBlocking
            5. This requires an emulation of systemd's socket activation. s6 provides the useful parts of it, like an s6-fdholder-daemon(8) process to hold file descriptors, but the systemd-specific API around socket activation, sd_listen_fds(3), still needs to be implemented.

        NotifyAccess
            1 if none, 7 otherwise, because it needs an implementation of sd_notify(3).

        Sockets
            5. Requires an implementation of systemd's socket activation.

        FileDescriptorStoreMax
            7. Requires an implementation of sd_notify(3); the fd store itself is native to s6.

        USBFunctionDescriptors
            9. This is low-level machine management, not service management.

        USBFunctionStrings
            9. Same.

        OOMPolicy
            9. Same.

Directives documented in systemd.exec(5)

    Paths

        ExecSearchPath
            1.

        WorkingDirectory
            2.

        RootDirectory
            1.

        RootImage
            6. I am discovering these options in real time and shaking my head — systemd still manages to baffle me with the amount of gratuitous ad-hoc that went into it. Still, this is regular low-level programming for Linux, this is less difficult to implement than systemd-specific stuff, that's why it only gets a 6.

        RootImageOptions
            6. Same.

        RootHash
            9. Please.

        RootHashSignature
            9.

        RootVerity
            9.

        MountAPIVFS
            6.

        ProtectProc
            6.

        ProcSubset
            6.

        BindPaths
            6.

        BindReadOnlyPaths
            6.

        MountImages
            6.

        ExtensionImages
            6.

        ExtensionDirectories
            6. It's a full low-level userspace implementation at this point. It's not very complex, the 6 feels accurate, but it's a whole lot of work. This is how systemd maintains its hegemony: not because it does incredible, awe-inspiring magic, but because it substitutes its monolithic self to a whole ecosystem, imposes its own API, and locks users in — people who want to smoothly transition away from systemd need to implement the whole shtick, which is obviously a huge undertaking, as the author of uselessd[4] can confirm.

    User/group identity

        User
            3. This looks very simple, but is treacherous, because User is a mash of two very different features: setting users statically ( via numeric ID, which don't change meanings between two invocations) and setting users dynamically ( via user name, which needs to be interpreted by getpwnam(3) on every invocation of the service). s6 supports both, but since these are two different things, the way to do them in s6 is different ( statically setting the UID and GID variables and calling ‘s6-applyuidgid -U’, or calling s6-setuidgid(8)). This is the exact kind of small detail that makes writing an automatic converter more difficult than it should be: the systemd unit file syntax is rife with semantic pitfalls, and managing your way across it requires very close attention.

        Group
            3. Same.

        DynamicUser
            5. Of course this flag has an entirely different meaning from setting users statically or dynamically, or else it would be too easy to understand. No, this flag is about allocating temporary new users, which is a prime example of overengineering.

        SupplementaryGroups
            1.Same.

        PAMName
            4. Requires PAM command-line utilities.

    Capabilities

        CapabilityBoundingSet
            4. This requires command-line tools implementing capabilities.

        AmbientCapabilities
            4. Same.

    Security

        NoNewPrivileges
            4. Similar to capabilities, this requires a command-line tool controlling the Linux-specific prctl(2) system call.

        SecureBits
            4. Same.

    Mandatory access control

        SELinuxContext
            5. This requires command-line tools managing SELinux.

        AppArmorProfile
            5. Same, with AppArmor.

        SmackProcessLabel
            5. Same, with SMACK. systemd needs to know and understand all the Linux security modules in order to interact with them. s6 does not — it expects a service's run script to perform all the needed process state changes and controls before executing into the daemon.

    Process properties

        LimitCPU
            1.

        LimitFSIZE
            1.

        LimitDATA
            1.

        LimitSTACK
            1.

        LimitCORE
            1.

        LimitRSS
            1.

        LimitNOFILE
            1.

        LimitAS
            1.

        LimitNPROC
            1.

        LimitMEMLOCK
            1.

        LimitLOCKS
            2. This resource limit isn't natively supported by s6-softlimit 8 , but it could appear in a future s6 version — and it's easy to add in any case.

        LimitSIGPENDING
            2. Same.

        LimitMSGQUEUE
            2. Same.

        LimitNICE
            2. Same.

        LimitRTPRIO
            2. Same.

        LimitRTTIME
            2. Same.

        UMask
            1.

        CoredumpFilter
            4. Requires a command-line tool around prctl(2).

        KeyringMode
            5. Requires interaction with PAM and an understanding of keyrings. Fortunately, practically nothing will need that.

        OOMScoreAdjust
            2.

        TimerSlackNSec
            4. Requires a command-line tool around prctl(2).

        Personality
            3. Requires a command-line tool around personality(2).

        IgnoreSIGPIPE
            2.

    Scheduling

        Nice
            1.

        CPUSchedulingPolicy
            3. Requires a command-line tool around sched_setscheduler(2).

        CPUSchedulingPriority
            3. Same.

        CPUSchedulingResetOnFork
            3. Same.

        CPUAffinity
            3. Requires a command-line tool around sched_setaffinity(2).

        NUMAPolicy
            3. Requires a command-line tool around set_mempolicy(2).

        NUMAMask
            3. Same.

        IOSchedulingClass
            3. Requires a command-line tool around ioprio_set(2).

        IOSchedulingPriority
            3. Same.

    Sandboxing
        systemd gracefully turns off the sandboxing options on systems that do not support the necessary functionality, so all these options can be ignored ( difficulty 0) and the services will still work. However, in order to actually implementing the sandboxing, it is necessary to pair s6 with command-line tools that perform the required process state changes by interfacing with namespaces, cgroups, seccomp, or any other relevant feature of the Linux kernel, so for all these directives the difficulty is somewhere between 2, if the tool already exists, and 8, if it requires writing a full container implementation from scratch. The following numbers are only a rough guess.

        ProtectSystem
            6.

        ProtectHome
            6.

        RuntimeDirectory
            1.

        StateDirectory
            1.

        CacheDirectory
            1.

        LogsDirectory
            1.

        ConfigurationDirectory
            1.

        RuntimeDirectoryMode
            1.

        StateDirectoryMode
            1.

        CacheDirectoryMode
            1.

        LogsDirectoryMode
            1.

        ConfigurationDirectoryMode
            1.

        RuntimeDirectoryPreserve
            3.

        TimeoutCleanSec
            3.

        ReadWritePaths
            5.

        ReadOnlyPaths
            5.

        InaccessiblePaths
            5.

        ExecPaths
            5.

        NoExecPaths
            5.

        TemporaryFileSystem
            5.

        PrivateTmp
            5.

        PrivateDevices
            5.

        PrivateNetwork
            8.

        NetworkNamespacePath
            8.

        PrivateIPC
            5.

        IPCNamespacePath
            5.

        PrivateUsers
            5.

        ProtectHostname
            5.

        ProtectClock
            7.

        ProtectKernelTunables
            7.

        ProtectKernelModules
            7.

        ProtectKernelLogs
            7.

        ProtectControlGroups
            7.

        RestrictAddressFamilies
            7.

        RestrictFilesystems
            7.

        RestrictNamespaces
            7.

        LockPersonality
            7.

        MemoryDenyWriteExecute
            7.

        RestrictRealtime
            7.

        RestrictSUIDSGID
            7.

        RemoveIPC
            5.

        PrivateMounts
            5.

    System call filtering

        SystemCallFilter
            8.

        SystemCallErrorNumber
            8.

        SystemCallArchitectures
            8.

        SystemCallLog
            8.

    Environment

        Environment
            1.

        EnvironmentFile
            1.

        PassEnvironment
            1.

        UnsetEnvironment
            1.

    Logging and standard input/output

        StandardInput
            1.

        StandardOutput
            1, except for journal which cannot be supported ( 10).

        StandardError
            Same.

        StandardInputText
            2.

        StandardInputData
            2.

        LogLevelMax
            3.

        LogExtraFields
            10.

        LogRateLimitIntervalSec
            10.

        LogRateLimitBurst
            10.

        LogFilterPatterns
            4.

        LogNamespace
            10.

        SyslogIdentifier
            2.

        SyslogFacility
            2.

        SyslogLevel
            2.

        SyslogLevelPrefix
            4.

        TTYPath
            1.

        TTYReset
            3.

        TTYVHangup
            3.

        TTYRows
            3.

        TTYColumns
            3.

        TTYDisallocate
            3.

    Credentials
        systemd implements its own credentials store mechanism, for no obvious benefit. The whole credentials system needs to be reimplemented outside of systemd in order for credentials-related directives to be supported by s6. Consequently, all these directives are rated 6.

    System V compatibility
        The utmp directives can be made significantly easier to implement if the target system is using utmps[5], because the directives then become a single call to utmps-write[6] with the relevant options. If utmps cannot be used, then the utmp calls need to be reimplemented.

        UtmpIdentifier
            4.

        UtmpMode
            4.

Directives documented in systemd.kill(5)

    KillMode
        Depends on the kill mode. control-group and mixed are 3, because they require cgroup control commands ( that can be implemented in shell). process is 1. none is 2.

    KillSignal
        1.

    RestartKillSignal
        5. s6 doesn't use a different signal for restarting; implementing this requires an outer layer. ( This is overengineering.)

    SendSIGHUP
        5. Same.

    SendSIGKILL
        1.

    FinalKillSignal
        5. ( This is absolute overengineering.)

    WatchdogSignal
        7. Only meaningful with an implementation of systemd's watchdog system.

Directives documented in systemd.resource-control(5)
    All these directives relate to cgroups, so implementing them means having access to at least some cgroups commands ( difficulty at least 3). Others are even more involved, requiring tight service integration with the system. Generally, seeing these directives in your unit files is a bad sign; despite some of them only having 3 or 4 listed, we do not recommend implementing systemd.resource-control(5) without having a full holistic view of the system.

    CPUAccounting
        3.

    CPUWeight
        4.

    StartupCPUWeight
        9. Involves startup and shutdown.

    CPUQuota
        4.

    CPUQuotaPeriodSec
        4.

    AllowedCPUs
        3.

    StartupAllowedCPUs
        9. Involves startup and shutdown.

    AllowedMemoryNodes
        3.

    StartupAllowedMemoryNodes
        9. Involves startup and shutdown.

    MemoryAccounting
        3.

    MemoryMin
        3.

    MemoryLow
        3.

    MemoryHigh
        3.

    MemoryMax
        3.

    MemorySwapMax
        3.

    MemoryZSwapMax
        3.

    TasksAccounting
        3.

    TasksMax
        3.

    IOAccounting
        3.

    IOWeight
        3.

    StartupIOWeight
        9. Involves startup and shutdown.

    IODeviceWeight
        5.

    IOReadBandwidthMax
        5.

    IOWriteBandwidthMax
        5.

    IOReadIOPSMax
        5.

    IOWriteIOPSMax
        5.

    IODeviceLatencyTargetSec
        4.

    IPAccounting
        7.

    IPAddressAllow
        7.

    IPAddressDeny
        7.

    IPIngressFilterPath
        8.

    IPEgressFilterPath
        8.

    BPFProgram
        8.

    SocketBindAllow
        6.

    SocketBindDeny
        6.

    RestrictNetworkInterfaces
        4.

    DeviceAllow
        6.

    DevicePolicy
        6.

    Slice
        9. Slices are a systemd concept, and fully implementing them requires a holistic system analysis.

    Delegate
        4.

    DisableControllers
        3.

    ManagedOOMSwap
        8. Out-of-memory management is an entire systemd subsystem; instead of implementing that, we recommend provisioning your machines correctly, and freeing up more resources for your applications by using s6.

    ManagedOOMMemoryPressure
        8.

    ManagedOOMMemoryPressureLimit
        8.

    ManagedOOMPreference
        8.

  Directives rated by difficulty
Use this section to answer the question: “ If I were to write a converter tool from systemd to s6, what subset of the unit file syntax should I focus on first? ”

Take this classification with a grain of salt: for instance, it does not make sense to implement an easy directive if it's only used in the context of a larger subsystem that's much harder to implement - typically, most cgroups-related resource control directives.

Difficulty: 0 — directives that can be ignored.

    Description

    Documentation

    Upholds

    PropagatesReloadTo

    PropagatesStopTo

    StopPropagatedFrom

    IgnoreOnIsolate

    StopWhenUnneeded

    AllowIsolate

    CollectMode

    SourcePath

    Type=idle

    RemainAfterExit

    GuessMainPid

    ExecReload

    TimeoutStartFailureMode

    TimeoutStopFailureMode

Difficulty: 1 — direct functionality mapping

    RefuseManualStop

    FailureActionExitStatus

    SuccessActionExitStatus

    Type=simple|exec|oneshot

    ExitType=main

    TimeoutStartSec

    TimeoutStopSec

    TimeoutSec

    Restart=always

    RestartPreventExitStatus

    NotifyAccess=none

    ExecSearchPath

    RootDirectory

    SupplementaryGroups

    LimitCPU

    LimitFSIZE

    LimitDATA

    LimitSTACK

    LimitCORE

    LimitRSS

    LimitNOFILE

    LimitAS

    LimitNPROC

    LimitMEMLOCK

    UMask

    Nice

    RuntimeDirectory

    StateDirectory

    CacheDirectory

    LogsDirectory

    ConfigurationDirectory

    RuntimeDirectoryMode

    StateDirectoryMode

    CacheDirectoryMode

    LogsDirectoryMode

    ConfigurationDirectoryMode

    Environment

    EnvironmentFile

    PassEnvironment

    UnsetEnvironment

    StandardInput

    StandardOutput
        (except journal)

    StandardError
        ( except journal)

    TTYPath

    KillMode=process

    KillSignal

    SendSIGKILL

Difficulty: 2 — straightforward implementation

    Requires

    Before

    After

    OnSuccess

    DefaultDependencies

    Type=forking

    PIDFile

    ExecStart
        ( omitting some prefixes)

    ExecStartPre

    ExecStartPost

    ExecCondition

    ExecStopPost

    RestartSec

    Restart
        except on-watchdog

    RestartForceExitStatus

    RootDirectoryStartOnly

    WorkingDirectory

    LimitLOCKS

    LimitSIGPENDING

    LimitMSGQUEUE

    LimitNICE

    LimitRTPRIO

    LimitRTTIME

    OOMScoreAdjust

    IgnoreSIGPIPE

    StandardInputText

    StandardInputData

    SyslogIdentifier

    SyslogFacility

    SyslogLevel

    KillMode=none

Difficulty: 3 — requires easy additional programming

    Wants

    Requisite

    BindsTo

    PartOf

    FailureAction

    SuccessAction

    StartLimitIntervalSec

    StartLimitBurst

    StartLimitAction

    ExitType=cgroup

    SuccessExitStatus

    User

    Group

    Personality

    CPUSchedulingPolicy

    CPUSchedulingPriority

    CPUSchedulingResetOnFork

    CPUAffinity

    NUMAPolicy

    NUMAMask

    IOSchedulingClass

    IOSchedulingPriority

    RuntimeDirectoryPreserve

    TimeoutCleanSec

    LoglevelMax

    TTYReset

    TTYVHangup

    TTYRows

    TTYColumns

    TTYDisallocate

    KillMode=control-group|mixed

    CPUAccounting

    AllowedCPUs

    AllowedMemoryNodes

    MemoryAccounting

    MemoryMin

    MemoryLow

    MemoryHigh

    MemoryMax

    MemorySwapMax

    MemoryZSwapMax

    TasksAccounting

    TasksMax

    IOAccounting

    IOWeight

    DisableControllers

Difficulty: 4 — requires medium additional programming

    RuntimeMaxSec

    RuntimeRandomizedExtraSec

    RequiresMountsFor

    RefuseManualStart

    PAMName

    CapabilityBoundingSet

    AmbientCapabilities

    NoNewPrivileges

    SecureBits

    CoredumpFilter

    TimerSlackNSec

    LogFilterPatterns

    SyslogLevelPrefix

    UtmpIdentifier

    UtmpMode

    CPUWeight

    CPUQuota

    CPUQuotaPeriodSec

    IODeviceLatencyTargetSec

    RestrictNetworkInterfaces

    Delegate

Difficulty: 5 — requires complex additional programming

    Conflicts

    OnFailure

    RebootArgument

    Type=dbus

    BusName

    ExecStop

    NonBlocking

    Sockets

    DynamicUser

    SELinuxContext

    AppArmorProfile

    SmackProcessLabel

    KeyringMode

    ReadWritePaths

    ReadOnlyPaths

    InaccessiblePaths

    ExecPaths

    NoExecPaths

    TemporaryFilesystem

    PrivateTmp

    PrivateDevices

    PrivateIPC

    IPCNamespacePath

    PrivateUsers

    ProtectHostname

    RemoveIPC

    PrivateMounts

    RestartKillSignal

    SendSIGHUP

    FinalKillSignal

    IODeviceWeight

    IOReadBandwidthMax

    IOWriteBandwidthMax

    IOReadIOPSMax

    IOWriteIOPSMax

Difficulty: 6 — requires a full independent implementation of a Linux subsystem and/or a part of the systemd architecture

    OnFailureJobMode

    RootImage

    RootImageOptions

    MountAPIVFS

    ProtectProc

    ProcSubset

    BindPaths

    BindReadOnlyPaths

    MountImages

    ExtensionImages

    ExtensionDirectories

    ProtectSystem

    ProtectHome

    All credentials-related[7] directives

    SocketBindAllow

    SocketBindDeny

    DeviceAllow

    DevicePolicy

Difficulty: 7 — requires a full independent implementation of a complex Linux subsystem and/or a significant part of the
    systemd architecture

    Type=notify

    TimeoutAbortSec

    TimeoutStartFailureMode=abort

    TimeoutStopFailureMode=abort

    WatchdogSec

    Restart=on-watchdog

    NotifyAccess

    FileDescriptorStoreMax

    ProtectClock

    ProtectKernelTunables

    ProtectKernelModules

    ProtectKernelLogs

    ProtectControlGroups

    RestrictAddressFamilies

    RestrictFilesystems

    RestrictNamespaces

    LockPersonality

    MemoryDenyWriteExecute

    RestrictRealtime

    RestrictSUIDSGID

    WatchdogSignal

    IPAccounting

    IPAddressAllow

    IPAddressDeny

Difficulty: 8 — requires a complete implementation of complex Linux-specific tooling

    JoinsNamespaceOf

    PrivateNetwork

    NetworkNamespacePath

    SystemCallFilter

    SystemCallErrorNumber

    SystemCallArchitectures

    SystemCallLog

    IPIngressFilterPath

    IPEgressFilterPath

    BPFProgram

    ManagedOOMSwap

    ManagedOOMMemoryPressure

    ManagedOOMMemoryPressureLimit

    ManagedOOMPreference

Difficulty: 9 — requires a full system analysis and remodelization

    JobTimeoutSec

    JobRunningTimeoutSec

    JobTimeoutAction

    JobTimeoutRebootArgument

    Conditions and Asserts

    USBFunctionDescriptors

    USBFunctionStrings

    OOMPolicy

    RootHash

    RootHashSignature

    RootVerity

    StartupCPUWeight

    StartupAllowedCPUs

    StartupAllowedMemoryNodes

    StartupIOWeight

    Slice

Difficulty: 10 — implementing this basically means reimplementing systemd

    StandardOutput=journal

    StandardError=journal

    LogExtraFields

    LogRateLimitIntervalSec

    LogRateLimitBurst

    LogNamespace

SEE ALSO
ioprio_set(2), personality(2), prctl(2), sched_setaffinity(2), sched_setscheduler(2), set_mempolicy(2), getpwnam(3), sd_listen_fds(3), sd_notify(3), systemd.exec(5), systemd.kill(5), systemd.resource-control(5), systemd.service(5), systemd.unit(5), s6-notifywhenup(7), s6-service-directory(7), s6-fdholder-daemon(8), s6-permafailon(8), s6-rc-compile(8), s6-setuidgid(8)

[1] https://systemd.io/

[2] https://skarnet.org/software/s6-rc/

[3] https://skarnet.org/software/s6-linux-init/

[4] https://web.archive.org/web/20150516113530/http://uselessd.darknedgy.net/

[5] https://skarnet.org/software/utmps/

[6] https://skarnet.org/software/utmps/utmps-write.html

[7] https://man7.org/linux/man-pages/man5/systemd.exec.5.html#CREDENTIALS

This man page is ported from the authoritative documentation at: https://skarnet.org/software/s6/unit-conversion.html

AUTHORS
Laurent Bercot Alexis <flexibeast@gmail.com> (man page port)