Christophe Varoqui wrote:
Hi Folks, Older versions of multipath-tools would always exit with status 0 (success) when flushing multipath device maps (-f/-F). This was never guaranteed but happened because the "r" local in multipath/main.c was used uninitialised in these code paths (by chance, it always lands on a freshly zeroed stack page, so although undefined the behaviour was pretty reliable). This was changed by commit 8497928514aa3df6d46f24d8d9b70b086e9fcfbd:Then by a9a6c71592d4e2271a38c3d334bee7cbce963cff. Does the upstream version works as you expect in this regard ?
Sorry - not sure how I missed that last week.
The alternative for -F seems to be to return 0 if all unused maps were flushed and 1 if there were unused maps that could not be flushed. This doesn't seem like a very likely occurrence, but maybe it should be handled separately?I guess the current implementation return r as the number failures.
It does, which seems a slightly strange thing to return - I don't see how it's useful as it's actually the number of device-mapper maps that we couldn't flush (sum of returns from dm_flush_map), i.e. the total number of maps that either weren't multipath, weren't unused etc :)
This will cause problems on systems that have 256 such maps since the exit status is truncated to 8-bits and we would falsely reported the status as zero.
It seems more useful to return an overall success/failure indication for these commands and would be more in-keeping with other similar tools and POSIX.
Regards, Bryn.