Bug 121921
| Summary: | pppd stops working but does not crash or exit. | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Jean-David Beyer <jdbeyer> |
| Component: | ppp | Assignee: | Thomas Woerner <twoerner> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.0 | CC: | ubeck |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-11-03 11:28:18 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Please have a look at http://people.redhat.com/twoerner/SRPMS/3.0E/ppp-2.4.1-14.1.src.rpm http://people.redhat.com/twoerner/RPMS/3.0E/ppp-2.4.1-14.1.i386.rpm This might solve the problem. 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? 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 update. No, up2date will not downgrade to the latest erratum. BTW: ifup ppp0 does not restart the connection. "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. 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. 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. Uwe Uwe Does it work again if you just remove the lock file in /var/lock ? 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. Please reopen this bugzilla entry, if the problem occurs again. |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.2) Gecko/20040301 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): ppp-2.4.1-14 How reproducible: Sometimes 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: