Am 02.02.2006 um 15:55 Uhr +0000 schrieb Hauke Fath:
>  Gnah, when you want the bug, it doesn't show...
>
>  A coworker reported it once with a -current kernel though, so it's
>  not strictly netbsd-3.
>
>  Am 31.01.2006 um 17:55 Uhr +0000 schrieb Christos Zoulas:
>  >  Can you show what w(1) prints and the "interesting" ptys in /dev/[pt]ty??.
>  >  I suspect what is going on, is that you have a rogue program that is
>  >  opening old style pty's behind the pty subsystem's back, so when ptyfs
>  >  tries to open the same pty, it fails.
>
>  Sounds reasonable...
>
>  >So when it fails for pts/4 for example, what does lsof say for 
>/dev/{t,p}typ4?

Doesn't look that easy.

I just encountered the bug on an idle machine that I had logged into 
remotely, i.e. no KDE stuff running (the login prompter is gdm, and 
there were a few leftover dbus-daemon-1 processes).

Matlab 14 aborted, and a ktrace showed me it wanted /dev/pts/1 but 
didn't get it. The fstat /dev/{t,p}typ1 came up _empty_.

I opened another remote xterm, became root to install the lsof 
package. The second login did successfully create /dev/pts/1. After 
that, Matlab would start up just fine, and create a /dev/pts/2, but 
owned root:wheel unlike 0 and 1 which were owned by my id, group tty.

Any ideas about where to go from here?

	hauke


-- 
/~\  The ASCII Ribbon Campaign                    Hauke Fath
\ /    No HTML/RTF in email	        Institut für Nachrichtentechnik
  X     No Word docs in email	                  TU Darmstadt
/ \  Respect for open standards              Ruf +49-6151-16-3281