Hello!
hear about new GLIBC vulnearability, read an
http://www.securityfocus.com/archive/1/534572
make a megascript:

- download all that files, and in its directory run "pkgtool", and "install packages from current directory".
looks like instead this i must be do "upgradepkg *.txz" , but now is too late - i have in packages list all that glibc x86_64_9 files, and also previous version x86_64-7 packages too.

try do "upgradepkg *.txz" now and get,as i can expect,

Skipping package glibc-zoneinfo-2014j-noarch-1 (already installed)

what i must do? do newer package automatically replace older? or i must manually remove via pkgtool -> remove, all new packages, and do upgradepkg ?

or what?
Also interested in - after that glibc upgrade i must restart server, or new packages start working ok without restart?
Also interesting about multilibs - after glibc upgrade i must build multilibs again?

Thanks in advance...

As you found, you can actually install the same package but different versions side-by-side. If the files are named the same, installpkg will clobber the existing files with the ones from the package you invoked pkgtool (installpkg) with. Normally, when you removepkg any package that has the same files found in other packages, removepkg will not touch them. The only grey area here is what any doinst.sh script has done. You can removepkg the older package, but with a package like glibc, you might want to have a fail-safe plan in case the system stops working. But in general, the thing to do is removepkg the older package, and not worry about upgradepkg --reinstall or trying to remove the newly installed package.

Note that I do not remember having to deal the glibc this way, so again, have a plan to handle anything that might happen.

Considering the type of vulnerability, I decided that it is easier just to reboot my systems. You don't always need to reboot, even for libc, but this had local and remote execution possibilities, and it is easier to flush old copies of libc with a reboot. Again plan accordingly.

I have never used multilib, so I do not know the steps, but your multilib needs an update too.

2 members found this post helpful.

I listed processes that had held open the previous version of libc

Then went and killed the user space ones.

For some of the system stuff you can use the init scripts - example:
For some processes you can just cause them to reload:
For myself I figured that restarting udevd wasn't important and didn't want to risk even trying on a remote server, as from experience you can't really restart it without some side effects. Please correct me if I'm wrong!

2 members found this post helpful.

Thanks you very much, comrades!
finally i remove new one packages, and do upgradepkg, then restart machine. looks, all works fine after restart

Ah thanks for refreshing my memory on how to handle it. I checked lsof previously, but decided libc touched enough services, I didn't want to audit each one. But I went ahead and checked udevd with objdump -T and found no gethostbyname symbols. So I think we could get by without a restart, but of course I can't know everyone's system.

OK good to know - I didn't expect udev to do host lookups but did not check.

I realised that killall -HUP is not useful -- the reason agetty was restarted was because it died in response to -HUP, and init restarted it.
I confused myself - -HUP causes some processes to reload their configs (inetd is an example) if they are programmed to respond to -HUP in this way: they don't restart the process, so -HUP would never be useful in this situation.