The behavior of Linux, after we have installed updates, is much better, in my opinion, that Windows behavior. Under Windows, virtually any system-wide update will require a reboot. But under Linux, often we can install library updates, without requiring this. However, there is some specific knowledge which users should have about this, which none of my Linux-using friends were actually able to reflect.

When we update a library, which is in-use by a running program, the old version of that library stays loaded in RAM and remains in use. The following is a Linux command, based on ‘lsof‘, which will report all the Processes still using libraries Deleted from the hard drive:


lsof | grep 'DEL.*lib' | cut -f 1 -d ' ' | sort -u



In order to minimize the consequences, Linux will generally compute the dependencies of updates, and restart services automatically if they are affected. However, this automatic restart of services will only take place for system-wide services, and not for services which run in user-land.

If the reader has a system service which has been configured to run under a system user-name, as opposed to a user-name belonging to a real user, then those will also get restarted automatically.

I.e., if I have received an update to my MySQL server, the globally-running MySQL server will also be restarted automatically, which actually runs as system user ‘mysql‘. But I know that ‘Akonadi‘, a PIM service running as user ‘dirk‘, runs its own, localized instance of a ‘mysqld‘ process, and that this instance will not be restarted.

Therefore, since I want my running processes up to date, and if all that was affected by the update was this running MySQL instance as user ‘dirk‘, one thing I can do is just log out my session and log back in again…

Further, if the update causes kernel-headers and kernel-images to be updated, my KDE desktop actually tells me that a restart is required… But the absence of any messages is not a better sign, under Linux, than my own knowledge is, of what I need to do. Under Linux, there could be no messages shown, just because there is no corresponding software installed, with the responsibility of showing me messages.


dirk@Phoenix:~$cd ~/tmp dirk@Phoenix:~/tmp$ find . | grep 'cat.s'
./cat.so
dirk@Phoenix:~/tmp$find . | grep 'cat*s' dirk@Phoenix:~/tmp$ find . | grep 'cat.*s'
./cat.so
dirk@Phoenix:~/tmp$find . | grep 'cats' dirk@Phoenix:~/tmp$ find . | grep 'ca.*t'
./ca.crt
./cat.so
dirk@Phoenix:~/tmp$find . | grep 'ca.*t.s' ./cat.so dirk@Phoenix:~/tmp$



lsof‘ does stand for ‘List Open Files’. But what they forgot to mention in my Comp-Sci Courses as well, is that ‘Open Files’ can include ‘Files Deleted by Other Processes’. The file handle is only closed, when the process that opened it, closes it.  And, .SO Files loaded as dependencies also seem to have handles, as portrayed by the kernel…

When deleted, their handles go into a failed state but continue to exist, which is necessary, because otherwise, the process would have no way to query the kernel, about what happened to the file. Because handles are only numbers – the use of which date back to the beginnings of Computing – code needs to rely on this number always referring to the same object, even without receiving any notifications of external events that could affect the object. It must keep its meaning, until the process dismisses it.