Root is on a multipathed device, multipathd can not be stopped

Latest response

Hi guys.

I am installing RH 5.8 booting from a HP SAS storage with multipath.. the server is a HP proliant..

 

there is a / partition, swap and /var all in the storage..

the issue is when I restart the server while the system stop all service one says ERROR... and the error is this:

root is on a multipathed device multipathd can not be stopped

I can restart the server and it will boot.. but I am not sure if this is a critical issue that could affect me in the future.. the server will be in production and the only reason for restart or shutdown will be a for a very critical failure...

I am trying to find information about this but I allways end in any page showing  the script which stop this service.. not sure if it is a bug or should I replace the original script with the one I found..

the other thing is if I update the system with yum update it wont boot with the new kernel.. I think I should rebuild the kernel image with mkinitrd.

If I run the command multipath -v0 or 1 2 it doesnt show anything..

any idea?

thanks in advance

 

Responses

With respect to shutting down the multpather service:

Shutting down multipathd would normally cause your dm-N dev-nodes to go away. Given that you're apparently accessing the root filesystem(s) via dm-N dev-node(s), it w/should really negatively impact your ability to stay running if the dm-N dev-nodes were to go away. Thus, it would likely be a Bad Thing™ if the system were to allow you to shut-down multipathd. That the system is preventing you from shutting down multipathd would thus be seen to be a Good Thing™ - and therefore not a critical issue that should negatively impact you.

The major downside of this configuration method is what you've already discovered: your default initial ramdisk may lack the hooks necessary to properly boot off of dm-N dev-nodes. The multipathd service normally starts after the initial ramdisk loads. You need to rebuild your initial ramdisk to include the the requisite multipath drivers so that the required dm-N dev-nodes are available when transitioning from the (non-multipathed) /boot filesystem to the root filesystems.

That said, properly-configured, when you apply patches, the associated automatic-running of mkinitrd should load the multipathd drivers into any newly-created initial ramdisk images. You should be able to do this by ensuring that the requisite module entries are placed into the INITRD_MODULES parameter in the /etc/sysconfig/kernel file.

 

Thanks for your help..

I am still I little confused:

Shutting down multipathd would normally cause your dm-N dev-nodes to go away. Given that you're apparently accessing the root filesystem(s) via dm-N dev-node(s), it w/should really negatively impact your ability to stay running if the dm-N dev-nodes were to go away. Thus, it would likely be a Bad Thing™ if the system were to allow you to shut-down multipathd. That the system is preventing you from shutting down multipathd would thus be seen to be a Good Thing™ - and therefore not a critical issue that should negatively impact you.

 

If  multipathd is shutdown then the dm-N nodes go away.  and that is a Bad thing.  But the error message I get is during restarting the server, so the fact that I get that message saying Multipathd "can not be stopped" is a good thing?. anyways if the system KILL multipathd process what could happen someday while trying to boot again?, could I get a kernel panic and the system unable to boot again?

so at the end I shouldnt worry about this message? 

We have only one / partition  and /var. So /boot is multphated  as well. Can this affect even more the system health?, should /boot in a non multiphated device?

While installing RedHat I used the parameter  linux mpath, so I could create mpath partitions during installing and NO after a basic installation and then configuring multipath.

 

That said, properly-configured, when you apply patches, the associated automatic-running of mkinitrd should load the multipathd drivers into any newly-created initial ramdisk images. You should be able to do this by ensuring that the requisite module entries are placed into the INITRD_MODULES parameter in the /etc/sysconfig/kernel file.

 

In this case if I recreate the ram disk, would this preven of getting the error message while shutting down the system?

and If after updating the system with yum update, it download a newer kernel version, I guess I should run mkinitrd with the new kernel version image and it should boot. right?

As I said, while installing redhat I used the linux mpath option, so how can I know with parameteres were given to the initial ramdisk? so I could recreate the new one with the same options in order to be able to boot with the new kernel?

Thanks. I appreciate your help.

> anyways if the system KILL multipathd process what could happen someday
> while trying to boot again?, could I get a kernel panic and the system unable
> to boot again? so at the end I shouldnt worry about this message?

It's akin to messages about not being able to unmount certain partitions because they're still busy when the `umount` operation hits. It's annoying to see but not fatal. Yanking critical device-paths out from under the kernel would result in the shutdown part of the reboot processing ending in a non-graceful way. This wouldn't necessarily prevent the system from successfully rebooting, but you'd not want to make a habit of terminating your shutdown in an ungraceful way.

> We have only one / partition and /var. So /boot is multphated as well. Can
> this affect even more the system health?, should /boot in a non multiphated
> device?

Err... "/boot" isn't generally done as anything other than a bare device (no LVM, no dm-multipath, etc.) - especially during stage 1 of the bootstrap process. It's possible you'd be remounting it as multipathed, but it would make little sense to do so.

> and If after updating the system with yum update, it download a newer
> kernel version, I guess I should run mkinitrd with the new kernel version
>image and it should boot. right?

When you do the yum update, if you've set up your system properly (see my prior response on how), the update process will properly remaked the initial ramdisk to include the appropriate multipath hooks. This should obviate the need to manually run mkinitrd.

Pulling the mkinitrd arguments from prior runs of that action is a bit more involved than this forum is optimized for relating. Basically, it comes down to uncompressing and dearchiving the initial ramdisk's components. There's a fairly decent number of Google results for the topic.

That said, tearing apart the previous initrd to figure out how to rebuild it is probably overkill. By default, initrd should rebuild the same way each time initrd is run. You'd have to explicitly tell initrd to build things differently in order to cause it to deviate from its prior behavior. Forcing it to include dm-multipath hooks is done as stated in my prior post.

All,

 

Multipathing /boot on a system that uses "SAN" boot is common practise.

multipathd not stopping during shutdown before all filesystems are unmounted on a "SAN" is standard behaviour.

In short:

 

Kind regards,

 

Jan Gerrit

Thank you so much both for your help.

Now I have everything more clear.

Again, thank you, I appreciate it.