Reported by: Guenther Brunthaler <firstname.lastname@example.org>;
Date: Sat, 20 Jan 2018 07:03:01 UTC;
Maintainer for vde2 is (unknown).
View this report as an mbox folder.
vde2. Full text available.
Guenther Brunthaler <email@example.com>:
firstname.lastname@example.org. Full text available.
From: Guenther Brunthaler <email@example.com> Subject: vde2: ifup plugin-stanza "vde2-plug" does not capture correct PID To: Devuan Bug Tracking System <firstname.lastname@example.org> Date: Sat, 20 Jan 2018 07:43:10 +0100 Package: vde2 Version: 2.3.2+r586-1 Severity: normal X-Debbugs-Cc: email@example.com 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 --exec $DPIPE -- $VDE_PLUG -g $GROUP -m 660 $CTLDIR = "$@" line into --exec $DPIPE -- "$@" = $VDE_PLUG -g $GROUP -m 660 $CTLDIR It turns out that the order of commands in dpipe is not irrelevant if the processes have different lifetimes. In such a case, the first command must be that with the longer lifetime, because dpipe will exec itself into that command, and its PID will be used by the caller of dpipe in order to terminate the pipeline later. -- System Information: Distributor ID: Devuan Description: Devuan GNU/Linux 1.0 (jessie) Release: 1.0 Codename: jessie Architecture: x86_64 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages vde2 depends on: ii adduser 3.113+nmu3 ii libc6 2.19-18+deb8u10 ii libpcap0.8 1.6.2-2 ii libvde0 2.3.2+r586-1 ii libvdeplug2 2.3.2+r586-1 vde2 recommends no packages. Versions of packages vde2 suggests: pn qemu <none> ii qemu-kvm 1:2.1+dfsg-12+deb8u6 ii vde2-cryptcab 2.3.2+r586-1 -- no debconf information
firstname.lastname@example.org. Full text available.