7b33c6228ff26b0bdb8ca5acf50b758c50cc9c6d
The manpages tell that such calls have quite limited meaning. logind has a few in the implementation of what remains of the session concept. At the same time, logind basically exposes sd_pid_get_session() as public API. This is absolutely required, to retain compatability e.g. with Xorg. But client code will work in more situations if it avoids assuming that it runs in a session itself. Its use inside the login session could be replaced with $XDG_SESSION_ID (which pam_systemd sets). I don't know whether it would be useful to change Xorg at this point or not. But if you were building something new, you would think about whether you want to support running it in a systemd service. Comment these logind API features, acknowledging the reason they exist is based in history. I.e. help readers avoid drawing implications from their existence which apply to history, but not the current general case. Finally, searching these revealed a call to sd_pid_get_session() in implementing some types of logind inhibitors. So these inhibitors don't work as intended when taken from inside a systemd user service :(. Comment this as well, deferring it as ticket #6852.
…
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%