> I was looking at the multipath/main.c source file. I notice at the > beginning, it has code: > > /* > * Don't run in parallel > */ ... > > This is racy. This isn't sufficient to guarantee that two multipath > binaries will never run concurrently. The multipathd could just happen > to begin execution at the same instant an administrator runs multipath. > Both could find the RUN file not present. Both would then do the > open(), and both would succeed. > Yes, I was aware of that but couldn't justify myself the need to serialize more strictly. In other words, I was lazy to do better. > Plus, you have the issue of removing this file when multipath exits. > If multipath should exit abnormally (due to an exception for example), > it leaves behind the RUN file. > Point taken : this is effectively a pain to keep track of this runfile > I suggest doing something like: > ... ok merged > > There should be no need to remove the RUN file. If it already exists > when entering this code, there's no harm done. If the binary exits > abnormally, the record lock will be removed as part of the kernel's > exit handling. > ok, done > How does this sound to you? > seems good, thanks. regards, cvaroqui
