Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix leak in unit path cache and another small optimization #15954

Merged
merged 4 commits into from May 29, 2020
Merged

Fix leak in unit path cache and another small optimization #15954

merged 4 commits into from May 29, 2020

Commits on May 28, 2020

  1. core: make unit_set_invocation_id static 

    No functional change.
    @keszybz
    keszybz committed May 28, 2020
    Copy the full SHA
    db868d4 View commit details
    Browse the repository at this point in the history

  2. shared/unit-file: make sure the old hashmaps and sets are freed upon … 

    …replacement

Possibly fixes systemd#15220. (There might be another leak. I'm still investigating.)

The leak would occur when the path cache was rebuilt. So in normal circumstances
it wouldn't be too bad, since usually the path cache is not rebuilt too often. But
the case in systemd#15220, where new unit files are created in a loop and started, the leak
occurs once for each unit file:

$ for i in {1..300}; do cp ~/.config/systemd/user/test0001.service ~/.config/systemd/user/test$(printf %04d $i).service; systemctl --user start test$(printf %04d $i).service;done
    @keszybz
    keszybz committed May 28, 2020
    Copy the full SHA
    3fb2326 View commit details
    Browse the repository at this point in the history

  3. core: define UnitDependency iterators in loops 

    Reduced scope of variables is always nice.
    @keszybz
    keszybz committed May 28, 2020
    Copy the full SHA
    f6173cb View commit details
    Browse the repository at this point in the history

  4. manager: free the jobs hashmap after we have no jobs 

    After a larger transaction, e.g. after bootup, we're left with an empty hashmap
with hundreds of buckets. Long-term, it'd be better to size hashmaps down when
they are less than 1/4 full, but even if we implement that, jobs hashmap is
likely to be empty almost always, so it seems useful to deallocate it once the
jobs count reaches 0.
    @keszybz
    keszybz committed May 28, 2020
    Copy the full SHA
    a4ac27c View commit details
    Browse the repository at this point in the history