5 ms·

Thank you, it's not always clear when a reboot is needed after an update. I do it with kernel updates but wouldn't have in this case until I read your comment a

Thank you, it's not always clear when a reboot is needed after an update. I do it with kernel updates but wouldn't have in this case until I read your comment and ran the command to check. If would be nice if package managers would let us know when this is necessary, I expect that might be a hard thing to get right though.

JshWright 12y ago
You can check to see if any running process are using any stale libraries pretty easily: sudo lsof | grep lib | grep DEL You can then either reload those processes manually, or just bounce the box if that's easier.
- deleted 12y ago
  [deleted]
  - teraflop 12y ago
    You're testing what happens when you delete a file for which an open file descriptor exists. On Linux, a shared library will normally be memory-mapped but will not have a corresponding file descriptor. So lsof will show DEL, not (deleted). I wouldn't normally nitpick about something like this, but if people follow your advice they might incorrectly think they don't need to reboot.
  - nkurz 12y ago
    You can see that the removed file gets a (deleted) in the 'NAME' column but not DEL in the 'TYPE'. Maybe you have a cut-and-paste error? The before and after look the same to me, no "(deleted)" to be seen.
    - danielweber 12y ago
      Use contrl-F to search, it got clipped off the right-hand side by HN's raw-mode display.
- gtrubetskoy 12y ago
  There's also a rare chance that a program is statically linked, in which case upgrading glibc won't help, the program would need to be recompiled.
  - JshWright 12y ago
    Yeah, that's a good point, and definitely worth mentioning, but obviously rebooting isn't going to help in that case either. The parent was asking about how they would know if they need to reboot or not.
  - aidenn0 12y ago
    It is nearly impossible to statically link glibc.
    - cnvogel 12y ago
      ... with nss-modules being a major culprit, ironically... (on which gethostbyname relies greatly)...
0x0 12y ago
For debian, you can use "checkrestart -v" from the "debian-goodies" package.

JshWright 12y ago

You can check to see if any running process are using any stale libraries pretty easily: sudo lsof | grep lib | grep DEL You can then either reload those processes manually, or just bounce the box if that's easier.

deleted 12y ago
[deleted]
- teraflop 12y ago
  You're testing what happens when you delete a file for which an open file descriptor exists. On Linux, a shared library will normally be memory-mapped but will not have a corresponding file descriptor. So lsof will show DEL, not (deleted). I wouldn't normally nitpick about something like this, but if people follow your advice they might incorrectly think they don't need to reboot.
- nkurz 12y ago
  You can see that the removed file gets a (deleted) in the 'NAME' column but not DEL in the 'TYPE'. Maybe you have a cut-and-paste error? The before and after look the same to me, no "(deleted)" to be seen.
  - danielweber 12y ago
    Use contrl-F to search, it got clipped off the right-hand side by HN's raw-mode display.
gtrubetskoy 12y ago
There's also a rare chance that a program is statically linked, in which case upgrading glibc won't help, the program would need to be recompiled.
- JshWright 12y ago
  Yeah, that's a good point, and definitely worth mentioning, but obviously rebooting isn't going to help in that case either. The parent was asking about how they would know if they need to reboot or not.
- aidenn0 12y ago
  It is nearly impossible to statically link glibc.
  - cnvogel 12y ago
    ... with nss-modules being a major culprit, ironically... (on which gethostbyname relies greatly)...

0x0 12y ago

For debian, you can use "checkrestart -v" from the "debian-goodies" package.