Skip site navigation (1)Skip section navigation (2) 
Date:      Tue, 23 Jun 2026 11:10:12 +0200
From:      =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@FreeBSD.org>
To:        Mike <the.lists@mgm51.com>
Cc:        freebsd-pkgbase@FreeBSD.org
Subject:   Re: Moving to pkg-based in 15.1 ...
Message-ID:  <865x39r5aj.fsf@ltc.des.dev>
In-Reply-To: <27027cff-3c3b-41c6-a45f-f5e76e673011@mgm51.com> (Mike's message of "Mon, 22 Jun 2026 17:48:32 -0400")
References:  <db84590d-4284-4a65-83bd-65b517fb783d@mgm51.com> <86a4sot2l4.fsf@ltc.des.dev> <27027cff-3c3b-41c6-a45f-f5e76e673011@mgm51.com>
index | next in thread | previous in thread | raw e-mail 

Mike <the.lists@mgm51.com> writes:
> Agreed.  I have always restarted all daemons after an update, and did
> a reboot when I saw some things updated that I knew needed an reboot
> (e.g., kernel update).

Here's a trick...

You can use procstat -v to dump the memory map of any process, which
will show you which binary and libraries it has loaded:

    $ procstat -v $$ 
      PID              START                END PRT  RES PRES REF SHD FLAG  TP PATH
    91099     0x29bee374e000     0x29bee3759000 r--    8   38  33  11 CN--- vn /bin/sh
    91099     0x29bee3759000     0x29bee3777000 r-x   30   38  33  11 CN--- vn /bin/sh
    91099     0x29bee3777000     0x29bee3778000 r--    1    0   1   0 CN--- vn /bin/sh
    [...]
    91099     0x29c706072000     0x29c7060f7000 r--   78  332 662 274 CN--- vn /lib/libc.so.7
    91099     0x29c7060f7000     0x29c706242000 r-x  240  332 662 274 CN--- vn /lib/libc.so.7
    91099     0x29c706242000     0x29c70624c000 r--   10    0   1   0 CN--- vn /lib/libc.so.7
    91099     0x29c70624c000     0x29c706253000 rw-    7    0   1   0 CN--- vn /lib/libc.so.7
    [...]
    91099     0x49b7fa342000     0x49b7fa348000 r--    6   29 525 137 CN--- vn /libexec/ld-elf.so.1
    91099     0x49b7fa348000     0x49b7fa35f000 r-x   23   29 525 137 CN--- vn /libexec/ld-elf.so.1
    91099     0x49b7fa35f000     0x49b7fa360000 r--    1    0   1   0 CN--- vn /libexec/ld-elf.so.1

If any of these are replaced or deleted after the process starts, the
connection between vnode and path is lost and procstat no longer
displays the path:

    $ cp /bin/sh .
    $ ./sh
    $ procstat -v $$ | head -4
      PID              START                END PRT  RES PRES REF SHD FLAG  TP PATH
    91107     0x1e80b9a00000     0x1e80b9a0b000 r--   11   41   3   1 CN--- vn /home/des/sh
    91107     0x1e80b9a0b000     0x1e80b9a29000 r-x   30   41   3   1 CN--- vn /home/des/sh
    91107     0x1e80b9a29000     0x1e80b9a2a000 r--    1    0   1   0 CN--- vn /home/des/sh
    $ rm -f ./sh
    $ procstat -v $$ | head -4
      PID              START                END PRT  RES PRES REF SHD FLAG  TP PATH
    91107     0x1e80b9a00000     0x1e80b9a0b000 r--   11   41   3   1 CN--- vn 
    91107     0x1e80b9a0b000     0x1e80b9a29000 r-x   30   41   3   1 CN--- vn 
    91107     0x1e80b9a29000     0x1e80b9a2a000 r--    1    0   1   0 CN--- vn 

So you can use something like this to list all processes which have an
executable mapping where the original path is gone:

    # ps $(procstat -va | awk '$4 == "r-x" && $NF == "vn" { print $1 }')

This will give you a better idea of what actually needs restarting than
just guessing.

DES
-- 
Dag-Erling Smørgrav - des@FreeBSD.org
home | help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?865x39r5aj.fsf>