Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #1509 > unrolled thread

How2 kill pppd without pulling-plug?

Back to article view | Back to comp.os.linux.networking

Contents

  How2 kill pppd without pulling-plug? Avoid9Pdf@gmail.com - 2012-07-11 19:20 +0000
    Re: How2 kill pppd without pulling-plug? Moe Trin <ibuprofin@painkiller.example.tld.invalid> - 2012-07-11 21:05 -0500
    Re: How2 kill pppd without pulling-plug? James Carlson <carlsonj@workingcode.com> - 2012-07-17 07:45 -0400
      Re: How2 kill pppd without pulling-plug? Avoid9Pdf@gmail.com - 2012-07-19 12:16 +0000
        Re: How2 kill pppd without pulling-plug? J G Miller <miller@yoyo.ORG> - 2012-07-19 12:27 +0000

#1509 — How2 kill pppd without pulling-plug?

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.

[toc] | [next] | [standalone]

#1510

FOLLOWUP SET

On Wed, 11 Jul 2012, in the Usenet newsgroup comp.os.linux.networking, in
article <jtkjla$mch$1@dont-email.me>, Avoid9Pdf@gmail.com wrote:

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

Sweet Mother of Ghod, Chris - how long have you been using *nix?  And
you haven't learned about shutting down gracefully?  Are you going
completely senile?    Or just trolling?

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

Because when you do that, you don't give things time to exit cleanly.
RTFM "man kill"         It's leaving shit scattered about your file
system, like lock files.   If you absolutely must use kill (or killall)
use -15 as the signal,  NOT MINUS NINE.

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

So your system is p0wn3d - maybe - try 'ps afuwwwx' and look to see
what process started what.   Also kick your pppd and include the 'dump'
option to see what options you've attempting to use.  See the man page.

        Old guy

[toc] | [prev] | [next] | [standalone]

#1513

On 07/11/12 15:20, Avoid9Pdf@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         <carlsonj@workingcode.com>

[toc] | [prev] | [next] | [standalone]

#1525

In article <ufcNr.4172$wD4.1838@newsfe19.iad>, James Carlson <carlsonj@workingcode.com> wrote: 

> On 07/11/12 15:20, Avoid9Pdf@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.

[toc] | [prev] | [next] | [standalone]

#1526

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.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.networking

csiph-web