Closed datamattsson closed 1 year ago
I'm pretty sure that issue was introduced with:
cd1756629762393da4ebb50a22b2badab8446369 multipathd: use strbuf in cli_handler functions
and it has been fixed upstream with:
95814552235e338f97fdf2b32413f928710a0ac4 libmultipath: fix 'show paths format' failure
I know this fix is in the Fedora Rawhide device-mapper-multipath build, but I'm not sure what other releases it may be in.
Well to be more precise, cd1756629762393da4ebb50a22b2badab8446369 was the commit that made multipathd stop returning failure when trying to show the checker of orphan paths. I don't think multipathd ever correctly showed an orphan path if the "%c" format wildcard was used, until 95814552235e338f97fdf2b32413f928710a0ac4
Thank you so much @bmarzins for the background information. I wonder why I couldn't find these.
In newer versions of multipath (v0.8.7 and above) the
multipathd show paths format
command fails silently when the path checker is asked for on orphaned entries:Replacing the
%c
with a%z
:The above example is using multipath-tools v0.8.8 (03/12, 2021) stock from Ubuntu 22.04.1 but I've reproduced this on
The devices it fails with are either iSCSI or FC.
SLES 15 SP3 uses multipath-tools v0.8.5 (11/09, 2020) and does not exhibit this problem and I've tested as low as multipath-tools v0.4.9 (05/33, 2016) on CentOS 7, which does not have this issue either.
This issue has caused a lot of angst mainly because the failed command return code is
0
as failures occurs in silence in our tools and libraries.