herb@blender.uucp (Herb Peyerl) (02/09/91)
The subject sort of says it all. Most of our nodes act normally
when a user telnet's to them however, a few of them produce this
error: "Object is not locked by this process". My node was running
10.2 and producing this message but I figured I'd just wait to complain
about it until I upgraded to 10.3. Now I've upgraded and the situation
hasn't changed. It happens when a user telnet's to a suspect node,
and gets an Aegis shell. Any command thereafter "ld, /bin/sh, /bin/ls,
etc" returns the error. Any shell internal command ("wd") works fine
but that only stands to reason.
Has anyone ever had this and known how to solve it? Possibly something
that is related to the problem is if we change the user's login shell
to csh or sh the user cannot login. It asks for "login:", the user types
in his username, then the "password:" prompt comes up but doesn't allow
the user to type anything before it aborts and the login: prompt comes
back up. This appears on the same nodes that show the other problem.
--
--------------------------------------------------------------------------
UUCP: herb@blender.UUCP || #define Janitor Administrator
ICBM: 51 03 N / 114 03 W || Apollo System_Janitor, Novatel Communications
"I spilled spot remover on my dog and now he's gone..." <Steven Wright>etb@milton.u.washington.edu (Eric Bushnell) (02/17/91)
I haven't seen that particular message, but I rarely use Aegis. However, the password reading problem is typical of the apollo corrupted pseudo tty syndrome. This is well known, and has a simple (usually) fix and workaround. You need to rebuild the pseudo tty devices in /dev. Kick off everybody who is rlogged in or telnetting, so that all the ptys are inactive. That means you must perform the fix from the console or a crp shell. Delete all the ptys in /dev. I use the unix command rm *typ*. Then make new ptys using /etc/crpty. If that doesn't do it, try again. I have, on occasion, had to reboot the bloody thing to make it take effect. You can use mkdev instead of crpty, I think. I suspect crpty is just a link or a script involving mkdev anyway. Some people run this periodically as a cron job, as preventive maintenance. Hope that helps, Eric Bushnell UW Civil Engr etb@zeus.ce.washington.edu etb@milton.u.washington.edu
dbfunk@ICAEN.UIOWA.EDU (David B Funk) (02/19/91)
In posting <16541@milton.u.washington.edu> etb%milton%ogicse.uucp@uunet.uu.net (Eric Bushnell) says, > You need to rebuild the pseudo tty devices in /dev. Kick off > everybody who is rlogged in or telnetting, so that all the > ptys are inactive. That means you must perform the fix from the > console or a crp shell. > > Delete all the ptys in /dev. I use the unix command rm *typ*. > Then make new ptys using /etc/crpty. If that doesn't do it, > try again. I have, on occasion, had to reboot the bloody thing > to make it take effect. There is another way to deal with this problem that doesn't require killing all tcp connections, just rename all ttyp/ptyp pairs that are in use. For example: $ ps aug USER PID SZ RSS TTY STAT TIME COMMAND dbfunk 3340 0 180 crp00 S 0:00 -sh dbfunk 3342 512 136 crp00 R 0:00 ps aug kbchandr 3264 0 72 pad0001 S 0:03 -sh kbchandr 3341 256 284 pad0001 R 0:01 c.bin jlb 3325 512 392 ttyp0 S 0:02 -csh $ cd /dev $ mv ttyp0 ttyp0.b $ mv ptyp0 ptyp0.b $ rm ?typ? $ ps agu USER PID SZ RSS TTY STAT TIME COMMAND dbfunk 3340 0 180 crp00 S 0:00 -sh dbfunk 3347 512 136 crp00 R 0:00 ps agu kbchandr 3264 0 68 pad0001 S 0:03 -sh jlb 3325 512 392 ttyp0.b S 0:02 -csh Be sure that you change the name of each ttyp? and its associated ptyp? in the same way. Then be sure that you don't delete either of them when you clean out the other (possibly FUBAR) ttyp/ptyp pairs. That is what determined the choice of wildcards for the "rm". Once the renamed pty pairs are no longer used (the user logs out) then they too can be deleted. > > You can use mkdev instead of crpty, I think. I suspect crpty is > just a link or a script involving mkdev anyway. > "/etc/crpty" and "/etc/mkdev" are not the same thing, they are 2 different programs that can be used to accomplish the same goal but have subtle differences that you should be aware of: /etc/crpty 1) Only creates ttyp/ptyp pseudo tty pairs 2) will fail if ttyp?/ptyp? currently exist. 3) command line: /etc/crpty 16 4) can be run by "root" or "%.locksmith" 5) uses value of "process" & "umask" to set protections on created ptys' if umask is wrong, then protections will be wrong 6) can create any number of pty pairs, from 1 to 64 /etc/mkdev 1) Can be used to create the whole spectrum of special device files. 2) Will remove any existing ttyp?/ptyp? pairs before creating new ones. 3) command line: /etc/mkdev /dev pty 4) only can be run by "root" 5) Will always set owner, group, & protections on ptys "correctly" regardless of the invoker's umask setting 6) will always create 16 pty pairs Note that crpty can be used to create more than 16 ptys. Pre-sr10.3 there wasn't much use for this due to the OS limitations, except for on a DN10k. With sr10.3 and the new OS capabilities, it is actually possible to use more than 16 ptys (not to mention that the tcp/ip software is more stable). We have a DSP3500 here that is used as a BBS machine, at sr10.2 with 16 ptys, we had to reboot it daily due to tcp lock-ups. With sr10.3 & 32 ptys, I have seen as many as 2 dozen users at 1 time and the required reboot rate has dropped to semi-weekly ;=). Dave Funk