Long list of false (?) positives #286
Comments
|
Does this only happen when running needrstart as non-root? Do you have any special filesystem setup? |
|
Right now I have needrestart not installed any longer due to these false positives with which it came up constantly, asking e.g. to restart samba server again and again without any obvious need. And unfortunately I can't install it on the productive machine, no test system available currently . Sorry. So I can merely state from my recollection.
Single peculiarity might be, this is a live system, run from a static linuxfs container file (which allows system updates on the fly and gets remastered for making them permanent). I have no means to check whether needrestart would conjure the same false result on a hard disk install. Does needrestart access the file system in an irregular way, what could explain the misbehaviour? When accessing the files in the system by the default methods (from within file manager or from console, including stat, ls, which or dpkg-query and apt) or using any other program or tool no issues with the overlay can be observed. All the files and folders can be accessed normally. If so , then for reproducing the issue it might be worth to run the live ISO on a testing system, to understand what could cause the issue needrestart has then with it. It can be obtained from http://antixlinux.com/download/ I encountered the issue on the the 23.1 full runit versions, 32 and 64 bit both (other versions not in use here, probably same result). The live system can be run from e.g. an USB stick or a CD directly, so no lengthy install is needed. If so, other Distros with Live overlays such as Knoppix might see the same issues with needrestart. Some file system related output (Please note, system is meanwhile upgraded to antiX 23.1 full runit 64 bit) : ps -aux returns e.g. for firefox the line (and some more of them, all showing the very same path to the executable) : And from this output: And: The redirection is set up by default firefox esr package from the debian repos: There is nothing obvious what could explain needrestart not being able to access the files properly. |
Took a short scheduled maintenance downtime for an additional testing, installing needrestart temporarily before rebooting the machine from its default live medium again without it. Here the result, so you don't have to rely on my recollection merely: Here again, nothing was installed after reboot (besides needrestart itself) so no processes can be outdated: Would be great if we could use needrestart, since it provides a very much appreciated functionality. System details: (new system: point release, new kernel, another boot medium to exclude arbitrary hardware issues.) |
|
Thesis: the overflay might be the trigger. Needrestart checks the device and inode stats info from the filesystem with the values provided in |
|
I have the same problem on one small ARM embedded board with Debian 11. Following your comment above, I compared the inode from /proc/PID/maps with the one given by stat command: can confirm that they are equal. So, the bug should lie somewhere else. Here is an excerpt for ntfy, one of the services indicated as needing a restart: If there is any further test I could do, I'm willing to help. |
|
Increasing output, it might boil down to some missing feature in my kernel (which is not the standard Debian one): |
|
I've wrote a little script containing most of needrestart's inode validation logic. Could you please give it a try? The script expects a lines from #!/usr/bin/env perl
use strict;
use warnings;
while(<>) {
chomp;
my ($maddr, $mperm, $moffset, $mdev, $minode, $path) = split(/\s+/, $_, 6);
print STDERR <<MAPS;
mdev=$mdev
minode=$minode
path=$path
MAPS
# get on-disk info
my ($sdev, $sinode) = stat($path);
my @sdevs = (
# glibc gnu_dev_* definition from sysmacros.h
sprintf("%02x:%02x", (($sdev >> 8) & 0xfff) | (($sdev >> 32) & ~0xfff), (($sdev & 0xff) | (($sdev >> 12) & ~0xff))),
# Traditional definition of major(3) and minor(3)
sprintf("%02x:%02x", $sdev >> 8, $sdev & 0xff),
# kFreeBSD: /proc/<pid>/maps does not contain device IDs
qq(00:00)
);
# Don't compare device numbers on anon filesystems
# w/o a backing device (like OpenVZ's simfs).
my $major = (($sdev >> 8) & 0xfff) | (($sdev >> 32) & ~0xfff);
$mdev = "00:00"
if ($major == 0 || $major == 144 || $major == 145 || $major == 146);
print STDERR <<EOL;
---
sdev=$sdev
sdevs=@sdevs
sinode=$sinode
major=$major
mdev=$mdev
EOL
# compare maps content vs. on-disk
unless($minode eq $sinode && ((grep {$mdev eq $_} @sdevs) ||
# BTRFS breaks device ID mapping completely...
# ignoring unnamed device IDs for now
$mdev =~ /^00:/)) {
print STDERR "\n=> uses obsolete $path\n";
}
else {
print STDERR "\n=> mapped $path is up-to-date\n";
}
print STDERR "\n";
} |
|
Hello, thanks a lot for looking into this! I saved your script as Here are the relevant logs: |
Can you please remove the |
|
Ops, sorry! (now ntfy is pid 1616) |
System just rebooted, after completely apt-upgraded. Still needrestart presents me a long list of processes which it considers to be in need of a restart:
Nothing has been upgraded after the reboot, so in my understanding there should not show up any processes in need to be restarted.
Actually all the programs involved are present in most recent version and up to date when asking apt. Just for example one of them:
And I made sure actually this version of firefox is running (By the way, there isn't any other version installed)
Still, after restarting firefox (closing and starting it again after I made sure it actually was no longer to be found in process list htop) needrestart again marks it to be in need of a restart immediately when checking.
Same goes for all the other processes. After restarting them they are still decried as obsolete and in need of a restart.
So I'm a bit confused now. I should add I do use needrestart the first time, so I can't tell apart whether this is an expected and normal behaviour of needrestart. Intuitively I'd say there is something wrong in the output.
System details:
antiX 23 runit 64-bit full
Hardware:
Graphics: AMD Cedar [Radeon HD 5000/6000/7350/8350 Series] vendor: ASUSTeK driver: radeon
Display: x11 server: X.Org v: 1.21.1.7 driver: X: loaded: radeon
CPU: Intel Core i3 540 family: 6 model-id: 0x25 (37) stepping: 5
Please let me know whether you need some more pieces of information about the system or the software installed.
The text was updated successfully, but these errors were encountered: