Please keep the bug in the recipient list On 05/23/2014 02:23 PM, Craig Barnes wrote:
>> I am assuming you are writing to the iscsi devices. If yes, then >> there's no reason for this to not fail. > > Yes I am writing to the iscsi device, the devices get removed as > expected, the service initiates a stop, only the kernel module unload > fails, I assume waiting for the service to finish or disks to sync. > > Is there any reason why this shouldn't successfully stop? > You are continuously pumping IO, and that's inflight, and now you want to deliberately unload the kernel module. It has abort because it is under use. >> Yes. THis one does not have any direct dependencies. As practice, I use >> modprobe. > > Ok, so > a) what is the worst thing that could happen using rmmod --wait In this case nothing. But I still see no reason to switch to rmmod. > b) is there a better way to do this? maybe wait 2 secs and try again > with modprobe -r? No. Then it becomes a never ending game. Why just 2 secs, why not 5 ? Your use case is invalid. It is like you have the mount point busy and you expect the kernel to unmount the file system. > c) if we fail at the module shouldn't we bring everything else back > again? > On stop) target, that's not expected. If it is restart), then yes. Which I guess gets covered in our current init script. Otherwise too, we do report that things failed. So any calling program should look for and honor that. >> Yes. That is the case. Look at conn.c in the sources. > > Sorry my c is a bit rusty and I am no kernel dev. But I understand and > appreciate your explanation. > > However I did find this... > http://sourceforge.net/p/iscsitarget/code/343/ > I need to verify that. I'm not very sure how it would really behave. What exactly is your requirement ? Do you want the init script to exit clean irrespective of the module state ? -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System
signature.asc
Description: OpenPGP digital signature