Comment 18 for bug 1670811

Hi Christian,

> > Can you please elaborate a bit more on that, for my own education?

Upfront, thanks for the explanation. It really helped to think a bit
more on the code and go figure out a few things.

I'm writing up an explanation below of why I still think it cannot
happen. And it's _not_ that I want to insist in making my point -- because
actually we don't even need that anymore w/ the much simpler/elegant
fix of changing the /var/run & /run paths :) -- it's more of I liked
to go check it out in the code.

> pid="$(pidof multipathd)"
> # lets assume it gets pid 1001 being the current main PID and there are
> three sibling processes of a sort of multipath-helper binary with pids:
> 1002, 1003, 1004

AFAIK, multipathd only spawns threads (with same PID as parent), but
not other processes (ie, different PIDs). There only point with fork()
calls are in daemonize()'ing the multipathd main() into a child().

After that, only one PID exists (despite several threads running, e.g.,
uevent listener, path checkers).

We can verify that, as with a running/functinal multipathd there's only
a single process running, but all the path checking/uevent listening is
going on all the time.

> out="$(/sbin/multipathd -k'shutdown')"
> # here the shutdown might send signals to all, and helpers 1002, 1003
> # But due to an error on terminating 1004 it sends back to its parent that
> it has to reload

Even considering the PIDs could be different (which doesn't seem to be the
case), the child() loop requires just one evaluation of (running_state != DAEMON_SHUTDOWN)
to get out of the loop in which it could process any other events,
and goes right into tearing down the threads and the process.

And the only place where it could get a different PID would be daemonize()
which has fork() calls, but it's only called from main().

> # main 1001 re-execs itself and 1001 goes away but a new 1005 appears and
> spawns two new helpers 1006, 1007.
> # now you end up with main 1005, helper 1004, 1006, 1007
> # shutdown will reply some error to "out" but you will not know exactly

> This is just a case for such an issue - and as I said only theoretical, but
> essentially it is a chance to use an out of date value.

Sure, I understand. It's been a great exercise analyzing it. Thanks.