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

[evan-goode]

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]

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]

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]

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.