Zbigniew Jędrzejewski-Szmek
71889176e4
Without this parameter, we would allow user@ to start if the user has no password (i.e. the password is "locked"). But when the user does have a password, and it is marked as expired, we would refuse to start the service. There are other authentication mechanisms and we should not tie this service to the password state. The documented way to disable an *account* is to call 'chage -E0'. With a disabled account, user@.service will still refuse to start: systemd[16598]: PAM failed: User account has expired systemd[16598]: PAM failed: User account has expired systemd[16598]: user@1005.service: Failed to set up PAM session: Operation not permitted systemd[16598]: user@1005.service: Failed at step PAM spawning /usr/lib/systemd/systemd: Operation not permitted systemd[1]: user@1005.service: Main process exited, code=exited, status=224/PAM systemd[1]: user@1005.service: Failed with result 'exit-code'. systemd[1]: Failed to start user@1005.service. systemd[1]: Stopping user-runtime-dir@1005.service... Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1961746.
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list or join our IRC channel.
Stable branches with backported patches are available in the stable repo.