What's the final solution for chrooted services? (haproxy this time)

[zerkms]

There was a discussion about postfix #130

Now there is a haproxy:

# needrestart -r l -p -v
Can't opendir(/dev/.lxd-mounts): Permission denied
 at /usr/lib/x86_64-linux-gnu/perl5/5.26/Proc/ProcessTable.pm line 162.
[main] eval /etc/needrestart/needrestart.conf
[main] needrestart v3.1
[main] running in root mode
[main] systemd detected
[main] container detected
[main] #15040 uses non-existing /usr/sbin/haproxy
[main] #15040 is a child of #15039
[Core] #36626 is a NeedRestart::Interp::Python
[Python] #36626: source=/usr/bin/networkd-dispatcher
[main] #15039 exe => /usr/sbin/haproxy
[main] #15039 is haproxy.service
[main] inside container, skipping kernel and microcode checks
WARN - Services: 1 (!), Containers: none, Sessions: none|Services=1;;0;0 Containers=0;;0;0 Sessions=0;0;;0
Services:
- haproxy.service

# ls -la /proc/15040/map_files/ |grep sbin
lr-------- 1 root    root    64 Jul 25 02:16 565329ee8000-56532a05c000 -> /usr/sbin/haproxy
lr-------- 1 root    root    64 Jul 25 02:19 56532a25b000-56532a25f000 -> /usr/sbin/haproxy
lr-------- 1 root    root    64 Jul 25 02:19 56532a25f000-56532a275000 -> /usr/sbin/haproxy

# ls -al /proc/15040/root/
total 12
drwxr-xr-x  3 root root 4096 Jun 17  2018 .
drwxr-xr-x 37 root root 4096 Jun 17  2018 ..
drwxr-xr-x  2 root root 4096 Jun 27 23:28 dev

I'm running needrestart on ubuntu 18.04, so it's a bit dated v3.1.

Was it fixed in a later version, or is a genuine bug? (my apologise if the former)

[djl]

I've been running into this (or a very similar problem), but with Firefox and Chrom(e|ium)

$ needrestart -v
... snip ...
[main] #1259525 uses non-existing /usr/lib/firefox/firefox
[main] #1259544 uses non-existing /usr/lib/firefox/firefox
[main] #1259578 uses non-existing /usr/lib/firefox/firefox
... snip ...
[main] #1385768 uses non-existing /usr/lib/chromium/chromium
[main] #1385770 uses non-existing /usr/lib/chromium/chromium
... snip ...
Your outdated processes:
chromium[1386083, 1386064, 1385770, 1385768, 1386032, 1386148, 1385968, 1386057, 1385966, 1386054, 1386172, 1386042, 1385949], Web Content[1259544, 1373284, 1373415, 1259525, 1288735, 1368644, 1360798], WebExtensions[1259578]

/proc/$pid/map_files/$maddr is a symlink to the "non-existing" file:

$ ls -l /proc/1259525/map_files
lr-------- 1 djl djl 64 Oct  7 13:16 55e5ee604000-55e5ee60f000 -> /usr/lib/firefox/firefox
lr-------- 1 djl djl 64 Oct  7 13:09 55e5ee60f000-55e5ee655000 -> /usr/lib/firefox/firefox
lr-------- 1 djl djl 64 Oct  7 13:16 55e5ee655000-55e5ee667000 -> /usr/lib/firefox/firefox
lr-------- 1 djl djl 64 Oct  7 13:16 55e5ee668000-55e5ee669000 -> /usr/lib/firefox/firefox
... snip ..

The obvious solution would be to just resolve that symlink:

index 9c6578e..028066e 100755
--- a/needrestart
+++ b/needrestart
@@ -506,7 +506,7 @@ if(defined($opt_l)) {
            unless($nrconf{skip_mapfiles} == 1) {
            $maddr =~ s/^0+([^-])/$1/;
            $maddr =~ s/-0+(.)/-$1/;
-			my @paths = ("/proc/$pid/map_files/$maddr", "/proc/$pid/root/$path");
+			my @paths = ("/proc/$pid/map_files/$maddr", "/proc/$pid/root/$path", readlink("/proc/$pid/map_files/$maddr"));
            my ($testp) = grep { -e $_; } @paths;
            unless($testp) {
                unless($path =~ m@^(/var)?/tmp/@ ||

Which does seem to fix the problem on my end:

$ ./needrestart -v
Scanning processes...
$

But I'm not sure if this is correct or if it'll break anything else.

[liske]

@djl 's solution is working if the chroot was started from the root namespace. Today's Linux systems allows more sophisticated setups... imagine nested containers (namespaces) running a chroot inside. It is not possible for needrestart to find the binary reliable. While running on a linux kernel this is not a major problem since the /proc/$PID/maps file shows the (deleted) flag if the file was removed. This was already observed by needrestart.

The default configuration has been changed to ignore non-existing files.