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.
And, there can be library updates that affect ‘
libc‘, and which would therefore affect virtually every process running. And in that case, it is useless to try to restart individual services; a restart of the computer is called for.
In the case of the KDE Libraries which were updated yesterday, my main issue was the fact that I have numerous user-processes running, all of which use those. These processes communicate with each other. If a newly-launched process was using the new library version and tried to interact with a process which was already running, and which was still using an older library version, eventually error messages would have come up.
Further, my session manager is ‘
kdm‘. It also depends on updated libraries, but runs as user ‘
root‘. Therefore, simply doing a log-out and a log-in will not restart this ‘
And so I felt it would make more sense, for me just to do the reboot, and not to wait for any error messages to greet me later on.
Further, that reboot was an opportunity for me to test, whether new system limits I had set in the file ‘
/etc/security/limits.conf‘ for user ‘
root‘, would successfully be reapplied to the ‘
memcached‘ daemon, just when I reboot, or whether that subject required further attention from me. Currently, I have ‘
memcached‘ running with the ‘
-k‘ option, which means that it is locking its pages of cached Web-content in physical memory and preventing them from being swapped out, in order to maximize the speed of this little Web-server. This is not the default behavior of ‘
P.S. If the reader has tried the above command-line
, and gotten no output, all this means is that he does not have any outdated library-versions loaded. The reader can also just try the command-line:
lsof | grep 'DEL'
This version will simply list all the processes with handles to files which have been deleted – hence the ‘
DEL‘ search-term fed to ‘
grep‘. Even though some users may expect otherwise, we often have such dangling file-handles, and often so in the directory ‘
/tmp‘. In the most mundane cases, they do not hinder system performance. But the added search-parameter ‘
lib‘ actually narrowed this list to libraries in the earlier example, and the ‘
cut‘ command showed only the first field in each line.
Also, the ‘
lsof‘ command can accept additional command-line switches itself, including
-nnV . But, depending on how many fields of additional information we want to see, the ‘
cut‘ command which follows may no longer be appropriate.
If the first version of the command generated output, then the next thing to do might be:
lsof | grep 'DEL.*lib' | sort -u
To get complete information about which libraries those are. Mine shows me:
root@Phoenix:/home/dirk# lsof | grep 'DEL.*lib' | sort -u v86d 153 root DEL REG 0,1 9048 /lib/x86_64-linux-gnu/libc.so.6 v86d 153 root DEL REG 0,1 9078 /lib/x86_64-linux-gnu/libx86.so.1 v86d 153 root DEL REG 0,1 9160 /lib64/ld-linux-x86-64.so.2 root@Phoenix:/home/dirk# cd /lib/x86_64-linux-gnu root@Phoenix:/lib/x86_64-linux-gnu# ls -l libc.so.6 lrwxrwxrwx 1 root root 12 Feb 29 12:29 libc.so.6 -> libc-2.19.so root@Phoenix:/lib/x86_64-linux-gnu#
I think the main reason I get this one false-positive, is the fact that on my box, ‘
v86d‘ may first run as part of ‘
initramfs‘. And then, when the real
root file system is mounted, these handles seem to get cut off by the final versions of the files.
If I was truly missing any file by the name of ‘
libc.so.6‘, it would not be possible to read this blog, nor for me to be typing it.
Further, another fact which can make it harder to reload libraries, just by restarting one program, is that Virtual Memory offers as a feature, that when multiple processes make use of the same shared library, that library only needs to get loaded into virtual memory once. And no attempt is made to reload it, until it is registered as not loaded.
Hence, if it was ‘
libc‘, not one program which was using it would need to be restarted, but all the programs which were using it would need to be halted at once, before the old version would actually get dropped. And only after that, once a new request is made to load it, will the up-to-date version get loaded.
So in the case of ‘
libc‘, this would just be pointless.