Once upon a time, Tony Mountifield <tony@xxxxxxxxxxxxx> said:
> That shouldn't matter. The running programs will have mapped the original
> glibc into memory, which will create a reference to the original inode, even
> though the directory entries pointing to it are gone. See the output of "lsof"
> for one of those processes, and you will see the libraries tagged as (deleted).
There can be problems when a running process tries to dlopen() a shared
library file and gets a new version. For example, if a running process
tries to do a host or user lookup (and hadn't used the method before),
it could crash.
Also, just because a process is still running OK with the old library
doesn't mean you want it to; there could be a security change in the
update that means old processes are vulnerable.
You can use the "needs-restarting" program from the yum-utils package to
see a list of processes that appear to need a restart due to library (or
binary) changes. It isn't 100% accurate, but it is pretty close. There
are some things that can't be restarted (like PID 1); then you should
probably reboot.
--
Chris Adams <linux@xxxxxxxxxxx>
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
