Lennart Poettering
6ac62d61db
The per-unit-type release_resources() hook (most prominent use: to release a service unit's fdstore once a unit is entirely dead and has no jobs more) was currently invoked as part of unit_check_gc(), whose primary purpose is to determine if a unit should be GC'ed. This was always a bit ugly, as release_resources() changes state of the unit, while unit_check_gc() is otherwise (and was before release_resources() was added) a "passive" function that just checks for a couple of conditions. unit_check_gc() is called at various places, including when we wonder if we should add a unit to the gc queue, and then again when we take it out of the gc queue to dtermine whether to really gc it now. The fact that these checks have side effects so far wasn't too problematic, as the state changes (primarily: that services would empty their fdstores) were relatively limited and scope. A later patch in this series is supposed to extend the service state engine with a separate state distinct from SERVICE_DEAD that is very much like it but indicates that the service still has active resources (specifically the fdstore). For cases like that the releasing of the fdstore would result in state changes (as we'd then return to a classic SERVICE_DEAD state). And this is where the fact that the release_resources() is called as side-effect becomes problematic: it would mean that unit state changes would instantly propagate to state changes elsewhere, though we usually want this to be done through the run queue for coalescing and avoidance of recursion. Hence, let's clean this up: let's move the release_resources() logic into a queue of its own, and then enqueue items into it from the general state change notification handle in unit_notify().
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 or join our IRC channel.
Stable branches with backported patches are available in the stable repo.