Re: Changing libraries when they are already in process space

On 6 Jun 2007, Josef Moellers said:

sandy wrote:
Hi,
I would need some information on unix system libraries. An application
is running in a machine and using some COMMON libraries like, libstdc+
+ and libodbc. This library is already loaded in application's process
space.
If i use RPM installer or any other program which replaces COMMON
libraries, what happens to the process already running.

It keeps the old file in memory. New processes loading the shared
object will get the new one. It is just not feasable to replace code
and data from within a process' address space.

Not without the cooperation of that process, at least, and even then
it's horribly difficult.

Does it
actually allows to replace library?

Why shouldn't it? Besides, if you upgrade to a new version, you'll
usually get a new file name as well: /usr/lib/libstdc++.so.5.0.6 will
still be there if you install /usr/lib/libstdc++.so.5.0.7, only the
symbolic link /usr/lib/libstdc++.so.5 will be set to the new file.

That is, it doesn't allow replacement of a running binary. You can
unlink (`delete') the library and put another file of the same name
there, and this is what normally happens: in that case, because the old
library is still being held open by all those things using it, it does
not actually get freed off the filesystem until all the processes
holding it open have closed it. (These are, of course, standard Unix
semantics.)

*Overwriting* of a running executable *is* blocked, with the write()
failing with -ETXTBSY (at one point this wasn't true for shared
libraries and other executable mmap()s, and overwriting them would be
apt to cause major crahses of lots of processes all at once: you'll
pardon me if I don't test this *just* now).

Init is statically linked, so there's no need to restart
that, which would require a reboot.

Not so!

linux-gate.so.1 => (0xb7f47000)
libc.so.6 => /lib/libc.so.6 (0x4332d000)
/lib/ld-linux.so.2 (0x4330f000)

In fact, telinit even has an option `q' which causes init to re-exec()
itself, specifically so that it can pick up new shared libraries
(generally after a libc upgrade).

However, it is often easier to reboot than to restart various services.

Certainly if you upgrade things like libc and the new copy has security
fixes in it or something, sure.

--
`... in the sense that dragons logically follow evolution so they would
be able to wield metal.' --- Kenneth Eng's colourless green ideas sleep
furiously
.

Relevant Pages

  • Re: Common Lisp from a Unix perspective - barriers to using CL
    ... Common Lisp regexp libraries. ... response is likely to encourage people to try out Common Lisp? ... The problem is that there are very few people invested in the success of ...
    (comp.lang.lisp)
  • Re: modular programming in Forth
    ... must be problem domains where constraining the choice of solutions in ... enough in application programming that it's worth while solving in one ... But the common root may be a habit of thinking of that as necessarily ... approach across different libraries, ... ...
    (comp.lang.forth)
  • Re: Popularity of programming languages
    ... > lots of useful libraries written in pure CL by now. ... drive a search engine doesn't mean that Common Lisp is doomed. ...
    (comp.lang.lisp)
  • Re: Is a new CL standard possible?
    ... Every language at its core is a set of rules that answer how data is ... In order to do _real_ work, libraries are needed ... Common Lisp would add so much overnight, ... Imagine if downloading Python meant that all you got were the basic ...
    (comp.lang.lisp)
  • Re: Unified Ada library
    ... Unified Ada Library. ... > are to limited to replace the more advanced component libraries. ... and coordinating with others to maintain a common ... >> developers were to collect libraries from all over the Web and integrate ...
    (comp.lang.ada)