S6-SYSTEMD-UNIT-CONVERSION(7)

💅 s6-systemd-unit-conv(7) — Miscellaneous Information Manual 🎀

ok so this is s6-systemd-unit-conv(7), and it lives in the Miscellaneous Information Manual, and it's literally all about how to convert systemd unit files to an s6 installation. buckle up bestie 💖

---

✨ NAME ✨

s6-systemd-unit-conversion — how to convert systemd unit files to an s6 installation. that's it, that's the name, slay 💅

---

🌸 DESCRIPTION 🌸

okay so the question of "how do i convert a whole set of services managed by systemd[1] into a set of services managed by s6" comes up constantly on our support channels. and lowkey, an automated conversion tool that parses a bunch of systemd.unit(5) files and spits out a bunch of directories (cf. s6-service-directory(7)) or s6-rc service definition directories (cf. s6-rc-compile(8)) would be genuinely so useful for people who wanna migrate to s6 but already have a whole existing base of services running under systemd. 🫶

unfortunately 😭 automating that conversion is extremely difficult. the main reason 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 like, few similarities between how systemd and s6 operate. ngl, it's giving two entirely different species. 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 tho (plot twist ✨), 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. bestie, here's the vibe check on the numbers:

• 0 — the directive is irrelevant to s6 and can just be ignored. bye 👋
• 1 — there is a straightforward, one-for-one way of translating the systemd directive into s6 parlance. easy ate. 💅
• 10 — 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. rip 🙈
• 9 — 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. not me writing that. never. 😭

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. slay.
• 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. main character energy tbh 👑
• 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 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. periodt.
• 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. big yikes. 💀

