0

So, I know that it is possible to view or recover deleted files that are currently being used by a process. I've found out that this also applies to packages that were updated. So, let's say we update a package, but that package is still being used by another process and ultimately running on an older version of that package since it has not been restarted. So, my question is, how do we determine the processes that are running on an older version of that package due to it not being restarted?

1
  • With regards to how your question starts (recover deleted files) is your intention in listing the processes not restarted after a package update to recover the files deleted by the package update ? In which case, since packages are generally made of several files including possibly several libs, several configuration files, dbus services, icons and much more… and since it is pretty unlikely that whatever running process will have needed / kept open all of these… you of course cannot expect recovering a package that way.
    – MC68020
    Oct 21, 2022 at 22:42

1 Answer 1

0

Shared libraries inodes are registered in /proc/PID/maps, i.e. for nginx running on Fedora 36:

7f9190a00000-7f9190a9a000 r--p 00000000 103:04 794344                    /usr/lib64/libstdc++.so.6.0.30

The format of this file is explained here.

Basically the fifth field is the inode number. Once you update libraries, you have to traverse /proc/[0-9]+/maps and check whether individual shared libraries correspond to their real filesystem counterparts. To get the real file inode number you could use ls --inode /path/file or stat --printf=%i /path/file.

Here's a script which I've just penned which shows such processes:

#! /bin/bash

cd /proc || exit 1

for i in [0-9]*; do
    test ! -d $i && continue # PID could have already died
    awk '$6 ~ /\// {print $5" "$6}' "$i/maps" | sort -u | while read inode_p so; do
            if [ -f "$so" ]; then
                inode_r=`stat --format=%i "$so"`
                test "$inode_p" != "$inode_r" && echo "PID $i `cat $i/comm` maps stale file '$so'"
            fi
    done
done

It shows all mapped files issues. If you want to limit it to shared libraries only, replace -f "$so" with -e "$so".

2
  • This is a nice idea but only as far as only libs are concerned. Some package updates only update configuration files which would also need some application to be restarted. Say for example baselayout's upgrade updating some /etc/profile or whatever needing to at least run env-update && . /etc/profile or logout/login. (I've got not clue how to take this into account though)
    – MC68020
    Oct 21, 2022 at 23:00
  • Off the top of my head I don't know a single package which depends on changes in configuration files in other packages. I mean certainly there are such packages (e.g. you may alter /etc/nsswitch.conf) but I think that's not what the OP was asking about. And if a file is only read once when a daemon/service starts, there's no way to find out whether it needs to be restarted. Oct 22, 2022 at 0:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.