Hello Ben, On Tue, 2023-02-07 at 18:32 -0600, Benjamin Marzinski wrote: > If "multipath -u" fails, udev doesn't import any values from the > program. This means that multipath.rules will continue to use the > values > for DM_MULTIPATH_DEVICE_PATH and FIND_MULTIPATHS_WAIT_UNTIL that it > has > already imported from the database. This is the correct thing to do > for > every case except the MAYBE case for "find_multipaths smart". In that > case, DM_MULTIPATH_DEVICE_PATH will be set to 1, and the rules will > assume that the device has been definitively claimed. > > In this case, we know that the device shouldn't have been claimed > before, but we don't know if it should be claimed now, or if we have > hit > the timeout and it should be released, since we didn't get any > information from multipath. The safest thing to do is assume that > this > was the timeout, and the device shouldn't be claimed. The only time > when > this could be the wrong answer is when we first see a new multipath > device, and it could only cause problems if there is metadata on the > device that will cause it to get autoassembled by something else, > before > multipathd can autoassemble it. If we assume that it is a multipath > device, or we assume that this wasn't actually the timeout uevent, we > can keep a necessary device from getting released to the reset of the > system. > > Signed-off-by: Benjamin Marzinski <bmarzins@xxxxxxxxxx> We have this code in check_path_valid(): /* * multipath -u must exit with status 0, otherwise udev won't * import its output. */ if (!is_uevent && r == PATH_IS_NOT_VALID) r = RTVL_FAIL; else r = RTVL_OK; AFAICS about the only condition I can imagine in which "multipath -u" would return an exit status other than 0 would be failure of init_config(). If that's the case you're concerned about, the issue might be easier to fix in main.c directly. Regards, Martin -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
