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.

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

needs-restarting should be able to list non-systemd processes that need restarting #1730

Open
evan-goode opened this issue Sep 25, 2024 · 3 comments

Comments

@evan-goode
Copy link
Member

dnf4 needs-restarting, called without any args, will list processes on the system that have mmapped deleted files and need to be restarted.

Going forward, Cockpit will be using this feature of dnf4 needs-restarting, so DNF 5 should support this feature too.

I propose a new flag, dnf5 needs-restarting --processes that lists processes that need restarting. dnf5 needs-restarting --processes should support an additional --exclude-services option (as in rpm-software-management/dnf-plugins-core#556) to filter out processes that are not managed by systemd (and would therefore already be listed by dnf5 needs-restarting --services).

dnf5 needs-restarting --processes should use the new approach used by dnf5 needs-restarting --services to determine whether a process is using outdated files, instead of looking at smaps like dnf4 needs-restarting does:

for each $process:
    find the $package that provides the binary for $process, if any
        recursively get all $dependencies of $package
        if $package or any $dependency has been updated since $process started
            recommend restart of $process
@ppisar
Copy link
Contributor

ppisar commented Sep 26, 2024

What about processes of executables that are not packaged? I would expect "dnf5 needs-restarting --processes" to catch them with inspecting memory mappings.

@evan-goode
Copy link
Member Author

What about processes of executables that are not packaged? I would expect "dnf5 needs-restarting --processes" to catch them with inspecting memory mappings.

Well, yes, DNF 4 supported that. I am just not a fan of tracing file dependencies by the crude approach of inspecting mmaps, and I think we should not support it in DNF 5. There are just so many opportunities for false negative results, for example if a process reads the old version of a file into memory and then closes it, or if (early in its lifetime) a process checks what version of one of its dependencies is installed and then (later in its lifetime) changes how it calls the dependency accordingly. When the package metadata is available to determine more formally what files a given binary depends on, we are much more equipped to recommend restart/no-restart.

@ppisar
Copy link
Contributor

ppisar commented Sep 27, 2024

I am just not a fan of tracing file dependencies by the crude approach of inspecting mmaps, and I think we should not support it in DNF 5.

Then it needs to be documented that DNF5 only handles processes of program owned by an installed RPM package.

There are just so many opportunities for false negative results, for example if a process reads the old version of a file into memory and then closes it, or if (early in its lifetime) a process checks what version of one of its dependencies is installed and then (later in its lifetime) changes how it calls the dependency accordingly.

I don't say it catches all instances. But it catches more of them than when you ignore memory-mapped files.

When the package metadata is available to determine more formally what files a given binary depends on, we are much more equipped to recommend restart/no-restart.

And at the same time missing the unpackaged ones.

I understand that the problem of unpackaged programs is an independent feature and if it will be implemented, it should be done independently. I'm only trying to emphasize that if you add --processes option, the user needs to understand that it does not mean all processes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants