Ken Jennings wrote:
I assume you're discussing a shared library linked by the system at run time, not an object library linked at compile time.
Correct.
My understanding is that if the update is overwriting the library in use you would see the process core dump, because the file is memory mapped to the process.
That doesn't happen. I can update the library without the process noticing at all.
I'm also assuming you're not seeing the process core dump, because the update renames or unlinks the share library file in use before installing the new library.
Ah, possible. But all I do is an scp from a development system into the target system - if I attempt to update a running binary, I get "text file busy", but not for a library.
2) (Another assumption -- You control the process source code and can modify and build it.)
Yes, I can.
Instead of letting the system dynamic link the library change the process to link the library itself [ using dlopen() ] and monitor changes> to the file [ using stat() ]. When the file changes then the process would dlclose() the library and then reopen it and then the process would need to reattach itself to the library's symbols with dlsym().
I like that - presumably I would need to change something in my build such that I don't need to link to this library?
I've been brainstorming a C library at work (for Solaris) during my "copious spare time" to do option 2 more or less automatically for a process, so that we can do updates in production without bringing down an application.
I'm not too concerned with the downtime, it's more of a management thing. I have this daemon running on N geographically separate systems, and it would be nice to have the restart done automatically. Thanks for all your input Ken - much appreciated. /Per Jessen, Zürich