Weave reset fails

[MaximeHeckel]

When running /weave --local reset the command fails with the following error message:

Cannot find device "vethwepl14191@if322"

Looking at the weave code you always try to escape such error by adding || true at the end so we don't understand why we are stuck on that error.

[bboreham]

It would be helpful if you could run the weave script with debug info turned on, like this:

WEAVE_DEBUG=1 weave --local reset

However I can see at least one line that does not have || true, in this section:

    for LOCAL_IFNAME in $(ip link show | grep v${CONTAINER_IFNAME}pl | cut -d ' ' -f 2 | tr -d ':') ; do
        ip link del $LOCAL_IFNAME
    done

If the interface goes away for some other reason (e.g. the container exits) between the grep and the ip link del, then this will fail.

[MaximeHeckel]

As the weave command are run inside a binary we cannot run them manually like this.
The only workaround for that issue was to run /weave --local reset || true

The problem is that even when restarting weave we get the same error it was failing all the time. That interface wasn't even listed.

[bboreham]

OK, I think that @if322 may be to the problem - the interface shouldn't have that in its name.
Can you run ip link show on that machine and post the output?

[rade]

However I can see at least one line that does not have || true

That is certainly a bug and produces errors as seen by the OP. To reproduce, apply the patch

diff --git a/weave b/weave
index cc4a74a..3d8303e 100755
--- a/weave
+++ b/weave
@@ -1573,6 +1573,8 @@ case "$COMMAND" in
         conntrack -D -p udp --dport $PORT >/dev/null 2>&1 || true
         destroy_bridge
         for LOCAL_IFNAME in $(ip link show | grep v${CONTAINER_IFNAME}pl | cut 
+            docker rm -f foo >/dev/null || true
+            sleep 1
             ip link del $LOCAL_IFNAME
         done
         ;;

and then

$ weave launch
$ weave run --name=foo -ti ubuntu
$ weave reset
Cannot find device "vethwepl15633"

Note that the sleep is necessary; looks like there is some asynchrony somewhere.

I have raised #1364 for the weird interface name issue.