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
On Fri, Nov 22, 2013 at 10:12 AM, Hannes Reinecke <hare@xxxxxxx> wrote:
On 11/22/2013 12:17 AM, Benjamin Marzinski wrote:Yeah, because I forgot to set the exit status via sd_notify.
> 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"
>
I'll be updating a patchset to include that.
Ah. Yes, you are absolutely right, of course.
> But the bigger issue is that multipathd is now stopped, and running
> "multipath" doesn't bring it back again.
I've forgot about this.
No, it's actually true what you've said.
> 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.
>
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@xxxxxxx +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)
-- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
