pppd instances hanging on futex(..., FUTEX_WAIT) - PPP

This is a discussion on pppd instances hanging on futex(..., FUTEX_WAIT) - PPP ; Hi I have incrasing number of pppd instances hanging on such calls: futex(0x4018f800, FUTEX_WAIT, 2, NULL These processes dont respond to SIGTERM and I think about sending them SIGKILL. Is there a risk that I will be left with some ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: pppd instances hanging on futex(..., FUTEX_WAIT)

  1. pppd instances hanging on futex(..., FUTEX_WAIT)

    Hi

    I have incrasing number of pppd instances hanging on such calls:
    futex(0x4018f800, FUTEX_WAIT, 2, NULL

    These processes dont respond to SIGTERM and I think about sending them
    SIGKILL. Is there a risk that I will be left with some dead ppp
    devices? For now I have:

    20: ppp0: mtu 1500 qdisc noop qlen 3
    link/ppp
    23: ppp1: mtu 1500 qdisc noop qlen 3
    link/ppp
    51: ppp3: mtu 1400 qdisc noop qlen 3
    link/ppp
    133: ppp2: mtu 1400 qdisc pfifo_fast
    qlen 3
    link/ppp

    while no active PPP connection.

    Or maybe there is other option to get rid of these processes?

    ppp version 2.4.2
    Linux kernel version 2.6.5.

    Regards

    Michal


  2. Re: pppd instances hanging on futex(..., FUTEX_WAIT)

    michal-google@michal.waw.pl wrote:
    > Hi


    > I have incrasing number of pppd instances hanging on such calls:
    > futex(0x4018f800, FUTEX_WAIT, 2, NULL


    Courtesy of google, from http://ds9a.nl/futex-manpages/futex4.html:

    The Linux kernel provides futexes ('Fast Userspace muTexes') as a
    building block for fast userspace locking and semaphores. Futexes are
    very basic and lend themselves well for building higher level locking
    abstractions such as POSIX mutexes.

    Those that have extensive C programming experience and understand both
    POSIX mutex and PPP may be able to relate the futex function call above
    to PPP (I don't qualify).

    > These processes dont respond to SIGTERM and I think about sending them
    > SIGKILL. Is there a risk that I will be left with some dead ppp
    > devices? For now I have:


    The PPP interfaces are dead anyway as far as functionality is concerned.
    If there actually are pppd instances still running which are associated
    with the down interfaces then I can't see any reason not to try a SIGKILL.

    > 20: ppp0: mtu 1500 qdisc noop qlen 3
    > link/ppp
    > 23: ppp1: mtu 1500 qdisc noop qlen 3
    > link/ppp
    > 51: ppp3: mtu 1400 qdisc noop qlen 3
    > link/ppp
    > 133: ppp2: mtu 1400 qdisc pfifo_fast
    > qlen 3
    > link/ppp


    > while no active PPP connection.


    For anyone who doesn't know, the output above comes from "ip link list"
    (iproute2), and provides an output similar to parts of ifconfig output.
    Linux can use iproute2 but I don't know whether other OSs can do so.
    The qdisc stands for queue discipline, which is configured by "tc" - a
    traffic control (TC) program associated with iproute2. Queue discipline
    bears some resemblance to IP TOS.

    I use tc in a bare-bones attempt to help processes using PPP to compete
    "fairly," with sfq, stochastic fairness queuing, by using the lines

    /sbin/tc qdisc add dev ppp0 root sfq perturb 10
    /sbin/tc qdisc del dev ppp0 root sfq perturb 10

    in /etc/ppp/{ip-up,ip-down} respectively (found in an advanced routing
    howto).

    > Or maybe there is other option to get rid of these processes?


    I don't know of any better option.

    But the trouble may be specific to the combination of the futex error
    and TC. If you don't remove the TC configuration in ip-down then perhaps
    you should try doing so and see whether that eliminates the left-over
    interfaces. You might also try not using TC at all and see whether the
    hanging goes away.

    > ppp version 2.4.2
    > Linux kernel version 2.6.5.


    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    /* The generation of random numbers is too important to be left
    to chance. */

  3. Re: pppd instances hanging on futex(..., FUTEX_WAIT)

    Clifford Kite wrote:
    > michal-google@michal.waw.pl wrote:
    >> Hi


    >> I have incrasing number of pppd instances hanging on such calls:
    >> futex(0x4018f800, FUTEX_WAIT, 2, NULL


    ....

    >> 133: ppp2: mtu 1400 qdisc pfifo_fast
    >> qlen 3
    >> link/ppp


    >> while no active PPP connection.


    It looks to me like ppp2 is active since that interface is UP.

    > For anyone who doesn't know, the output above comes from "ip link list"
    > (iproute2), and provides an output similar to parts of ifconfig output.
    > Linux can use iproute2 but I don't know whether other OSs can do so.
    > The qdisc stands for queue discipline, which is configured by "tc" - a
    > traffic control (TC) program associated with iproute2. Queue discipline
    > bears some resemblance to IP TOS.


    ....

    >> Or maybe there is other option to get rid of these processes?


    > I don't know of any better option.


    > But the trouble may be specific to the combination of the futex error
    > and TC. If you don't remove the TC configuration in ip-down then perhaps
    > you should try doing so and see whether that eliminates the left-over
    > interfaces. You might also try not using TC at all and see whether the
    > hanging goes away.


    Duh! Sorry, I leaped without looking - with the usual result. The tc
    program is not involved here; the kernel queue discipline _default_
    is pfifo_fast.

    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"

+ Reply to Thread