Bug 121921 - pppd stops working but does not crash or exit.
Summary: pppd stops working but does not crash or exit.
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: ppp   
(Show other bugs)
Version: 3.0
Hardware: i686 Linux
Target Milestone: ---
Assignee: Thomas Woerner
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-04-29 03:43 UTC by Jean-David Beyer
Modified: 2007-11-30 22:07 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-03 11:28:18 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Jean-David Beyer 2004-04-29 03:43:57 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2)

Description of problem:
I have pppd configured to do demand dialing, and it works most of the
time. Most recently, it has run a week without failure, but when it is
feeling bad, it can fail more than once a day.

When it has failed, the symptoms are:

1.) Green "led" of modem-lights applet is lit, indicating that file
/var/lock/LCK..ttyS4 (the modem lock) exists (it does exist).
2.) Tasks that wish to communicate with the Internet through the ppp0
port fail to connect.
3.) If I pick up the telephone on the same line, dial tone is present.

On those times when I have looked at /var/log/messages, it indicates
that pppd disconnected due to lack of activity (as it should), but it
never tries to connect again. pppd is running, but mistakenly believes
the connection is up.

The only way I have found to fix it is to kill pppd with a -9 and
restart it with ifup.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Let system run normally.
2.Be patient.
3.After a while (could be a week) notice that system is disconnected
from the Internet and does not try to dial.

Actual Results:  pppd stops working.

Expected Results:  pppd should attempt to connect with ppp0 (uses wvdial).

Additional info:

Comment 2 Jean-David Beyer 2004-06-17 15:30:49 UTC
I downloaded the ppp-2.4.1-14.1.i386.rpm, stopped pppd, installed it with
rpm -Uvh ppp-2.4.1-14.1.i386.rpm
and restarted pppd with /sbin/ifup Exit109 (my ppp0 connection.

We will see.

I had been running the latest ppp supplied by up2date. Do I risk
having up2date downgrading this, or is this update about to be
distributed with up2date to RHEL 3 ES users?

Comment 3 Thomas Woerner 2004-06-17 16:28:12 UTC
This package is a test version with fixes and it is not signed. 
If it solves all problems and there is no need for additional fixes,
then it will be released as an official erratum for RHEL3 in the next

No, up2date will not downgrade to the latest erratum.

Comment 4 Thomas Woerner 2004-06-17 16:30:30 UTC
BTW: ifup ppp0 does not restart the connection.

Comment 5 Jean-David Beyer 2004-06-18 04:23:09 UTC
"BTW: ifup ppp0 does not restart the connection."

I am not sure I understand you. In the past ifup ppp0 DID restart the
connection; i.e., in RHEL 7.3, for example. In RHEL 3 ES, filling out
the GUI network configuration screen for modems connections names the
connection after the provider (or some such thing), so the same script
in /etc/sysconfig/network-scripts is called ifcfg.Exit109 instead of
ifcfg.ppp0, so ifup Exit109 does start pppd, which seems to call
wvdial, and restarts the connection.

Comment 6 Jean-David Beyer 2004-06-22 22:50:53 UTC
Running pppd failed today. pppd was running, but it would not initiate
a connection because, I suppose, it thought there was a connection:
the /var/lock/LCK..ttyS4 file was there and the modemlights applet
indicated a connection. Yet there was dial tone on the data line.

I examined /var/log/messages and pppd was not logging. This has
happened before. After a while, pppd stops logging.

So I had to kill it with -9 (a default kill did not stop it), remove
/var/log/LCK..ttyS3, and restart it. It then worked correctly.

Comment 7 Uwe Beck 2004-07-25 00:30:19 UTC
This looks like the same problem I reported in Bug #116921.
I use pppd together with ADSL. Not every day the problem is relevant.
Can be it works 14 days without errors.
The problem togehter with ADSL is, that the pppd is not correct works
if you have some/many actions in ip-down.local and ip-up.local. ADSL
do not use /var/lock/LCK..ttySx lockfiles but if pppd makes errors the
system state is "nothing is work".
Already in March I take the ppp-2.4.1 RHEL3 SRPM and the ppp-2.4.2
source and build my own ppp-2.4.2 RHEL3 RPM.
Since I use my own ppp-2.4.2 daemon I have no trouble (0 errors since
March, really).
The RHLE hotline has all informations from my in issue-tracker. It's
issue 34019. Also my ppp-2.4-2 SRPM is there known.



Comment 8 Thomas Woerner 2004-09-16 10:24:34 UTC
Does it work again if you just remove the lock file in /var/lock ?

Comment 9 Jean-David Beyer 2004-09-16 11:17:20 UTC
It has not failed lately (last time was 2004 June 22), so I do not
remember. Since it was failing fairly regularly before then, and not
since, I am not sure what changed. Knowing me, I tried that first
without success. But I would not swear to it.

There was a failure 2004 May 9.
There was a big up2date May 14 (around 150 packages) that did not fix
it, obviously.
There were three small up2dates May 19 that had nothing to do with ppp.
There were small up2dates on May 24 and May 26 that had nothing to do
with this.
There was a kernel up2date on 2004 May 30, but this did not fix it,
because pppd stopped working June 4. It had stopped logging sometime
in May, though it kept on working until June 4.
There was a small up2date 2004 June 9 that had nothing to do with it.
There was another kernel up2date 2004 June 17 that did not fix it.
Then it failed 2004 June 22.
There was a kernel up2date 2004 July 2, and major (180 packages)
up2date 2004 September 6. I have not noticed any changes to pppd in
there, but that does not guarantee there were none.

So either one of the kernel fixes fixed this problem, or the error
rate from whatever cause has gone down.

Comment 10 Thomas Woerner 2004-11-03 11:28:18 UTC
Please reopen this bugzilla entry, if the problem occurs again.

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