A process works with a file that is not in its directory. That is how file names work and how dpkg installs an upgrade.
A name in a directory is only a link to the file itself, its inode. During an upgrade dpkg writes the new file next to the old one and renames it over. The name now leads to the new inode, and the old one has no names left — lsof shows 0 in the NLINK column.
A file without a name lives while at least one process holds it. The service's httpd started before the upgrade: the kernel mapped the program into its memory and runs it from there. The kernel marks such files (deleted) — in the process's /proc it looks like this:
The fixed program is on the disk, but the old one is running — vulnerability included. Only a new process loads the new file: you restart the service, sudo systemctl restart lab-feed. reload does not help here: it sends a signal to the same process, which only rereads its settings.
The nightly report program was upgraded at 03:00. At 04:00 cron started the report again. What will sudo ls -l /proc/<PID>/exe show for that process?
-
A program runs from the file in its directory; the
.debarchive is needed only for installing. Theexelink leads to the program file. -
The mark goes to a process started before the upgrade. The 04:00 process opened the program by name, and the name already leads to the new file.
A process started after the upgrade opens the program by name and gets the new file. Only processes that were running before the upgrade hold the deleted file.
Key points
-
After an upgrade, a process started earlier works with a deleted file:
(deleted)in/proc/<PID>/exeandmaps,0inNLINKfromlsof +L1. -
Only a new process loads the new program —
systemctl restart;reloadkeeps the same process.