Lennart Poettering
5099a50d43
Previously, all user code was part of a session except for the code run as part of user@.service, which wasn't. This tries to make this more uniform: we'll track the user@.service runtime also as a session, but of the special type "manager". This means we have a really good overview finally of all user code that is running and can make decisions on what to start when and how long to keep it around. The pam_systemd client side will now be reasonably uniform: it just calls the CreateSession() bus call with the right class, and we'll return any data it needs. This means the weird "side-channel" we previously used to initialize XDG_RUNTIME_DIR for the user@.service goes away (see next commit). This conditionalizes various behaviours now cleanly depending on the session class: 1. SESSION_CLASS_WANTS_SCOPE() will be true for all classes except for the manager class. It declares whther the client shall be migrated into their own scope, which we generally want for sessions but not for the manager, since it already has its own service unit. 2. SESSION_CLASS_WANTS_SERVICE_MANAGER() will be true for all classes except for the manager class. It declares whether we shall start the service manager if a session of this class is around. Of course, this is off for the service manager, since this would always pin itself. 3. SESSION_CLASS_PIN_USER() will be true for all classes except for the manager class. It declares whether the we shall keep the User structure around for a user as long as the session is around. Now you might wonder why have these as three functions, even though they mostly give the same answers? That's because this all is preparation to add further session classes later that will return different answers for the three calls. (For example, a later patch adds "background-light" which will return true for SESSION_CLASS_WANTS_SCOPE() and SESSION_CLASS_PIN_USER(), but false for SESSION_CLASS_WANTS_SERVICE_MANAGER(). i.e. it will get a scope, and pin user tracking, but not start a service manager.
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 Code Map for information about this repository's layout and content.
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, join our IRC channel #systemd on libera.chat or Matrix channel
Stable branches with backported patches are available in the stable repo.