Reboots and Linux/Windows

Posted Jun 12, 2003 13:10 UTC (Thu) by smoogen (subscriber, #97)
In reply to: Some interesting publicity by proski
Parent article: Some interesting publicity

The 'its less reboots' is actually getting to be a misnomer from us old dinosaurs. Many of the Windows updates can be applied without rebooting a machine.. the reboot is there to absolutely sure there arent any routines running depending on old DLL's in memory.

With all the multi-libbing that Linux has now, many a Linux box faces a similar issue. You update that XYZ package, but with all the apps that are running on your system linked to the old libXYZ, you either have to restart them or find them a bit flakey or insecure depending on what happens next. My old IBM/Sun/HP manuals tell me that I need to put the box into single user mode to apply patches and for patches that affect system libraries that a reboot may be needed for best functioning.

At the core of things the real factor is not the uptime between reboots as the amount of time that you can perform the work you need to. If somehow Windows could do this more than a Linux box then the user might not care if he has to reboot once a day..

Reboots and Linux/Windows

Posted Jun 12, 2003 13:21 UTC (Thu) by Ross (guest, #4065) [Link] (1 responses)

At least on Linux fuser(1) makes it easy to tell which processes are using
the old library.

Reboots and Linux/Windows

Posted Jun 13, 2003 21:09 UTC (Fri) by esh (guest, #140) [Link]

On many (most?) Linux systems you can put lsof(8) to good use. "lsof +L1" - sans quotes - will show you all commands which have files open where the link count has fallen below 1. Those are files that have actually been deleted on the file system, but the file itself is still kept around as long as a processes uses it. For this to show you old, untrustworthy processes, the old libraries need to be deleted, not just left around next to the shiny new replacements. But then again, you would want to delete those old library versions anyway - they are not to be trusted after all. The same goes for the programs themselves if a process still refers to an old version that has since been replaced (and deleted).