s6
Software
skarnet.org

How to convert systemd unit files to an s6 installation

Converting a set of services managed by systemd 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 files and outputting a set of s6 service directories or s6-rc service definition directories would be extremely 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 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.

• All the directives listed by the order in the systemd documentation, with their difficulty
  • in systemd.unit(5)
    • [Unit] section
    • [Install] section
  • in systemd.service(5)
    • [Service] section
  • in systemd.exec(5)
    • Paths
    • User/group identity
    • Security
    • Mandatory access control
    • Process properties
    • Scheduling
    • Sandboxing
    • System call filtering
    • Environment
    • Logging and standard input/output
    • Credentials
    • System V compatibility
  • in systemd.kill(5)
• All the directives listed by their difficulty
  • 0
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

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; 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, 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 reproductble.

[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(), 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 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= : 6. 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().
• 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 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 a 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().
• Sockets= : 5. Requires an implementation of systemd's socket activation.
• FileDescriptorStoreMax= : 7. Requires an implementation of sd_notify(); 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 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). 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, 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, because the directives then become a single call to utmps-write 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=
• PropagatesStopTp=
• StopPropagatedFrom=
• IgnoreOnIsolate=
• StopWhenUnneeded=
• AllowIsolate=
• CollectMode=
• SourcePath=
• Type=idle
• RemainAfterExit=
• GuessMainPid=
• ExecReload=
• TimeoutStartFailureMode=
• TimeoutStopFailureMode=

Difficulty: 1 — direct functionality mapping

• RefuseManualStop=
• FailureActionExitStatus=
• SuccessActionExitStatus=
• Type=simple, exec or 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 and 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=
• 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 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=