[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, no notes. 🎀
• BusName — 5. Avoid type dbus if you possibly can, bestie. 🙈
• ExecStart — 2, but with caveats, and the caveats are doing a lot of heavy lifting here. This is the bread and butter of service definitions — every one of your services is gonna have one of these, and the contents of ExecStart typically go straight into a run script (for longruns) or an up file (for oneshots). ✨ But since systemd hates simplicity with a burning passion, there are a whole bunch of transformations that have to happen to the command line before it's usable in a script, especially if the command has a special executable prefix. Implementing those has its own difficulty ratings, because of course it does:
  • @ — 1.
  • - — 1.
  • : — 2.
  • + — 5.
  • ! — 3.
  • !! — 3.
• ExecStartPre — 2. To get strict semantic equivalence with their systemd version, ExecStartPre lines have to be implemented as s6-rc oneshots, and the whole unit file has to be implemented as a bundle. That's the price of exactness. 💅
• ExecStartPost — 2. Same. 🫶
• ExecCondition — 2.
• ExecReload — 0. Literally zero! A reloading command that doesn't involve restarting the service does not need the service manager as a third-party. systemd cannot help inserting itself where it does not belong — it's giving main character syndrome. 😭
• ExecStop — 5. s6 only supports terminating services via signals, so if a service needs a specific command to stop it, the converter has 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's 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. Run such a thing (a process, not a service) outside of any kind of supervision framework, bestie. 🌸
• RuntimeRandomizedExtraSec — 4. Same.
• WatchdogSec — 7. Requires a watchdog implementation in the very specific systemd way. 🐕
• Restart — depends on the value, so buckle up:
  • 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. Slay.
• 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, so that part's already iconic. 👑
• USBFunctionDescriptors — 9. This is low-level machine management, not service management. Not our department. 💅
• 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, so it's 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 for 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. Looks very simple, but it is treacherous, because User is a mash-up 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 navigating your way across it requires very close attention. No cap.
• Group — 3. Same.
• DynamicUser — 5. Of course this flag has an entirely different meaning from setting users statically or dynamically — otherwise 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. 💅 That's the whole vibe.

🧬 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

• Personality — difficulty 3. It's giving "needs a whole command-line tool wrapping personality(2)", so yeah, not a one-liner bestie.
• IgnoreSIGPIPE — difficulty 2.

🌸 Scheduling

• Nice — difficulty 1. Baby steps, we love to see it.
• CPUSchedulingPolicy — difficulty 3. You're gonna need a command-line tool wrapping sched_setscheduler(2) for this one.
• CPUSchedulingPriority — difficulty 3. Same deal, same wrapper energy.
• CPUSchedulingResetOnFork — difficulty 3. Also same.
• CPUAffinity — difficulty 3. Requires a command-line tool around sched_setaffinity(2), no cap.
• NUMAPolicy — difficulty 3. Needs a tool around set_mempolicy(2).
• NUMAMask — difficulty 3. Same.
• IOSchedulingClass — difficulty 3. Needs a tool around ioprio_set(2).
• IOSchedulingPriority — difficulty 3. Same, literally.

💅 Sandboxing

Okay so here's the tea, and it's honestly kind of iconic: systemd gracefully turns off the sandboxing options on systems that don't have the necessary functionality. Which means all of these options can be ignored (difficulty 0) and your services will still work. Slay.

But — and this is the highkey important part — if you actually want the sandboxing to do something, you have 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 of these directives, the difficulty is somewhere between 2 (if the tool already exists, cute, we love a shortcut) and 8 (if it requires writing a full container implementation from scratch 😭). The devs are like, "the following numbers are only a rough guess", so take them as vibes, not gospel.

• ProtectSystem — difficulty 6.
• ProtectHome — difficulty 6.
• RuntimeDirectory — difficulty 1.
• StateDirectory — difficulty 1.
• CacheDirectory — difficulty 1.
• LogsDirectory — difficulty 1.
• ConfigurationDirectory — difficulty 1.
• RuntimeDirectoryMode — difficulty 1.
• StateDirectoryMode — difficulty 1.
• CacheDirectoryMode — difficulty 1.
• LogsDirectoryMode — difficulty 1.
• ConfigurationDirectoryMode — difficulty 1.
• RuntimeDirectoryPreserve — difficulty 3.
• TimeoutCleanSec — difficulty 3.
• ReadWritePaths — difficulty 5.
• ReadOnlyPaths — difficulty 5.
• InaccessiblePaths — difficulty 5.
• ExecPaths — difficulty 5.
• NoExecPaths — difficulty 5.
• TemporaryFileSystem — difficulty 5.
• PrivateTmp — difficulty 5.
• PrivateDevices — difficulty 5.
• PrivateNetwork — difficulty 8.
• NetworkNamespacePath — difficulty 8.
• PrivateIPC — difficulty 5.
• IPCNamespacePath — difficulty 5.
• PrivateUsers — difficulty 5.
• ProtectHostname — difficulty 5.
• ProtectClock — difficulty 7.
• ProtectKernelTunables — difficulty 7.
• ProtectKernelModules — difficulty 7.
• ProtectKernelLogs — difficulty 7.
• ProtectControlGroups — difficulty 7.
• RestrictAddressFamilies — difficulty 7.
• RestrictFilesystems — difficulty 7.
• RestrictNamespaces — difficulty 7.
• LockPersonality — difficulty 7.
• MemoryDenyWriteExecute — difficulty 7.
• RestrictRealtime — difficulty 7.
• RestrictSUIDSGID — difficulty 7.
• RemoveIPC — difficulty 5.
• PrivateMounts — difficulty 5.

🧚 System call filtering

• SystemCallFilter — difficulty 8.
• SystemCallErrorNumber — difficulty 8.
• SystemCallArchitectures — difficulty 8.
• SystemCallLog — difficulty 8.

🦋 Environment

• Environment — difficulty 1.
• EnvironmentFile — difficulty 1.
• PassEnvironment — difficulty 1.
• UnsetEnvironment — difficulty 1.

🎀 Logging and standard input/output

• StandardInput — difficulty 1.
• StandardOutput — difficulty 1, except for journal, which cannot be supported (10). Yeah, that one's just not happening.
• StandardError — Same.
• StandardInputText — difficulty 2.
• StandardInputData — difficulty 2.
• LogLevelMax — difficulty 3.
• LogExtraFields — difficulty 10.
• LogRateLimitIntervalSec — difficulty 10.
• LogRateLimitBurst — difficulty 10.
• LogFilterPatterns — difficulty 4.
• LogNamespace — difficulty 10.
• SyslogIdentifier — difficulty 2.
• SyslogFacility — difficulty 2.
• SyslogLevel — difficulty 2.
• SyslogLevelPrefix — difficulty 4.
• TTYPath — difficulty 1.
• TTYReset — difficulty 3.
• TTYVHangup — difficulty 3.
• TTYRows — difficulty 3.
• TTYColumns — difficulty 3.
• TTYDisallocate — difficulty 3.

🔥 Credentials

Not gonna lie, this one's a whole mood. systemd implements its own credentials store mechanism, like, 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

Bestie, 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. Iconic behavior honestly. If utmps cannot be used, though, then the utmp calls need to be reimplemented. F in the chat.

• UtmpIdentifier — difficulty 4.
• UtmpMode — difficulty 4.

---

💀 Directives documented in systemd.kill(5)

• KillMode — depends on the kill mode, bestie. control-group and mixed are 3, because they require cgroup control commands (that can be implemented in shell — yes, in shell, we love a low-effort queen). process is 1. none is 2.
• KillSignal — difficulty 1.
• RestartKillSignal — difficulty 5. s6 doesn't use a different signal for restarting, so implementing this requires an outer layer. (The page says, and I quote: this is overengineering.)
• SendSIGHUP — difficulty 5. Same.
• SendSIGKILL — difficulty 1.
• FinalKillSignal — difficulty 5. (This one is absolute overengineering 💀.)
• WatchdogSignal — difficulty 7. Only meaningful with an implementation of systemd's watchdog system.

⭐ Directives documented in systemd.resource-control(5)

Okay so all of these directives relate to cgroups, which means implementing them requires having access to at least some cgroups commands (difficulty at least 3). Others are even more involved, requiring tight service integration with the system — like, main-character-complex levels of involved.

🚨 Real talk: 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. Please don't come for us.

• CPUAccounting — difficulty 3.
• CPUWeight — difficulty 4.
• StartupCPUWeight — difficulty 9. Involves startup and shutdown.
• CPUQuota — difficulty 4.
• CPUQuotaPeriodSec — difficulty 4.
• AllowedCPUs — difficulty 3.
• StartupAllowedCPUs — difficulty 9. Involves startup and shutdown.
• AllowedMemoryNodes — difficulty 3.
• StartupAllowedMemoryNodes — difficulty 9. Involves startup and shutdown.
• MemoryAccounting — difficulty 3.
• MemoryMin — difficulty 3.
• MemoryLow — difficulty 3.
• MemoryHigh — difficulty 3.
• MemoryMax — difficulty 3.
• MemorySwapMax — difficulty 3.
• MemoryZSwapMax — difficulty 3.
• TasksAccounting — difficulty 3.
• TasksMax — difficulty 3.
• IOAccounting — difficulty 3.
• IOWeight — difficulty 3.
• StartupIOWeight — difficulty 9. Involves startup and shutdown.
• IODeviceWeight — difficulty 5.
• IOReadBandwidthMax — difficulty 5.
• IOWriteBandwidthMax — difficulty 5.
• IOReadIOPSMax — difficulty 5.
• IOWriteIOPSMax — difficulty 5.
• IODeviceLatencyTargetSec — difficulty 4.
• IPAccounting — difficulty 7.
• IPAddressAllow — difficulty 7.
• IPAddressDeny — difficulty 7.
• IPIngressFilterPath — difficulty 8.
• IPEgressFilterPath — difficulty 8.
• BPFProgram — difficulty 8.
• SocketBindAllow — difficulty 6.
• SocketBindDeny — difficulty 6.
• RestrictNetworkInterfaces — difficulty 4.
• DeviceAllow — difficulty 6.
• DevicePolicy — difficulty 6.
• Slice — difficulty 9. Slices are a systemd concept, and fully implementing them requires a holistic system analysis. Like, the whole system. Good luck babes.
• Delegate — difficulty 4.
• DisableControllers — difficulty 3.
• ManagedOOMSwap — difficulty 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. That's the tip, periodt.
• ManagedOOMMemoryPressure — difficulty 8.
• ManagedOOMMemoryPressureLimit — difficulty 8.
• ManagedOOMPreference — difficulty 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, bestie: 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. So like, don't get cocky just 'cause something's a 1, iykyk.

✨ 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

okay bestie, difficulty two is basically "yeah you got this, it's a chill afternoon project" 💅 no cap, these are the ones you can knock out without a whole character arc:

• 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

so like, this tier is where you gotta actually write a lil bit of code, but it's giving "one weekend, two iced coffees, done" 🍓 fr fr:

• 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

medium programming, medium vibes, medium "omg why is this taking me three evenings" energy 😭 but you'll slay it:

• 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

okay now we're in complex territory, bestie — this is the "clear your calendar and tell your friends you're busy" tier 👑:

• 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

yeah so at this point you're not "adding a feature", you're literally reimplementing a whole Linux subsystem and/or a chunk of the systemd architecture. it's giving icon behaviour but also it's giving suffering 🫶:

• 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

"complex Linux subsystem" AND "a significant part of the systemd architecture"?? bestie that's not a task, that's a whole personality change 💅 good luck, genuinely:

• 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

"complete implementation of complex Linux-specific tooling" — no notes, that's just the whole sentence, and it ate 🔥:

• JoinsNamespaceOf
• PrivateNetwork
• NetworkNamespacePath
• SystemCallFilter
• SystemCallErrorNumber
• SystemCallArchitectures
• SystemCallLog
• IPIngressFilterPath
• IPEgressFilterPath
• BPFProgram
• ManagedOOMSwap
• ManagedOOMMemoryPressure
• ManagedOOMMemoryPressureLimit
• ManagedOOMPreference

---

⭐ Difficulty: 9 — requires a full system analysis and remodelization

full system analysis AND remodelization?? that's not a port, that's a glow-up of your entire architecture. main character energy only 👑:

• 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

and here it is. the final boss. the manpage itself says it: implementing these basically means reimplementing systemd 💀 like, the whole thing. literally just build systemd again at this point, bestie. iconic of the doc to warn us tbh 🙈:

• StandardOutput=journal
• StandardError=journal
• LogExtraFields
• LogRateLimitIntervalSec
• LogRateLimitBurst
• LogNamespace

---

🦋 SEE ALSO

go read these, bestie — they're the whole friend group:

• 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)

and the link drop, all seven of them, exactly as given 🎀:

• [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 — so if you want the original-original, that's where it lives 💖

---

💜 AUTHORS

• Laurent Bercot
• Alexis <flexibeat@gmail.com> (man page port)

---

okay that's the whole page, bestie — you made it to the end 🥳 this lil port shipped with Debian on November 11, 2023, and honestly? reading all ten difficulty tiers in one sitting is a flex. go drink some water, you've earned it 💅🫶✨