Re: RHEL 6.5 shared library upgrade safety

[Loic Dachary <loic@dachary.org>]

[-- Attachment #1: Type: text/plain, Size: 1328 bytes --]



On 18/08/2014 17:17, Sage Weil wrote:
> On Mon, 18 Aug 2014, Loic Dachary wrote:
>> Hi Ceph,
>>
>> In RHEL 6.5, is the following scenario possible : 
>>
>> a) an OSD dlopen a shared library for erasure-code, 
>> b) the shared library file is replaced while the OSD is running, 
>> c) the OSD starts using the new file instead of the old one. 
>>
>> It seems unlikely but it would explain a weird stack trace at 
>> http://tracker.ceph.com/issues/9153#note-5 so I'm double checking ;-)
> 
> I think this is possible and likely.  We had similar problems with the 
> rados classes and eventually just made them load all available plugins on 
> startup (and also on demand in case one is installed later).
> 
> The simplest thing is probably to do that here as well...

This will not solve the upgrade problem for Firefly daemons which are are already running, unfortunately. Stopping the daemons while the package is being upgraded seems safer and more generic (see the other thread). Or are there issues with this approach ?

Cheers

> 
> sage
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
Loïc Dachary, Artisan Logiciel Libre


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 263 bytes --]