kemp@convex1.convex.com (Phil Kemp) (07/16/90)
I caught the end of a thread last week about SCO UNIX failing to allow logins due to corruption of the terminal database. This bug has bite me twice now and I would like to know if anyone has further info on the details of this corruption. The first time I tried to reboot I couldn't get the system back up. I had to re-install from scratch. ( Well the base system, anyway... ). The problem has re-occurred and I am not able to check it out immediately. Please post as I'm not sure how well my mail is going to work this week :-( .... Thanks for any help PK Phil Kemp CONVEX Computer of Canada Ltd. Voice:(403)-233-2815 UUCP:kemp@convex.com
wht@n4hgf.Mt-Park.GA.US (Warren Tucker) (07/18/90)
In article <103961@convex.convex.com> kemp@convex1.convex.com (Phil Kemp) writes: >I caught the end of a thread last week about SCO UNIX failing to allow >logins due to corruption of the terminal database. This bug has bite >me twice now and I would like to know if anyone has further info on the >details of this corruption. The first time I tried to reboot I couldn't >get the system back up. Putting OVERRIDE=tty01 in /etc/default/login will let you log in as root on the first multiscreen even if the brown shirts (auth, SecureWare and friends) are miffed. Rebulding the kernel environment (idmkenv) seems to fix the problem for me, but I don't know why. --------------------------------------------------------------------- Warren Tucker, TuckerWare emory!n4hgf!wht or wht@n4hgf.Mt-Park.GA.US Ker-au'-lo-phon. An 8-foot partial flue-stop, having metal pipes surmounted by adjustable rings, and with a hole bored near the top of each pipe. Tone soft and "reedy".
gws@xenitec.on.ca (Geoff Scully) (07/19/90)
In article <103961@convex.convex.com> kemp@convex1.convex.com (Phil Kemp) writes: > >I caught the end of a thread last week about SCO UNIX failing to allow >logins due to corruption of the terminal database. This bug has bite >me twice now and I would like to know if anyone has further info on the >details of this corruption. The first time I tried to reboot I couldn't >get the system back up. I had to re-install from scratch. ( Well the >base system, anyway... ). The problem has re-occurred and I am not able >to check it out immediately. Please post as I'm not sure how well my >mail is going to work this week :-( .... > The problem is with the files /etc/auth/system/ttys*. There should be only on file in /etc/auth/system named ttys. When multiple login-logouts occur too rapidly a working file named either ttys-t or ttys-s will also reside in /etc/auth/system. You don't mention what version of SCO UNIX you are running, so some of the following may not apply. If you are running 3.2.1 or later, or if you have the 3.2.0 upgrade (unx146?? my memory fails me) for this problem, you should have a line in /etc/default/login that says OVERRIDE=tty01 or something like it. If this is the case you should be able to log in on tty01 and correct the problem by examining the files in /etc/auth/system. One of ttys, ttys-t or ttys-s will be a current version of your tty database, the others will either be incomplete or empty. Make sure the complete one ends up in /etc/auth/system/ttys and remove all others. You should now be able to log in on any tty. If the OVERRIDE feature is not available to you, first you should call SCO support and get them to send the appropriate "unx???" disk to you. You will likely have to shutdown hard if you are not logged in somewhere as root when it happens. Bring the system back up from your boot+root floppies and mount the hdroot filesystem on the floppy. Follow the same procedure as above to remove the extra ttys files from /etc/auth/system. Hope this helps... --g ---- Geoff Scully Support Services -- XeniTec Consulting Services Internet: gws@xenitec.on.ca UUCP: ..!{uunet!}watmath!xenitec!gws
mykel@saleven.oz (Michael Landers) (07/25/90)
In article <103961@convex.convex.com> kemp@convex1.convex.com (Phil Kemp) writes: >I caught the end of a thread last week about SCO UNIX failing to allow >logins due to corruption of the terminal database. This bug has bite >me twice now and I would like to know if anyone has further info on the >details of this corruption. The first thing you should do when you install an SCO system is to add "OVERRIDE=tty01" to /etc/default/login. This (as was previously mentioned) allows root to login on /dev/tty01 (ie the first of the console screen). As for the actual problem. If it is the same one that I have had a few (well, lots actually) times here then all you have to do is remove the file /etc/auth/system/ttys-t. This, I believe, is a tempory file used when recreating the terminal database information (which happens quite a lot), and when you log in, it can't recreate it as it is still there (note: logins rewrite the terminal database to update last login etc). I don't know why it is there, but it is simple enough to remove. Mykel. -- () \\ Black Wind always follows |\/|ykel Landers (mykel@saleven.oz) \\ Where by dark horse rides, _||_ \\ Fire is in my soul, Phone: +612 906 3833 Fax: +612 906 2537 \\ Steel is by my side.
kleiner@bu-tyng.bu.edu (Ken Kleiner) (07/27/90)
In article <103961@convex.convex.com> kemp@convex1.convex.com (Phil Kemp) writes: > >I caught the end of a thread last week about SCO UNIX failing to allow >logins due to corruption of the terminal database. This bug has bite >me twice now and I would like to know if anyone has further info on the >details of this corruption. The first time I tried to reboot I couldn't >get the system back up. I had to re-install from scratch. ( Well the >base system, anyway... ). The problem has re-occurred and I am not able >to check it out immediately. Please post as I'm not sure how well my >mail is going to work this week :-( .... > >Thanks for any help Hi, Well, I came across that problem in an SCO class that I was teaching. All of a sudden, a student said that he couldn't log in. He was getting the error 'Cant Obtain Database Info on this Terminal'. It happened right after we tried the 'mscreen' command (some were still in mscreen). It seems that there was a file called /etc/auth/system/ttys-t hanging around. We renamed it to something else and everything worked fine after that. Is this a temp file of some sort built from /etc/auth/system/ttys? BTW, it only happens when you use mscreen. Anybody else seen this? -Ken ------------------------------------------------------------------------------ Ken Kleiner <<< {wang}{ulowell}{elrond}{decvax}!bu-tyng!kleiner >>> Boston University's Corporate Education Center (Computer Center) 72 Tyng Road, Tyngsboro, MA 01879 (508) 649-9731 GO RED SOX!!!! -----------------------------------------------------------------------------
root@mjbtn.JOBSOFT.COM (Mark J. Bailey) (07/28/90)
kleiner@bu-tyng.bu.edu (Ken Kleiner) writes: >In article <103961@convex.convex.com> kemp@convex1.convex.com (Phil Kemp) writes: >> >>I caught the end of a thread last week about SCO UNIX failing to allow >>logins due to corruption of the terminal database. This bug has bite >>me twice now and I would like to know if anyone has further info on the >>details of this corruption. The first time I tried to reboot I couldn't >>get the system back up. I had to re-install from scratch. ( Well the >>base system, anyway... ). The problem has re-occurred and I am not able >>to check it out immediately. Please post as I'm not sure how well my >>mail is going to work this week :-( .... >> >>Thanks for any help >Hi, > Well, I came across that problem in an SCO class that I was > teaching. All of a sudden, a student said that he couldn't > log in. He was getting the error 'Cant Obtain Database Info > on this Terminal'. It happened right after we tried > the 'mscreen' command (some were still in mscreen). It seems that > there was a file called /etc/auth/system/ttys-t hanging around. > We renamed it to something else and everything worked fine after > that. Is this a temp file of some sort built from > /etc/auth/system/ttys? > BTW, it only happens when you use mscreen. > Anybody else seen this? > -Ken I have had the same problem for some time on SCO Unix 3.2.1 (shipped with EAP ODT). It occurs when the terminal database logging process fails (somehow) and does not completely remove its temp files. This is documented in at least the ODT system admin's guide in the section on error messages. I contacted SCO about it and they are aware of it and are working on a fix. Aparently (IMHO), there is a flaw in their algorithm. They had a fix disk for a while and then pulled it (I assume because of continued problems). This is all a part of the C2 security system. In my experience with it, it occurs when several people are logging in or out simultaneously. The processes working with the ttys must collide at a critical section and die prematurely. Your experience with it when using mscreen would likely create such a period of lots of logging in processes. I suspect that this is big on SCO's fix list. When I posted to the net about a month ago, one reader sent me the following shell script that I think he got from SCO as a temporary fix (kludge) to cleanup when the garbage ttys-* files get left around. I run it from cron every 30 minutes, and while I am still running into this problem, at least every 30 minutes, it is being checked and cleared! While there is a possibility of it running at the same time someone is logging in, so far I have had no problems. Beats driving 10 miles across town from home everytime it screws up. I suppose one could add a little to the front of the script to check for temp ttys-* that are older than, say, 5 minutes. You should contact SCO tech support and at least get on the list for the fix. I believe it will be an update to the C2 security system. Hope this helps. Thanks to Lance Ellinghouse for this fix! It works! :-) Mark. -------------------------------- cut here --------------------------------- From uunet!sco!hermix!root Mon Jun 18 23:57:33 1990 Return-Path: <uunet!sco!hermix!root> Received: by mjbtn.jobsoft.com (/\=-/\ Smail3.1.18.1); Mon, 18 Jun 90 23:57 CDT Received: from sco.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA20158; Mon, 18 Jun 90 20:13:11 -0400 From: uunet!hermix!root (Superuser) X-Mailer: SCO System V Mail (version 3.2) To: mjbtn!mjb Subject: Fix for problems with *-t files on TTYs Date: Mon, 18 Jun 90 13:41:47 PDT Message-Id: <9006182041.aa01535@hermix.UUCP> Status: RO Here is a fix that I put together for the problem of TTYs database going down due to the *-t file being left there. The script follows and then put a line in the root's crontab to run this every now and then. This fix was given to me by SCO after MANY MANY complaints from eme. Have fun! ------- Cut here -------- # # This is to fix the tty database when it gets a messed up # if [ -f /etc/auth/system/ttys ] then if [ -f /etc/auth/system/ttys-t ] then rm /etc/auth/system/ttys-t fi if [ -f /etc/auth/system/ttys-o ] then rm /etc/auth/system/ttys-o fi exit fi if [ -f /etc/auth/system/ttys-o ] then mv /etc/auth/system/ttys-o /etc/auth/system/ttys chown auth /etc/auth/system/ttys chgrp auth /etc/auth/system/ttys chmod 664 /etc/auth/system/ttys if [ -f /etc/auth/system/ttys-t ] then rm /etc/auth/system/ttys-t fi exit fi if [ -f /etc/auth/system/ttys-t ] then mv /etc/auth/system/ttys-t /etc/auth/system/ttys chown auth /etc/auth/system/ttys chgrp auth /etc/auth/system/ttys chmod 664 /etc/auth/system/ttys exit fi ------ Done ------ Have fun and enjoy! Lance Ellinghouse Mark V Systems, Ltd. E-mail: uunet!sco!hermix!lance hermix!lance@anes.ucla.edu ------------------------------------------------------------------------- -- Mark J. Bailey, N4XHX "We do our JOB, so you can do yours!" USMAIL: 511 Memorial Blvd., Murfreesboro, TN 37129_______/====X11====\_______ VOICE: +1 615 893 0098 | JobSoft | UUCP: ...!uunet!mjbtn!mjb, ...!raider!mjbtn!mjb | Design & Development Co.| DOMAIN: mjb@mjbtn.JOBSOFT.COM CIS: 76314,160 | Murfreesboro, TN USA | <KA9Q-UNIX-USERS Mailing List-Subscribe: ka9q-unix-requests@mjbtn.jobsoft.com>