multipathd queue_if_no_path And no_path_retry Explained

If you configure your multipath device to use “no_path_retry N” explicitly you may still see queue_if_no_path in multipath -ll output as a listed feature:

$ multipath -ll
mpathc (3600601608de04200c24aed5886c9b28e) dm-3 DGC ,VRAID 
size=2.0T features='2 queue_if_no_path retain_attached_hw_handler' hwhandler='1 alua' wp=rw

Does it mean the no_path_retry setting was not applied at all? According to multipath.conf man page both, queue_if_no_path and no_path_retry, are identical:

Queue IO if no path is active; identical to the no_path_retry keyword.

But which policy is in use: queue or fail?

Unfortunately, it was not made clear in documentation but if no_path_retry is set to anything but fail, you will see queue_if_no_path in multipath -ll output.

If no_retry_path was set to fail, the output would look like this:

$ multipath -ll 
mpathc (3600601608de04200c24aed5886c9b28e) dm-3 DGC ,VRAID 
size=2.0T features='1 retain_attached_hw_handler' hwhandler='1 alua' wp=rw

This means, that yes, “no_path_retry N” is actually used as a path failure handling policy but queue_if_no_path is displayed instead anyway.

Also, no_path_retry is recommended over queue_if_no_path. Straight from multipath.conf man page:

The usage of queue_if_no_path option can lead to D state processes being hung and not killable in situations where all the paths to the LUN go offline. It is advisable to use the no_path_retry option instead.

If you want to set no_path_retry option explicitly, in an attempt to make sure that failed I/O requests are not queuing up and waiting patiently for a path to come back online, you need to add to your /etc/multipath.conf this:

devices {
 device {
 vendor "DGC" 
 product "VRAID" 
 no_path_retry fail

Obviously, you need to match your vendor and product.

Another way to do the same is to use dmsetup command. Assuming you have three different multipath devices: mpatha, mpathb and mpathc.

$ dmsetup message mpatha 0 "fail_if_no_path" 
$ dmsetup message mpathb 0 "fail_if_no_path" 
$ dmsetup message mpathc 0 "fail_if_no_path"

If you have a compatible device it will be most likely configured automatically by multipathd. If that’s the case your multipath.conf would look not very different from this real-life example:

$ grep -v ^# /etc/multipath.conf                                                                                                                                                                                                  
defaults {
        user_friendly_names yes
        find_multipaths yes
devices {
        device {
                vendor                  "DGC" 
                product                 "VRAID" 
                no_path_retry           fail

blacklist {

To apply your changes just run these commands:

$ multipath -d
$ multipath -v2
$ multipathd reconfigure

To verify the changes, look up runtime configuration and look for no_path_retry:

$ multipathd show config

Using snap Application Aliases

If you run snap and snapd <= 2.25 this is how you can set up aliases for snap applications in your snapcraft.yml:

      command: usr/bin/wrapper-psql
      aliases: [psql]
      plugs: [network]

Build and install your snap package. Then you need to enable all such aliases manually as the user you plan to run your application as. Normally, it is an unprivileged user.

Before you can enable an alias, though, you need to make sure you’re logged in:

$ sudo snap login
Email address: *****
Password of "*****": 
Login successful

Otherwise you won’t be able to create aliases as an unprivileged user (only as root via sudo.)

Enable your alias:

$ snap alias postgresql93.psql psql
 - postgresql93.psql as psql

Verify it was created:

$ snap aliases
Command Alias Notes
postgresql93.psql psql manual

Use the alias:

$ whereis psql
psql: /snap/bin/psql
$ psql --version
psql (PostgreSQL) 9.3.17

Remove your alias:

$ snap unalias psql
 - postgresql93.psql as psql

Aliases are unique:

$ snap alias postgresql94.psql psql
error: cannot perform the following tasks:
- Setup manual alias "psql" => "psql" for snap "postgresql94" (cannot enable alias "psql" for "postgresql94", already enabled for "postgresql93")

They can also be enabled automatically upon installation of a snap package when it is installed from a store.

Note, in snap version => 2.26 this behavior will change.

Read more about aliases and upcoming changes here.