> At this point, has multipathd retested the paths, or are you hoping that > the loop up event will trigger the multipathd? The behaviour I was expecting was for multipathd to prediodically poll all the paths, find that the failed paths were now good, and activate them. Looking in the deamon log files, multipathd catches when the path fails, but never notices when they come back. May 28 15:17:17 ia64g /usr/bin/multipathd: [event thread] event caught May 28 15:17:17 ia64g /usr/bin/multipathd: [event thread] refresh devmaps list May 28 15:17:17 ia64g /usr/bin/multipathd: [event thread] refresh failpaths list May 28 15:17:19 ia64g /usr/bin/multipathd: [checker thread] reconfigure 600508b40001045d0001c00006de0000 May 28 15:17:49 ia64g last message repeated 6 times May 28 15:18:49 ia64g last message repeated 12 times May 28 15:18:59 ia64g last message repeated 2 times etc > is possible today (see below), but once the multipathd tests the paths > they should readded to the multipath device. Does the retesting part not > work too? Correct the retesting does not work. I'm not sure where it is falling over; if looking at the san switch, the machine is definately sending packets out onto both fabric aprox. every 5 seconds. My guess is that activity is multipathd probing the paths. Guy -- Guy Coates, Informatics System Group The Wellcome Trust Sanger Institute, Hinxton, Cambridge, CB10 1SA, UK Tel: +44 (0)1223 834244 ex 7199