On Thu, Mar 30, 2017 at 6:25 PM, Mauricio Faria de Oliveira < mauri...@linux.vnet.ibm.com> wrote: [...]
> And the whole shutdown is skipped in case 'multipathd -kshutdown' failed > and PID is null (as kill_stage does not progress into 1,2,3) > > +if [ "$out" = 'ok' ] \ > +|| ( [ -n "$pid" ] && /bin/kill -SIGINT $pid ) \ > +|| ( [ -n "$pid" ] && /bin/kill -SIGKILL $pid ); then > + kill_stage=1 > +fi > > Maybe I'm missing something in your point? > I think you are fine, I think I just expected the logic inverse. If there is no pid this is essentially being: => "check ok" || false || false And that should be fine - if none of that it does not go into stage 1 below. > Also there might be some theoretical cases where the > > +out="$(/sbin/multipathd -k'shutdown')" > > As a side effect could make the pid change, so please re-arrange the > pidof and the shutdown. > > I'm afraid I don't see that theoretical case happening. > Can you please elaborate a bit more on that, for my own education? > 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 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 # 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. By changing order you are at least a bit better off - only "a bit" as if you start to consider asynchronous behavior it gets worse again. In some sense juggling with pids is a bit like potential racy "use after free" and since we are sending kill signals we might at least close the minimal things we see. [... thanks for the great explanation that was following ...] Yeah I think the current case is safe, never the less IMHO reordering two lines can't hurt to not have a bug in it in 2022. I'd agree it is waste if it would be more effort than reordering two lines. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1670811 Title: Multipath services fails to start on Ubuntu 17.04 on boot and kdump (initramfs) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1670811/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
