Dear Maintainer,


Preliminary remark: Even though I am using Devuan rather then Debian, I
have verified that the problem still exists in the current "stretch"
version (vde2_2.3.2+r586-2.1_amd64.deb) of the package.

"ifup" for a virtual VDE2 tun/tap plug records an incorrect PID for the
vde_plug2tap process in the pidfile, and "ifdown" will therefore not be
able to shut it down.

As a consequence, the vde_plug2tap process keeps running, wasting
resources, and the tun/tap interface remains still visible with
ifconfig -a, even though it will have been deconfigured.

The problem arises when using ifup/ifdown to configure additional
tun/tap interfaces for a VDE2 switch.

Such additional network interfaces are necessary when binding normal
applications running on the local box (and not in VM guests) to
different VLANs managed by the same virtual VDE2 switch.

For instance, when adding the following /etc/network/interfaces entry

iface ethsmb inet static
         vde2-plug vde_plug2tap -p 5 -s /var/run/vde2/ethvm.ctl ethsmb
         address 10.35.43.113
         netmask 255.255.0.0

then "ifup ethsmb" makes a new network interface "ethsmb" appear which
is connected to port 5 on the virtual switch (which itself manages
another network interface "ethvm").

"ifdown ethsmb" should make the new interface go away, but it won't.

The problem is located in plug-in script /etc/network/if-pre-up.d/vde2
from the package.

This script contains a command

start-stop-daemon --start --quiet --pidfile $PIDFILE \
--make-pidfile --background \
--exec $DPIPE -- $VDE_PLUG -g $GROUP -m 660 $CTLDIR = "$@"

It seems dpipe double-forks under certain situations, at least in this
case, and so the --background option of start-stop-daemon has no effect
and the --pidfile captures the wrong PID.

This can also be verified by just running the resulting dpipe command
manually without the "start-stop-daemon": It returns immediately,
obviously forking the processes into the background, and $! does *not*
contain a valid process ID.

I have also figured out what needs to be changed in order to make
everything work as intended again: Just exchange the order of commands
connected with dpipe. In other words, change the