systemd service unit evaluation differences local RHEL vs production

systemd Service Unit Evaluation: RHEL 8/9 Local vs Production Differences

When the same systemd unit file runs on a local RHEL workstation and in a production environment, several directives are evaluated differently depending on SELinux state, name service resolution, and namespace configuration. The following breakdown separates confirmed behaviors from environment-dependent ones.

Environment Inheritance from Shell Profiles

systemd does not read interactive shell profiles such as ~/.bashrc or /etc/profile when starting a service unit. The service process receives a minimal environment supplied by the system manager, plus any variables explicitly set via Environment=, EnvironmentFile=, or systemctl set-environment. This behavior is deterministic and identical whether the unit runs locally or in production. If a unit relies on profile-defined variables, those must be redeclared in the unit file or exported via EnvironmentFile=.

WorkingDirectory= Resolution

WorkingDirectory= accepts an absolute path. If a relative path is provided, systemd resolves it relative to the service manager's root directory, effectively / for the system manager, not the user's home directory or the shell's current working directory. This resolution is deterministic across all RHEL 8 and RHEL 9 environments. To avoid unexpected paths, always specify an absolute path in WorkingDirectory=.

User= and Group= Resolution

User= and Group= are resolved at unit start using the Name Service Switch. In environments where /etc/passwd and /etc/group are the source, resolution is predictable and consistent between local and production. If production uses LDAP or SSSD, and the specified user or group is not reachable, the unit may fail to start or fall back to root, depending on configuration. Local file-based resolution is more predictable; always verify the account exists and is reachable on the target host.

SELinux Context Assignment

The SELinux context applied to a service process is determined by the policy's type-transition rules: systemd running as init_t executes the configured binary, and the binary's file type e.g., httpd_exec_t transitions the process into its domain e.g., httpd_t. Changing SELinux from permissive to enforcing does not recompute the context; it only determines whether access-vector-denial AVC denials block execution. A unit that starts successfully in permissive mode may fail in enforcing mode if AVC denials compound kernel-enforced hardening directives such as ProtectSystem= or NoNewPrivileges=.

Hardening Directives and Enforcing SELinux

Directives such as ProtectSystem=, PrivateTmp=, NoNewPrivileges=, and RestrictAddressFamilies= are enforced by the kernel and namespaces regardless of SELinux mode. In enforcing mode, SELinux denials can add additional restrictions, so a unit that works locally in permissive mode may encounter failures in production enforcing mode. Always test units under the same SELinux enforcement level as the target deployment.

Version Considerations

RHEL 8 and RHEL 9 ship systemd versions 239 and 252 respectively; behavior of newer directives may differ on RHEL 7 systemd 219. Units tested under permissive SELinux locally can fail silently in production enforcing mode; always check ausearch/audit logs for AVC denials after deployment.

Verification Commands

# Show evaluated properties of a unit
systemctl show myunit.service -p Environment -p WorkingDirectory -p User -p SELinuxContext

# Check SELinux mode and recent AVC denials
getenforce
sestatus
ausearch -m avc -ts recent

# Confirm the binary's label and running process context
ls -Z /usr/bin/mybinary
ps -eZ | grep myunit

# Catch directive errors before deployment
systemd-analyze verify myunit.service

If production starts fail with AVC denials, run ausearch -m avc -ts recent on the production host and review the unit file and binary path to determine whether a policy modification or a change to hardening directives is needed.