I've come across an issue where processes that load symlinked .so files crash if I update the
.so while the processes are still running.
I have long-running processes that load shared libraries (.so) when first starting and may end up using those shared libraries much later on when the process is running. The shared libraries that the processes load are actually symlinks to the real
.sos (to have all of the
.sos in a structured directory pertaining to each process). Occasionally I need to apply some fix and recompile the .so file, but I've seen that when I do this, some of the long-running processes will crash when accessing symbols from that .so that I updated.
From my understanding, if the processes loaded the actual .so instead of a symlink, I should not see this behavior because when I recompile the .so (which removes and recreates the .so file with a new inode), the inode for that old .so should still stay in existence until all of the processes that have it opened close it. I think the problem I'm seeing is due to the fact that the processes are opening the symlink instead of the target .so, so the long-running processes only hold onto the symlinks inode instead of the target
.sos inode. But I don't have enough information to confirm my theory is correct.
Is it true that the inode for a file will remain in existence until all processors have closed it? And does this apply for processes that mmap the file but don't keep a file descriptor open for it?
Does open/mmap of a symlink only keep track of the inode for the symlink? Or does it also prevent the O/S from destroying the target file's inode as well?