larry@tapa.uucp (Larry Pajakowski) (07/05/89)
First thank's to all those who took the time to reply to my problems with init exiting. Most suggestions were that init was being signaled by a process with root permissions. Ed Hew also suggested looking at the process accounting log for hints. Here is what I think was going on. Once an hour I run a script to disable and enable the tty port attached to the TB+ to take care of the port/modem going comotose. Concurrent and unknown to me a getty was being re-spawned on tty11 every minute. This is very similar to problems we and others have had with smart modems not configured correctly. Now the Compaq this runs on only has 10 function keys so tty11 didn't have anything to talk to. I suspect tty11 being enabled was a relic of the 2.2.6 version running on the machine previously. I seem to remember that the tty ports were renamed as part of the 2.3.1. release to support F11 and F12. The log of failures indicated that they occured right after the disable/enable script was run. Looking at the process accounting log revealed that when the disable/enable script executed at the same time (one second resolution here) as the re-spawning of the tty11 getty init would exit. I suspect that init had received the kill signal say from the disable/enable when the kill signal from the getty exiting happened. This then caused init to get confused and exit. The solution then was to disable tty11 which wasn't supposed to be enabled in the first place. Most likely if this is the problem there may be other situations like this where init is busy processing signals at about the same time from exiting processes, enable and disable. Beware. SCO I like you product and I hope you can fix this. The last 6 months have been rather frustrating to me and our users. Again thank's to all who responded. Larry Pajakowski Abbott Labs. larry@abtcser 1-312-937-1153
clewis@eci386.uucp (Chris Lewis) (07/07/89)
In article <1989Jul5.154102.703@tapa.uucp> larry@tapa.uucp (Larry Pajakowski) writes: >First thank's to all those who took the time to reply to my problems with init >exiting. Didn't notice what this thread was about before... >Once an hour I run a script to disable and enable the tty port attached to the >TB+ to take care of the port/modem going comotose. Concurrent and unknown to >me a getty was being re-spawned on tty11 every minute. This is very similar >to problems we and others have had with smart modems not configured correctly. Xenix, at least in several older versions on multiple platforms has this problem. If you disable and then enable a port "too quickly", init can die. Where "too quickly" depends.... This is even documented! (in older Xenix manuals at least). "disable port" goes off and changes /etc/ttys (or /etc/inittab if you're running the new init stuff), signal's /etc/init, and (I think) kills any getty on that port. /etc/init, on receipt of the signal, rescans /etc/ttys (/etc/inittab), notes the changes, and then doesn't bother to reissue the /etc/getty that died. enable essentially diddles /etc/tty (/etc/init) and then signals /etc/init to tell it to reread the file and restart the getty. Now the rub - unless /etc/init has had a chance to run, rescan, and rearm the signal by the time the second signal comes in - it's bye-bye init. I'm not too certain of the precise details of whether this is to do with the problems with SV signaling in general, or just sloppiness in /etc/init. Work around: put a "sleep 30" between disable and enable. We used a version of 4.3UUCP on a Xenix system that had this problem. The UUCP had a mechanism for turning the line around between incoming and outgoing. Once we put the sleep in, it never happened again. (This was a *very* old version of Xenix, but if this is the "generic" signal problem, it's probably still there...) -- Chris Lewis, R.H. Lathwell & Associates: Elegant Communications Inc. UUCP: {uunet!mnetor, utcsri!utzoo}!lsuc!eci386!clewis Phone: (416)-595-5425