Ticket #129 (closed defect: fixed)
Opened 21 months ago
Last modified 20 months ago
can't restart/stop net.ppp0
Reported by: | anonymous | Owned by: | |
---|---|---|---|
Priority: | critical | Milestone: | |
Component: | rc | Version: | 0.4 |
Keywords: | Cc: | vaeth@mathematik.uni-wuerzburg.de, gurli@gurlinet.dk |
Description
After upgrading to 0.4.0
/etc/init.d/net.ppp0 restart
start-stop-daemon: /usr/sbin/pppd is already running
WARNING: net.ppp0 not under our control, aborting
process pppd is running, and I need to kill it manualy, only after this is possible to start net.ppp0.
/etc/init.d/net.ppp0 stop
Long waits and then fails to stop
Attachments
Change History
comment:2 Changed 20 months ago by polynomial-c@gmx.de
This was also reported as Gentoo bug. https://bugs.gentoo.org/251839
comment:3 Changed 20 months ago by roy
The may have been fixed in openrc-0.4.1 released today.
Is this correct?
comment:4 Changed 20 months ago by polynomial-c@gmx.de
No, openrc-0.4.1 still exhibits the same problem:
Igor:~ # /etc/init.d/net.ppp0 start
- Bringing up interface ppp0
- Starting pppd in ppp0... [ ok ]
- received address XX.XX.XX.XXX
- WARNING: net.ppp0 not under our control, aborting
Igor:~ # /etc/init.d/net.ppp0 stop
- Bringing down interface ppp0
- Stopping pppd on ppp0 [ !! ]
Igor:~ # ps -A | grep ppp
23023 ? 00:00:00 pppd
Igor:~ #
Changed 20 months ago by polynomial-c@gmx.de
- attachment openrc-0.4.1-pppd-send-sigterm.patch added
With this patch pppd gets killed again
comment:5 Changed 20 months ago by polynomial-c@gmx.de
I reported a similar problem to gentoo bugzilla: https://bugs.gentoo.org/251728 for app-admin/sysklogd's init script.
Is it possible that somehow the --retry switch changes the signal, start-stop-daemon sends to processes on stop? Because I always see s-s-d emitting signal 0 when using the --retry switch...
comment:6 Changed 20 months ago by vaeth@mathematik.uni-wuerzburg.de
Indeed, if I interpret start-stop-daemon.c correctly, the default value sig=0 is used when the -R option is met without (or before) the -s option: This sets the signal sig(=0) to the schedule list with parse_signal(), and the test {{{
if (!TAILQ_FIRST(&schedule)) {
}}} in line 963 will then avoid that any -K option or any later -s option takes any effect on the schedule list. It appears that a solution would be to postpone the call of parse_schedule to line 962. (Of course optarg has to be saved, and the call must be outside of the scope of the if(stop||sig) test).
Changed 20 months ago by vaeth@mathematik.uni-wuerzburg.de
- attachment openrc-0.4.1-start-stop-daemon.patch added
Patch for start-stop-daemon.c to postpone parse_schedule() after option parsing
comment:7 Changed 20 months ago by vaeth@mathematik.uni-wuerzburg.de
- Cc vaeth@mathematik.uni-wuerzburg.de added
The openrc-0.4.1-start-stop-daemon.patch works for me. Not sure whether getopt_long() will free() the optarg string (i.e. whether xstrdup()/free() in the patch is really needed) but better be safe than sorry...
Changed 20 months ago by vaeth@mathematik.uni-wuerzburg.de
- attachment openrc-0.4.1-start-stop-daemon.2.patch added
Patch for start-stop-daemon.c to postpone parse_schedule() after option parsing. No memory leak if --retry is used repeatedly.
comment:8 in reply to: ↑ description Changed 20 months ago by gurli@gurlinet.dk
- Cc gurli@gurlinet.dk added
comment:9 Changed 20 months ago by polynomial-c@gmx.de
Nice. With this patch I don't have to alter all those failing init scripts on my machines as these scripts don't fail anymore ;)
comment:10 Changed 20 months ago by gurli@gurlinet.dk
These patches also fixes the problem for me.
comment:11 Changed 20 months ago by anonymous
Please use vaeth's patch as mine only circumvents the problem while his patch is fixing the real problem.
comment:12 Changed 20 months ago by roy
- Status changed from assigned to closed
- Resolution set to fixed
r1460 should fix this, based on vaeths idea. Re-open if anyone thinks otherwise.
There is no need to duplicate the optarg for this, just store the reference to the latest.