Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

How2 kill pppd without pulling-plug?

274 views
Skip to first unread message

Avoi...@gmail.com

unread,
Jul 11, 2012, 3:20:13 PM7/11/12
to
I remember reading how some Soviet-scammers, made people's modems
auto-dial Moldovia, and the expensive call costs went partly to the scammers.

Since then I just pull the plug.
And I've got the POTS-dial-up modem set to *sound*.

Now this fixed-radio-terminal-modem which goes via ttyUSB0, can't
re-connect after I disconnect-the-USBline, until I reboot.

It was previously OK, under Slak13, until that crashed the IDE and
I've been using old-FC1.

There's a kernel problem and apparently a mem-leak, because
it slowly <disconnects pid/S after I've pulled-the-line>.

Here's `tail /var/log/messages` :-
Jul 11 19:08:50 localhost pppd[28712]: secondary DNS address 41.164.0.11 <-last good line
Jul 11 19:23:57 localhost kernel: usb.c: USB disconnect on device 00:0f.0-1 address 4
Jul 11 19:23:57 localhost kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000998
Jul 11 19:23:57 localhost kernel: printing eip:
Jul 11 19:23:57 localhost kernel: caef656c
Jul 11 19:23:57 localhost kernel: *pde = 00000000
Jul 11 19:23:57 localhost kernel: Oops: 0002
Jul 11 19:23:57 localhost kernel: ppp_deflate ppp_async ppp_generic slhc usbserial vfat fat soundcore r128 agpgart reiserfs parport_pc lp parport autofs ipt_REJECT ipt_state ip_conntrack iptab
Jul 11 19:23:57 localhost kernel: CPU: 0
...
Jul 11 19:23:57 localhost kernel: [<c8a095c0>] usb_hub_thread [usbcore] 0x0 (0xc60b3fe0)
Jul 11 19:23:57 localhost kernel: [<c010741d>] kernel_thread_helper [kernel] 0x5 (0xc60b3ff0)
Jul 11 19:23:57 localhost kernel:
Jul 11 19:23:57 localhost kernel:
Jul 11 19:23:57 localhost kernel: Code: 89 90 98 09 00 00 8d 4e 58 ff 43 74 0f 8e 96 05 ...

Also why can't I
`kill -9 <pppd-pid>` ?

If I leave the USB-line connected it goes on-line by itself, every few minutes.
What the hell is that?!

== TIA.


James Carlson

unread,
Jul 17, 2012, 7:45:30 AM7/17/12
to
On 07/11/12 15:20, Avoi...@gmail.com wrote:
> Here's `tail /var/log/messages` :-
> Jul 11 19:08:50 localhost pppd[28712]: secondary DNS address 41.164.0.11 <-last good line
> Jul 11 19:23:57 localhost kernel: usb.c: USB disconnect on device 00:0f.0-1 address 4
> Jul 11 19:23:57 localhost kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000998

The drivers clearly don't take kindly to having the hardware yanked
away. If you have the source for the drivers and the time to
investigate the problems they have, you might be able to repair them to
your liking. Otherwise, don't do that.

> Also why can't I
> `kill -9 <pppd-pid>` ?

If a user thread (such as pppd) invokes a kernel interface that blocks,
it can block in an uninterruptible manner. When that happens, you
cannot kill the process because it can't be interrupted.

In other words, it's due to the kernel bugs noted above that were
triggered by the action of pulling out the USB cable on a live connection.

> If I leave the USB-line connected it goes on-line by itself, every few minutes.
> What the hell is that?!

Dunno. Any chance you can post configuration information? By default,
pppd doesn't do that, but there are options you can configure ("demand"
and "persist" are the main ones) that will cause it to retry after a
disconnect.

Since it's not the default, it has to be somewhere in your pppd
configuration files and/or command line options.

--
James Carlson 42.703N 71.076W <carl...@workingcode.com>

Avoi...@gmail.com

unread,
Jul 19, 2012, 8:16:07 AM7/19/12
to
In article <ufcNr.4172$wD4....@newsfe19.iad>, James Carlson <carl...@workingcode.com> wrote:

> On 07/11/12 15:20, Avoi...@gmail.com wrote:
> > Here's `tail /var/log/messages` :-
> > Jul 11 19:08:50 localhost pppd[28712]: secondary DNS address 41.164.0.11 <-last good line
> > Jul 11 19:23:57 localhost kernel: usb.c: USB disconnect on device 00:0f.0-1 address 4
> > Jul 11 19:23:57 localhost kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000998
>
> The drivers clearly don't take kindly to having the hardware yanked
> away. If you have the source for the drivers and the time to
> investigate the problems they have, you might be able to repair them to
> your liking. Otherwise, don't do that.
>
I expect USB to be plug-and-play-able?
It was on my knl2.6* linux.

> > Also why can't I
> > `kill -9 <pppd-pid>` ?
>
> If a user thread (such as pppd) invokes a kernel interface that blocks,
> it can block in an uninterruptible manner. When that happens, you
> cannot kill the process because it can't be interrupted.
>
OK thanks, that's the deeper explanation that I wanted.

> In other words, it's due to the kernel bugs noted above that were
> triggered by the action of pulling out the USB cable on a live connection.
>
> > If I leave the USB-line connected it goes on-line by itself, every few minutes.
> > What the hell is that?!
>
> Dunno. Any chance you can post configuration information? By default,
> pppd doesn't do that, but there are options you can configure ("demand"
> and "persist" are the main ones) that will cause it to retry after a
> disconnect.
>
> Since it's not the default, it has to be somewhere in your pppd
> configuration files and/or command line options.

Adding `demand nopersist` to my 90s-old script, which I've
been using before I read your book at the Johannesburg
reference library [**], I'm now able to `killall pppd`.
And then I'm now able to pull-out the USB-line.
Which previously gave <kernel errors /problems> on this
knl 2.4*, since my knl 2.6* has crashed. Knl2.6* could handle it;
which is what also confused me.

I don't trust the system/s.
Going on line, is like a rocket-launch or a taxi-journey:
when it's finished, I must disconnect.

== Chris Glur.

[**] since the <revolutionary-natives-party> was handed
power, they've closed the previously brilliant ,30's built,
reference library, and I've heard that by mistake some
AA employee pulped many of the valuable books. A lot of the
new books are cartoon-based. Which perhaps makes sense
since the controlling-natives have never had a written language.
Today' BBC news was explaining how S. Italy's local government &
municipal authorities are similarly corrupt.
Be happy don't worry.



J G Miller

unread,
Jul 19, 2012, 8:27:38 AM7/19/12
to
On Thursday, July 19th, 2012, at 12:16:07h +0000, Chris Glur wrote:

> Today' BBC news was explaining how S. Italy's local government &
> municipal authorities are similarly corrupt.

It is highly improbably that you will ever find any country without
any goverment or municipal government which is not corrupted to some degree.

It is all a matter of degree of how bad is the corruption, just
like the people in any population, qv corruption in the administrations
of F W de Klerk and P W Botha.
0 new messages