Well, my patch is at the end, leaving the rm in place. However, I could examine looking at using slibclean (shared library clean) - which is the program to remove outstanding (loaded, but not active) shared library code.
And - thinking through - if the remove is not done, and the .so file is not copied - the old .so copy remains - but you "expect" it to be updated. For these cases, rather than remove I would move the file to a dated pid (mv $TARGET $TARGET.$today.$$) - and if all fails move it back, otherwise remove (and slibclean again, for certainty). I have been quite perturbed in the past when I was installing "live" and it failed. My previous installed php was now broken. re: slibclean - the program has been around "forever" - at least since since AIX 4.X (starting in 1994-1995). No idea if it has been tested before for php and/or instdso.sh. However, to work, slibclean still needs the previous version to be stopped. I assume that is the same as unlink() of a file - the inode is not actually cleared until both the link count is 0 and there are no open connections to the inode. That is, I do not expect that slibclean is removing "open" routines - but it might. Finally, In my case, as I am "packaging" to a temp directory (installing to $INSTALL_ROOT/*) this should never be an issue. The other issue I run into is the -a argument - because when packaging ( On Sun, May 4, 2014 at 11:54 PM, Victor J. Orlikowski < victor.j.orlikow...@alumni.duke.edu> wrote: > On May 4, 2014, at 5:46 PM, Victor J. Orlikowski < > victor.j.orlikow...@alumni.duke.edu> wrote: > > My only comment to that would be: has AIX resolved the issue wherein it is > required that the file backing a previously-loaded module has to be rm’d, > in order to ensure that the in-memory copy is released? > > > Responding to myself, after a quick consult with the Googlemonster: > Seems you need to call a utility called slibclean, to remove the memory > references to the shared object. > > And, sometimes, that still doesn’t work - so you have to rm it anyway. :/ > > Anyhoo - it seems to me that the real problem is that we’re deleting the > newly generated .so, rather than the *target* into which we’re trying to > copy (which is what would be what has the in-memory references). > > Best, > Victor > -- > Victor J. Orlikowski <> victor.j.orlikow...@alumni.duke.edu > >
