OpenRC and systemd unit file interoperability in Artix Linux: Compatibility limits and conversion needs
0 reputation · 27 Aug 2023, 22:53 UTC
0 reputation · 27 Aug 2023, 22:53 UTC
The goal is to ascertain whether a native systemd unit file (.service) can be executed directly on an Artix Linux OpenRC installation that has the systemd‑compat package installed, or whether it must first be converted into an OpenRC runscript.
Artix provides systemd‑compat as a translation layer, but its coverage of systemd unit options is not fully documented. Features such as Type=notify, ExecStartPre/Post, complex dependency graphs, environment files, and certain logging directives may be unsupported or behave differently. This uncertainty affects start‑up ordering, failure handling, and log directory conventions, and it is unclear whether future Artix releases will expand or restrict this compatibility.
What specific systemd unit options are known to fail or require adaptation when used via systemd‑compat on OpenRC?
How does the compatibility layer affect service dependency resolution and start‑up sequencing compared to native systemd?
Is there a documented threshold of unit complexity beyond which conversion to an OpenRC runscript is strongly recommended?
29275 reputation · 28 Aug 2023, 04:53 UTC
A native systemd unit file (.service) cannot be executed with full feature parity on Artix Linux OpenRC, even with systemd-compat installed. While the compatibility layer allows basic binaries to launch via ExecStart, it is a translation layer, not a full implementation of the systemd manager. If your service relies on advanced lifecycle management, complex dependencies, or specific systemd-only directives, it must be converted into a native OpenRC runscript.
The systemd-compat layer focuses on basic execution. The following options are known to fail or behave inconsistently:
ExecStartPre and ExecStartPost are typically ignored. Any prerequisite setup must be handled within a native OpenRC start() function.Type=notify is unsupported. OpenRC cannot process the notification sockets systemd uses to determine when a service is "ready."EnvironmentFile directives may be ignored, and logging directives intended for journald will not function as expected, as OpenRC typically logs to syslog or messages.Systemd uses a complex, parallelized dependency graph (Wants=, Requires=, After=). OpenRC uses a more linear, script-based dependency model. When using the compatibility layer, these complex graphs do not map 1:1. This often results in incorrect start-up sequencing or race conditions where a service attempts to start before its required network or filesystem dependencies are fully initialized.
Conversion to a native OpenRC runscript is strongly recommended if the unit file meets any of the following criteria:
Type other than simple.ExecStartPre or ExecStartPost for initialization.Socket Activation or Timer units.To verify if a compat-unit is functioning correctly, use the following scoped commands:
# Check if the process actually launched
ps aux | grep [service_name]
# Verify the service status within OpenRC
rc-status
Missing Diagnostic Detail: To provide a more specific recommendation, please specify if the service in question requires a specific Type= (e.g., forking or notify) or relies on a specific After= target.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.