30c81ce2cef97b05e143c7adf4cd1b1c5fb59932
This partially reverts3536f49e8fand3536f49e8f. When the user is dynamic, and we are setting up state, cache, or logs dirs, behaviour is unchanged, we always do a recursive chown. This is necessary because the user number might change between invocations. But when setting up a directory for non-dynamic user, or a runtime directory for a dynamic user, do any ownership or mode changes only when the directory is initially created. Nothing says that the files under those directories have to be all recursively owned by our user. This restores behaviour before3536f49e8f, so modifications to the state of the runtime directory persist between ExecStartPre's and ExecStart's, and even longer in case the directory is persistent. I think it _would_ be a nice property if setting a user would automatically propagate to ownership of any Runtime/Logs/Cache directories. But this is incompatible with another nice property, namely preserving changes to those directories made by an admin, and with allowing change of ownership of files in those directories by the service (e.g. to allow other users to access them). Of the two, I think the second property is more important. Also, it's backwards compatible. https://bugzilla.redhat.com/show_bug.cgi?id=1508495 There is no need to chmod a directory we just created, so move that step up into a branch. After that, 'effective' is only used once, so get rid of it too.
systemd - System and Service Manager
Details
General information about systemd can be found in the systemd Wiki.
Information about build requirements are 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 file for information 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.
Languages
C
88.5%
Shell
5.7%
Python
4.6%
Meson
1.1%