file not deleted when installing PHSS_36311

[Srimalik]

Hi,

I have installed PHSS_36311, swagent logs show:

Installing fileset "PHSS_36311.CORE2-SHLIBS,r=1.0" (2 of 2).
* File "/usr/lib/hpux32/aries32.so" could not be removed. It was
renamed and added to the cleanup file
"/var/adm/sw/cleanupfile".
* File "/usr/lib/hpux32/pa_boot32.so" could not be removed. It
was renamed and added to the cleanup file
"/var/adm/sw/cleanupfile".

The files /usr/lib/hpux32/aries32.so and /usr/lib/hpux32/pa_boot32.so the corresponding 64 bit files were deleted without any problems.

Does this mean that these libs were in use(loaded into memory) by some application and after the installation of the patch the old core remain loaded into that application address space.

-->If the above is valid why does not this patch initiates a reboot after installing.


What do I need to load the new shared code. I have two options:

1) Restart all applications
a) find and stop all the apps which are using these objects.
b) somehow make sure that the object(aries32.so) is unloaded from the memory
c) start all your required parisc applications

2) Reboot the system

I do not know how to do 1(b). also reboot is better than finding and restarting individual apps.

--> Can sombdy suggest me a better option to load the new shared code in memory?

Thanks
Sri

[Steven E. Protter]

Shalom Sri,

A reboot test is required to see if this is a problem. The old file could be loaded into memory via binaries.

Binaries using these libraries need to be recompiled and tested as well.

SEP

[Srimalik]

Hi Steve,

>A reboot test is required to see if this is
>a problem. The old file could be loaded into
>memory via binaries.
I agree with you, I have already rebooted the machine to make sure that the new code is loaded also the ##aries.so is deleted now.

But My question is shouldn't the patch installation scripts make a reboot mandatory in this case.

Consider the scenario:
Two apps A and B are using aries.so, We install the patch, A & B are still using the old code, then A encounter a problem fixed in aries.so by this patch and fails, the user restarts A(he is confidant as he has installed the patch), new A will also use the old code a B has not unmapped the code from its address space, A will fail again and again.


>Binaries using these libraries need to be >recompiled and tested as well.
I am currently testing my binaries.
These objects are dynamically linked, Why would the apps using it need recompilation?

Another off-topic question :-)

What is the meaning of "Shalom"? , I know Salam is a greeting(a way to say hello) in urdu, are Shalom and salam related.

Thanks
Sri

[James R. Ferguson · Accepted solution]

Hi Sri:

A reboot was not necessary because the in-use binary could be renamed. New processes would then use the new version. When the last process associated with the old binary terminates, the old file can be removed.

What happens is that a 'mv' renames the file. This does not change the file's inode and so current processes referenecing the file by inode are unaffected. New processes invoke the new binary by name; find it; and use that version.

At some later date, when you do reboot, the '/var/adm/sw/cleanupfile' is examined for entries. In its list will be the old binary and it will be removed during the startup sequence that occurs *after* the reboot when no processes can be using the old, renamed file.

With regard to your question about "Shalom" [but not to steal SEP's thunder...]; you can better understand its meaning by reading this:

http://en.wikipedia.org/wiki/Shalom

Regards!

...JRF...

[Srimalik]

Shalom James,

>A reboot was not necessary because the in-use
>binary could be renamed. New processes would >then use the new version. When the last process
> associated with the old binary terminates, >the old file can be removed.

aries32.so is a shared object and not a binary, will not the linker/loader use the in memory table instead of inodes while finding if the lib is alredy loaded in the memory. and will not load the new version if it finds it in tables.

**I may be wrong***
but I thought that a shared lib is not unloaded until the last binary using it terminates and if another binary requests to load the same shared lib while another has already done so the loader checks some system tables for the existence of this lib in memory and does not load it again if found.
This is all theory I have read long back in books.

Is this done in a different way practically?

Thanks
Sri

[Srimalik]

You were right, I have just confirmed it by writing some sample programes. :)

Sri

[Dennis Handly]

>Does this mean that these libs were in use (loaded into memory) by some application and after the installation of the patch the old core remain loaded into that application address space.

Yes.

>-->If the above is valid why does not this patch initiates a reboot after installing.

Because I complained and told them NOT to do that any more. If you want, you can simply shutdown the application and restart.

>--> Can somebody suggest me a better option to load the new shared code in memory?

Why do you think you need to do that?

If you are installing Aries, you are doing that for a reason, some application doesn't work. In that case, you know the application, so restart it.

If you don't know the application, it should work perfectly fine with the old Aries.

>SEP: Binaries using these libraries need to be recompiled and tested as well.

A new Aries should be binary compatible. Do you test out your libc patches?

>My question is shouldn't the patch installation scripts make a reboot mandatory in this case.

No. Most patches that patch shlibs don't require a reboot. Why should Aries?
(Note there is only one isolated case where this causes problems.)

>the user restarts A (he is confidant as he has installed the patch), new A will also use the old code as B has not unmapped the code from its address space, A will fail again and again.

That's now how it works. As JRF said, the kernel checks based on inode number. The new Aries has a different inode than the old. Both images of aries are in memory.

>Why would the apps using it need recompilation?

Exactly.

>aries32.so is a shared object and not a binary, will not the linker/loader use the in memory table

The dynamic loader (dld) knows nothing about fancy-smancy kernel stuff. It uses mmap and then the kernel looks at inodes.

>but I thought that a shared lib is not unloaded until the last binary using it terminates and if another binary requests to load the same shared lib while another has already done so the loader

Yes, the kernel does this, not dld.

>checks some system tables for the existence of this lib in memory and does not load it again if found.

This check is based on inode.

[Srimalik]

Cleaning up old threads.