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

openrc-0.4.1-pppd-send-sigterm.patch Download (487 bytes) - added by polynomial-c@gmx.de 20 months ago.
With this patch pppd gets killed again
openrc-0.4.1-start-stop-daemon.patch Download (1.1 KB) - added by vaeth@mathematik.uni-wuerzburg.de 20 months ago.
Patch for start-stop-daemon.c to postpone parse_schedule() after option parsing
openrc-0.4.1-start-stop-daemon.2.patch Download (1.2 KB) - added by vaeth@mathematik.uni-wuerzburg.de 20 months ago.
Patch for start-stop-daemon.c to postpone parse_schedule() after option parsing. No memory leak if --retry is used repeatedly.

Change History

comment:1 Changed 20 months ago by anonymous

  • Owner roy deleted
  • Status changed from new to assigned

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

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

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

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.

Note: See TracTickets for help on using tickets.