schweigl@edvvie.at (Johnny Schweigl) (11/23/90)
We are currently encountering a major problem with no idea how to solve it. Machine configuration is as follows: Hardware: COMPAQ Systempro two 386/33 CPU boards 12 MB mem 1.6 GB Disk, configured for data guarding 3COM Etherlink II network adapter Adaptec SCSI controller GIGATAPE DAT streamer SCO UNIPATH SDLC comms board Computone controller with 1 Async feature box attached Software: SCO UNIX 3.2 Runtime TCP/IP 1.1.1 Runtime SCO (Corollary) MPX COMPAQ EISA supplement Operating environment: Machine serves as time accounting system with industrial terminals connected via RS232. Users (>25) telnet from WANG VS (great, BTW) to SCO box, using accounting software. 32 pty's are configured into the kernel (maximum allowed by TCP/IP). C2 security mode is relaxed (from sysadmsh). Error: After entering userid and passwd (telnet session is ok) SCO UNIX responds with "Cannot obtain database information on this terminal". when logging on as root on /dev/console, the system tells me that "The security databases are corrupt". No new logins are allowed after this error had occured. The error seems to have no systematic behaviour. It appears at random points in time, with 3 telnet sessions or 20, or something like that. RTFM: SCO TCP/IP release notes predict this error if pty's and vty's are not correctly configured. Nope. As far as I can see I did it right. Simply followed the instructions in the manual. No further reference to this error in the complete runtime docs. Also, the TCP/IP manual says, that if streams ressources are insufficient, unpredictable errors. Possible sources of error: Someone modified /etc/passwd manually. System will be reinstalled completely this weekend. If this was the only problem, shouldn't the error occur permanently? Quite contrary, it is not reproducible. Actions taken so far: Analyzed streams ressource usage with crash and strstat subcommand, reconfigured kernel. Should now be sufficient. Ran a brute force test with 32 concurrent telnets and some parallel ftp's. Error did not occur. Next day, error occured 8 times. One day later 3 times, and so on ... Problem: Angry users wanting to tear our heads off. So if you know any solution, or if this is a known error, corrected in release x.y.z pleeeaaase tell me. Thanks in advance, -- This does not reflect the | Johnny Schweigl opinions of my employer. | USENET: schweigl@edvvie.at I am busy enough by talking | about my own ... | EDVG Vienna/Europe, Tel (+43 222) 59907-0
martinh@hpopd.HP.COM (Martin Harris) (11/29/90)
I have seen a similar error occur on my system -only it happened all the time the solution was due to the update of the /etc/auth/system/ttys file going wrong and leaving it empty and the new and/or old ttys (-t, -o) lying around Solution if all the files ttys, ttys-t and ttys-o all exist and none are empty (and ttys-t == ttys) then delete ttys-t and ttys-o. If only ttys-t and ttys-o exist (or only ttys-t) then copy ttys-t to ttys and remove the surplas files. When fixing this I also came across the message that systems with large numbers of users logging on and off will generate this message sporadically ! But no way of fixing this was mentioned. Do they use whole file locking on ttys instead of record logging ??!!! Hope this of some use. Regards Martin Harris Hewlett-Packard - Pinewood England R&D Engineer.