[dm-devel] [PATCH 13/13] multipathd: no_map_shutdown option

[Christophe Varoqui]

Hi,

To my knowledge, systemd has not been integrated in all distributions.
It would be nice not to break the build of multipath-tools on those
environments.

The current patchset breaks the build on non-systemd systems as soon as
patch 06/13.
I can apply the patchset from 01/13 to 05/13 included, and let you refactor
the systemd integration proper in a new series.

Is that ok with you ?

Best regards,
Christophe Varoqui
www.opensvc.com



On Fri, Nov 22, 2013 at 10:12 AM, Hannes Reinecke <hare at suse.de> wrote:

> On 11/22/2013 12:17 AM, Benjamin Marzinski wrote:
> > I don't understand this option?  When I played around with it, it seems
> > like it only causes problems.  For instance.  If I remove all the
> > multipath devices with "multipath -F", then multipathd stops.
> > Incidentally, this pisses off the watchdog timer.
> >
> > This pops up in /var/log/messages
> >
> > Nov 21 11:04:05 ask-08 systemd[1]: multipathd.service watchdog timeout!
> > Nov 21 11:04:05 ask-08 systemd[1]: Unit multipathd.service entered
> > failed state
> >
> > and checking the status shows the service as failed.
> >
> > # service multipathd status
> > multipathd.service - Device-Mapper Multipath Device Controller
> >    Loaded: loaded (/usr/lib/systemd/system/multipathd.service; enabled)
> >    Active: failed (Result: watchdog) since Thu 2013-11-21 11:04:00 CST;
> 3min 25s ago
> >   Process: 22687 ExecStart=/sbin/multipathd -d -s -n (code=exited,
> status=0/SUCCESS)
> >    Status: "shutdown"
> >
> Yeah, because I forgot to set the exit status via sd_notify.
> I'll be updating a patchset to include that.
>
> > But the bigger issue is that multipathd is now stopped, and running
> > "multipath" doesn't bring it back again.
>
> Ah. Yes, you are absolutely right, of course.
> I've forgot about this.
>
> > You will create the multipath
> > devices, but nothing will be monitoring them.  The same thing happens if
> > the multipathd service is started before the any multipathable devices
> > are discovered.  It starts up and then shuts back down (again tripping
> > the watchdog timer). When those devices finally get discovered, there is
> > nothing to listening for the uevents, so no multipath devices ever get
> > created.
> >
> > I must be missing something here.
> >
> No, it's actually true what you've said.
> Multipathd can only listen to events if it's started.
> But that's precisely what systemd is for, right?
> Starting a service when something is written onto a socket?
> Guess it need some more work here.
>
> But I could finally do my long-term project of merging
> multipath and multipathd to share the same codebase, with
> multipath just using the multipathd CLI and having no logic
> on it's own.
>
> But in the light of this, this patch is indeed not working
> as designed, and should not be applied as of now.
>
> Which doesn't affect the other parts in the series, which
> _definitely_ should be applied.
> Christophe, how to proceed?
>
> Do you need a new patchset with the last patch removed,
> or are you fine with the current one and just not applying
> the last patch?
>
> Cheers,
>
> Hannes
> --
> Dr. Hannes Reinecke                   zSeries & Storage
> hare at 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)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20131122/a9b424e9/attachment.htm>