#9 no more ptys

open-remind
QingLong
None
6
2014-03-10
2001-03-12
Thomas Laun
No

DESCRIPTION:
After running queue a few times, I suddenly started
getting the error "no more ptys." and my command was
not executed. This was the case even though there are
plenty of unused ptys around.

REASON:
The reason for this problem are the wrong file
permissons for the pseudo-terminals. On my system, they
have to be set like this:
crw-rw-rw- root tty ptya0
crw-rw-rw- root tty ptya1
crw-rw-rw- root tty ttya0
crw-rw-rw- root tty ptya1
After this problem occured, I found the owner and group
to be wrong. Interestingy, only a0 and a1 were wrong.
The others were ok.

FIX:
Login as root and reset the file permissions as
following (for my SuSE Linux 7.0 system):
chmod 666 ?tya?
chown root.tty ?tya?

WORKAROUND:
If you can't reset the file permissions, you can still
use queue without the pty-emulation. Use the command
switch -n to do so.

Discussion

  • Werner G Krebs

    Werner G Krebs - 2001-05-11
    • assigned_to: nobody --> wkrebs
    • status: open --> open-remind
     
  • Werner G Krebs

    Werner G Krebs - 2001-05-11

    Logged In: YES
    user_id=32209

    This is very helpful, but we should try to patch this. SuSE will become popular, even in the US.

     
  • Nobody/Anonymous

    Logged In: NO

    On a RedHat 6.2 box, after installing 1.40.1 and attempting
    to run it, has corrupted the pty subsystem. I tried the
    above steps to no avail. The workaround will work but
    whatever queue did, it took out x-windows and screen with
    it (They can no longer get ptys either -- unless they are
    run as root)

     
  • Werner G Krebs

    Werner G Krebs - 2001-05-28

    Logged In: YES
    user_id=32209

    You must mean 1.40.1-beta. 1.40.1 has not yet been released. This could confuse people once 1.40.1
    actually comes out.

    This is the first report we've had of pty system problems like this (taking out x-windows), and I do
    development on RedHat 6.2. It's too bad you posted this anonymously (hope you'll be monitoring this
    forum), as I would have liked to work with you to resolve this problem --- before the real 1.40.1 is released.
    Still, 1.40.1-BETA does have new terminal code (from rxvt), so I guess we'd better look into this.

    If the SuSE chmod fix doesn't work for, I suggest running the MAKEDEV script (/dev/MAKEDEV) to regenerate
    your pty subsystem. (Actually, not sure about Redhat, but many commercial unices run this after reboot.)
    1.40.1 has new terminal code in it (from rxvt), so I suppose we should look into this, although this the first
    report of the problem (and I use RedHat 6.2 for the builds.)

     
  • Werner G Krebs

    Werner G Krebs - 2001-05-28
    • priority: 5 --> 6
    • assigned_to: wkrebs --> qinglong
     
  • John McKowen Taylor, Jr.

    Logged In: YES
    user_id=276535

    Hi,

    I am trying the CVS/queue-development version (2003-11-11)
    and this bug is still a problem for me.

    The -n trick works, but with the accompanying loss of
    functionality.
    The chmod, chown workaround does nothing; my ptys are
    already OK.
    But to be thorough, I tried it anyway (no change),
    and then I tried re-running MAKEDEV, also to no avail.

    I can do "queue -n foo" no problem,
    but "queue foo" instantly returns
    "No more ptys." and then seems to wait for a keystroke
    before giving me the shell prompt.

    I am running RH8, 2.4.18-14smp.
    I used gcc323 to build queue.
    Also, I installed the latest autoconf and automake,
    and rebuilt the configure file to get it to run clean.

    I am interested in working with someone more familiar with
    the guts
    of queue to figure this out, as the full-duplex pty
    emulation seems
    to be one of Queue's virtues.

    Thanks!

    best regards,

    -- johnT
    John McKowen Taylor, Jr.
    Cadence Design Systems, Inc.
    200 Regency Forest Dr.
    Cary, NC 27511 USA
    +1 919 403 9966

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks