HP-UX is very robust when it come to protecting the running peice of code. If you were a library or a program writer and wanted to patch a running binary or currently in use lib, you may have to shutdown the system to single user and then do your
job.

Question 1: Is it possible to replace a running code on HP-UX? Like change a library that is being used, without killing the process that is using it?
eg. /usr/bin/foosrvr is running, your job is to replace the binary with new version, without effecting the system from it's current state.

Question 2: How would you replace /usr/lib/libc.1? Even in single user mode it will be used by init and if you kill init, you shutdown the system, you cannot do it solaris way (boot from cd, mount root partition and replace files etc.)

e.g.: Your job is to replace libc.1 either in single user mode or multi-user mode

This is not a hard question to answer, given that you can dig and dig, dig, and dig lot deeper.

Good luck and have fun.
 

Answer for question 1 is
mv /usr/bin/footsrvr /usr/bin/footsrvr.1
now you can copy the new binary.
I do not know answer for the second one.

Wrong!! Try again!!
You will be able to do mv opr back and forth on the binary.

Try something simple. Write a small C program that runs infinitely, do fuser on it, note the proc id. Now do your mv opr, do the
fuser again. Fuser does not return the proc id.

Reason: Because you disassociated the vnode without the running process knowing about it, next time the process need to
access the vnode for peice of code or data etc, sections in the binary have changed and it _WILL_ dump.

Nice try. You're close, keep trying. :
 

Hey!! that wont work.
If you change it that way.. then, you must do something .. such that - your new pgm overlays the memory-space of the running pgm.  So, to achieve what the question says, can be done by replacing the dynamic lib files ie ->

any newer dlopen()s / dlsym()s from the running executable will load the new symbols from the new objs (new lib file).

Well.. never tried this before..
possibly you have to do :
# cp libfoo.so lib_oldfoo.so
# cc -G -o libfoo.so lib_oldfoo.so newcode.c

Now, libfoo.so forms Ur new lib.
# dump -Lv libfoo.so
will show :
[1] NEEDED libfoo.so
[2] NEEDED libc.so.1

I guess same thing can be used for libc.so as well.

Buttt.. /sbin/init is supposed to be statically linked.
It shows -
It has a dependence on /usr/lib/libdl.so
 

The LC_MONETARY-probl was solved within appln-scripts itself.
 

*Oops* Sorry if I screwed up the Revision control part of it. ie libfoo.so libfoo.so.1 and 2s and 3s etc
Moreover, sometimes gcc may cry about the redifinition of the functions in the dynamic lib. I need to dig into the ld/gcc s
options.. so that symbols defined first override the symbols defined later.
 

No cp will work in single user mode, but a proc is using a library, you'll be unable to cp.

HINT: You need to duplicate the inode information, not by creating it, by but referencing to it!!
 

LC_MONETETARY:: Glad to hear that. Hey that hint was very close.
 

You meant to create a hard link. RIGHT??

Ok. It was very interesting.
 

Exactly my point. But do not use the regular link. There is a static /etc/link, use that. If you use regular link you will render
the link useless after moving the especially libc.2

So..

/etc/link libc.2 libc.2.old
rm libc.2
/etc/link libc.2.new libc.2

This will even patch a running program. Never knew of this /etc/link business at all.

Goodie.
 

Can't we update the same lib using some ld / cc option?
Earlier what I meant was of creating a new lib libnewfoo.so file that has the dependencies on the earlier lib ie libfoo.so .

How about appending the newcode.o onto the old lib libfoo.so and retaining the name and the inode no as libfoo.so
The executable will dlopen-> dlclose() the lib nad the next time it dlopen()s it.. the newcode takes effect thus patching the
(w)hole stuff.
 

HP-UX internals demand that shared executable not being used when changed.

And generally for any .so/.sl or shared object you cannot replace any .o's inside, since it is in ELF .so format and is not a
archive. It is as good as an executable with it's own linkage table, data/BSS etc, so you don't have distinction to achieve
replacement as in archive libs.

Have fun

Quick Links:
Do you have a UNIX Question?

Unix Home: Unix System Administration Hints and Tips