Bug 448881 - Race condition in ppp-watch results in ifup failure.
Summary: Race condition in ppp-watch results in ifup failure.
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: initscripts
Version: 9
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-05-29 08:53 UTC by Tomislav Vujec
Modified: 2014-03-17 03:14 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-03-20 14:21:09 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Tomislav Vujec 2008-05-29 08:53:04 UTC
Description of problem:
It seems there is a race condition in ppp-watch. I wanted to configure GPRS over
bluetooth connection, but kept getting error "The serial port could not be
locked." However, if I added "set -x" to the ifup-ppp script (trying to debug
the script), everything would work fine. After looking through sources and
tracing the executable, I found out that the parent ppp-watch gets the signal
from the background logger process which gets executed from the background shell
in turn execute from the ifup-ppp script. This signal is then interpreted as if
the pppd itself is exiting, which causes the parent to kill it.

Since I didn't understand why is this particular logger started in the
background, from a background shell no less, I fixed it with inserting sleep 1
before starting pppd. Why would anyone want to do this triple forking is beyond
my imagination.

Version-Release number of selected component (if applicable):
initscripts-8.76.2-1.i386

How reproducible:
It is a race condition, so it is hard to intentionally reproduce, but it always
happens for me.

Steps to Reproduce:
1. ifup <PPP_INTERFACE>
2.
3.
  
Actual results:
No connection with error message:
  Device <PPP_INTERFACE>: The serial port could not be locked.

Expected results:
  Connection established.

Additional info:

Comment 1 iarly selbir 2009-03-20 03:12:55 UTC
Hi, 

is this problem unsolved yet?

I'm want to keep alive this bug.

Thanks for any reply.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 2 Tomislav Vujec 2009-03-20 03:34:39 UTC
Unfortunately, since I switched my laptop, I don't have any way to test ppp right now. However, ifup-ppp still executes logger in double external shell background (line 144):
(/usr/bin/logger -p daemon.info -t ifup-ppp \
  $"pppd started for ${DEVNAME} on ${MODEMPORT} at ${LINESPEED}" &)&
This causes pppd to receive SIGCHLD and misinterprets it. I still question the logic of this particular line, it is just logging, why is it necessary to put it in external shell, and then background both the shell and logger process?!?!

Comment 3 Bill Nottingham 2009-03-20 14:21:09 UTC
(In reply to comment #2)
> (/usr/bin/logger -p daemon.info -t ifup-ppp \
>   $"pppd started for ${DEVNAME} on ${MODEMPORT} at ${LINESPEED}" &)&
> This causes pppd to receive SIGCHLD and misinterprets it. I still question the
> logic of this particular line, it is just logging, why is it necessary to put
> it in external shell, and then background both the shell and logger process?!?!  

So...

1) it's been there since the initial revision in the SCM (at least 11+ years ago!)
2) I can't test PPP at the moment either

When it was initially added, we did not exec pppd. So the race couldn't hit there.
Now we conditionally do, so it can.

Honestly, the simplest fix I would think is to just not background it at all - it's logger, it's not going to take forever.

http://git.fedorahosted.org/git/?p=initscripts.git;a=commitdiff;h=502b5569efec0a10c9eb04ad4e59b96ca6d03caf

Will add it to rawhide and watch for responses.


Note You need to log in before you can comment on or make changes to this bug.