Unexpected unloading behavior of provider in SFCB

<[email protected]>
Newsgroups gmane.network.open-pegasus.general
Message-ID <[email protected]>
Hi all,

I am seeing some unexpected unloading behaviour of CMPI based C providers in SFCB. It is expected that if any provider has subscriptions lying in the interop/implementation namspace OR on MI cleanup routeins "CMPI_RC_NEVER_UNLOAD" being returned to the cimom, then the provider won't unload. But after doing all these my provider is still getting unloaded after some unspecific (random) amount of time/calls. I have even extended the unload time property in /etc/sfcb/sfcb.cfg to 12000, which I think is more than enough.

To confirm whether the provider is unloaded due to a seg fault, I had set "ulimit -c unlimited" in /etc/init.d/sfcbd script, but did not get any zdump core files. To further convince myself, I wrote a very basic CMPI based C provider, with only the interfaces returning success. This provider had no chance of getting a seg fault ever, but still it won't remain loaded :(.

My query is that, is there any known issues regaring C providers in sfcb related to this unloading pattern? Am I missing anything which could possibly prevent my provider from unloading?

Thanks in advance,
Biswaparatap. 

"Education is not preparation for life; education is life itself"
Let's educate someone today !!


Please do not print this email unless it is absolutely necessary. 

The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. 

www.wipro.com
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.