David Edmundson
6a881daf85
One problem found with the current draft specification is we can't have an application provide a non-transient systemd service file in a way that is spec compliant as the service name currently needs to end in a random token defined by the launcher. This came up when trying to put DBus activated services into the correct cgroup. There isn't enough metadata in the DBus service file to know the correct application ID, and the most intuitive fix is for those applications to just specify the SystemdService file in the existing system. They're generally unique for a given user session anyway so don't need a separate cgroup identifier. This changes the spec for RANDOM to be optional for services. It also changes the separator between in services to act like templates. Ultimately that's what we're trying to recreate with the RANDOM token of the systemd service and it's a better fit. It's needed as otherwise with launcher and the random ident being both optional it would be impossible to get the application ID reliably. Scopes are unchanged as they don't support templates.
System and Service Manager
Details
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.