Re: Performance hit: symlinks
Keith G. Murphy wrote:
> Karsten M. Self wrote:
>
>>
>> By using symlinks, filehandle open to the old library will continue
>> to work while they are open.
>
>
> Are you *sure* this is a reason to use symlinks? I really thought
> old libraries stuck around until all filehandles to them were closed
> anyway.
>
> I thought it was more that you don't want to just start overwriting
> the old library directly, because *new* opens by other programs might
> have a problem until the copy finishes. On the other hand, maybe the
> overwrite would try to do an exclusive lock on the library, and not
> work while the library was open by other programs. I'm not inclined
> to try on my system. :-)
>
OK, you know I had to check it out. :-)
I experimented with /usr/lib/libpcap.so.0.6.2, which is not used by much
else on my system besides invocations of tcpdump (I hoped).
# ls libpcap* -l
-rw-r--r-- 1 root root libpcap.so.0.6.2
lrwxrwxrwx 1 root root libpcap.so.0->libpcap.so.0.6.2
# mv libpcap.so.0.6.2 libpcap.sav
tcpdump bombed because it couldn't find the library
# cp libpcap.sav libpcap.so.0.6.2
tcpdump worked OK
# rm libpcap.so.0
tcpdump bombed because it couldn't find the library
Nothing suprising so far.
# ln -s libpcap.so.0.6.2 libpcap.so.0
tcpdump runs fine again
What if I delete the library out from under a running tcpdump?
I ran my tcpdump and ctrl/S'ed it.
# rm libpcap.so.0.6.2
#
When I ctrl/Q'ed my running tcpdump, it completed just fine, which
supports my contention that the library is not deleted until all open
channels against it are closed. So using symlinks to avoid *removing*
the library is unnecessary.
# cp libpcap.sav libpcap.so.0.6.2
tcpdump runs fine again
What if I directly overwrite the library while tcpdump is running?
I ran my tcpdump and ctrl/S'ed it.
# cp libpcap.sav libpcap.so.0.6.2
When I ctrl/Q'ed my running tcpdump, it segfaulted!
Thus, I would say that the main reason to use symlinks when updating
libraries is that directly overwriting them causes major problems in
programs that have them open.
On second reading, this doesn't contradict what Karsten said, except I
don't see what the "atomicity" issue has to do with the issue of open
channels to the library in running programs.
Reply to: