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

[Hannes Reinecke]

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)