All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Reinecke <hare@suse.de>
To: dm-devel@redhat.com
Subject: Re: Chicken and egg problem with multipath-tools
Date: Mon, 04 Mar 2013 07:54:41 +0100	[thread overview]
Message-ID: <51344531.90705@suse.de> (raw)
In-Reply-To: <1362220999.44153.YahooMailClassic@web126202.mail.ne1.yahoo.com>

On 03/02/2013 11:43 AM, Andrei B. wrote:
> Hi,
>
> I've been trying to install multipath-tools on a couple of linux servers with FC storage that I work with.
> They run Linux Slackware.
> I've built from source, created an installable package (Slackware style) and deployed it.
>
> I have discovered the following problem (chicken and egg style):
>
> - multipathd, AFAIK, should start before LVM, because if several volumes need be assembled by LVM,
 > they should exist before LVM starts.
> - multipathd, AFAIK, should start before any service that has it's data stored on the remote storage.
>
> I am not familiar [enough] with the inner workings of the startup sequence on redhat/debian like systems.
> Slackware's startup sequence is much simpler and I placed multipathd in file rc.S (which is the first
 > one called by init) right before LVM.
>
> And here lies the chicken-egg problem. At this point, only the root filesystem is mounted and
 > it is mounted read-only. It is the correct and proper startup 
sequence in Slackware. Filesystems
 > are checked for errors after LVM starts and then root is 
remounted read-write and the rest
 > of the filesystems are mounted.
>
> The problem is that multipathd wants to create a PID file under /var (which is at this time readonly).
 > This fails and multipathd fails to start.
> It took me a lot of testing and reboots until I managed to determine this is the actual problem.
>
Hmm. Why? multipathd can happily live without a PID file; SUSE has 
been doing this for years (for precisely the same reason).
Check the SUSE init scripts.

> The stop-gap solution I have found, so far, is to load dm-multipath module and run multipath -v0
> before LVM, thus creating the multipath devices, then later, after the filesystems are remounted
 > rw, start multipathd.
>
Bah.
Just start multipathd without creating a pid file.
Then you can check if multipathd runs via the multipathd CLI.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke		      zSeries & Storage
hare@suse.de			      +49 911 74053 688
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg)

  parent reply	other threads:[~2013-03-04  6:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-02 10:43 Chicken and egg problem with multipath-tools Andrei B.
2013-03-03 11:42 ` Gabriel de Perthuis
2013-03-03 21:01   ` Andrei B
2013-03-04 10:49     ` Bryn M. Reeves
2013-03-04  6:54 ` Hannes Reinecke [this message]
2013-03-04 11:00   ` Andrei B.
2013-03-04 11:13     ` Hannes Reinecke
2013-03-04 11:27       ` Bryn M. Reeves
2013-03-04 10:54 ` Bryn M. Reeves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51344531.90705@suse.de \
    --to=hare@suse.de \
    --cc=dm-devel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.