Bugzilla Bug 141832

I'm using the new baselayout to get a pppoe-connection. My /etc/conf.d/net:
config_ppp0=( "ppp" )
plugins_ppp0=( "pppoe" )
pppd_ppp0="defaultroute"
link_ppp0=( "eth1" )
username_ppp0=( "xxx" )

I've a program updating my dyndns-account, which is started by
/etc/ppp/ip-up.local and stopped by /etc/ppp/ip-up.local.

It's started without problems, but when I do a /etc/init.d/net.ppp0 stop it's
not stopped.
But: If I pull out the cable from the pppoe-modem, the connection drops, the
status of the /etc/init.d/net.ppp0 scripts gets inactive and the program is
stopped (=> the /etc/ppp/ip-down.local-Script is working!). After plugging the
cable in again the program is also started properly again...

A short search in /lib/rcscripts/net/pppd.sh lists me the following line which
stops the ppp-connection:
start-stop-daemon --stop --exec /usr/sbin/pppd --pidfile "${pidfile}"
When I manually stop the ppp-daemon with this command (by replacing
"${pidfile}" with /var/run/ppp-ppp0.pid), /etc/ppp/ip-up.local has also stopped
my dyndns-program!
Only if I stop it via /etc/init.d/net.ppp0 the script /etc/ppp/ip-down.local
seems not to be run.
It's not really important that this feature works for my dyndns-script, but I
have thought about some advanced routing, then it would become important...

I don't know why or how to resolv this "anomaly", maybe the ppp-connection is
set down or something like this before ppp is stopped, so that ppp doesn't run
etc/ppp/ip-down.local?!

It's reproducible on several machines, all running sys-apps/baselayout-1.12.1
and net-dialup/ppp-2.4.3-r16.
I've not tried if the problem exists with older versions of the packages.
Any more infos needed?

# emerge --info
Portage 2.1-r1 (default-linux/x86/2006.0, gcc-4.1.1, glibc-2.4-r3, 2.6.17.6
i686)
=================================================================
System uname: 2.6.17.6 i686 AMD Athlon(tm) XP 2500+
Gentoo Base System version 1.12.1
app-admin/eselect-compiler: [Not Present]
dev-lang/python:     2.4.3-r1
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r3
sys-devel/gcc-config: 1.3.13-r3
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=pentium3 -O2 -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo"
CXXFLAGS="-march=pentium3 -O2 -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distcc distlocks metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/"
LANG="de_DE.utf8"
LC_ALL="de_DE.utf8"
LDFLAGS="-Wl,-O1"
MAKEOPTS="-j 9"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude='/distfiles' --exclude='/local' --exclude='/packages'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://ftp.belnet.be/gentoo-portage"
USE="x86 bzip2 ipv6 libwww ncurses nls nptl perl python readline tcpd threads
unicode userlocales elibc_glibc input_devices_keyboard input_devices_mouse
input_devices_evdev kernel_linux userland_GNU"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LINGUAS,
PORTAGE_RSYNC_EXTRA_OPTS

I cannot replicate this on my simple pppoe setup - net-dial want to test?

I can confirm this behaviour. Since one of the last versions of baselayout,
ip-down.local isn't called anymore, though ip-up.local is. I do some "nasty"
things in ip-up/ip-down (i.e. VPN restart, etc.), so I know well if it is
called or not (SYSLOG entries are written).

But I haven't investigated further...

Looks like your turf, Roy.

Created an attachment (id=94227) [edit]
Only send the kill signal once

Patch to /lib/rcscripts/sh/rc-daemon.sh

As I cannot replicate this I have looked over the ppp source and it seems to
abort when >1 TERM signal is sent. This patch should fix.

(In reply to comment #4)
> Created an attachment (id=94227) [edit]
> Only send the kill signal once
> 
> Patch to /lib/rcscripts/sh/rc-daemon.sh
> 
> As I cannot replicate this I have looked over the ppp source and it seems to
> abort when >1 TERM signal is sent. This patch should fix.
> 

Yes, the patch fixes the problem. Thanks!

In SVN - will appear in baselayout-1.12.5

Fixed in 1.12.4-r4