brant@manta.UUCP (Brant Cheikes) (06/27/88)
I've encountered this odd bug that I have so far been unable to find an explanation for. It's pretty innocuous, doesn't happen very often, and is cured by a reboot. The problem: the first shell spawned from the user agent (e.g., using "Full-screen UNIX" in 3.51) is attached to /dev/syscon instead of a /dev/wn. Subsequent shells get the usual window device. You can detect this problem by running either tty or ps. This hasn't caused me any problems so far, I've checked utmp and wtmp and the /dev/w* entries, everthing looks normal. Still, *something* must be wrong somewhere. Is there some way to cure this without rebooting? And is there anything wrong with just using /dev/syscon? The UNIXpc kernel continues to work [sic] in strange and wondrous ways. -- Brant Cheikes University of Pennsylvania Department of Computer and Information Science ARPA: brant@linc.cis.upenn.edu, UUCP: ...drexel!manta!brant
lenny@icus.UUCP (Lenny Tropiano) (06/28/88)
In article <378@manta.UUCP> brant@manta.UUCP (Brant Cheikes) writes: |>I've encountered this odd bug that I have so far been unable to find |>an explanation for. It's pretty innocuous, doesn't happen very often, |>and is cured by a reboot. The problem: the first shell spawned from |>the user agent (e.g., using "Full-screen UNIX" in 3.51) is attached to |>/dev/syscon instead of a /dev/wn. Subsequent shells get the usual |>window device. You can detect this problem by running either tty or |>ps. This hasn't caused me any problems so far, I've checked utmp and |>wtmp and the /dev/w* entries, everthing looks normal. Still, |>*something* must be wrong somewhere. Is there some way to cure this |>without rebooting? And is there anything wrong with just using |>/dev/syscon? The UNIXpc kernel continues to work [sic] in strange |>and wondrous ways. Yes, UNIX for the UNIX pc is sick... Who knows if AT&T will ever fix the bugs. My friend Gil Kloepfer, Jr. (gil@limbic.UUCP) had noticed this problem and was trying to figure out a pattern. It seemed that the machine would boot and the window'd devices were connected as "sys" or (syscon) when the ps was done, and not w1 (or w2, etc..). It seemed when he shut his machine down it would put the "Press Return to Reboot" message in side a window, and the /etc/killall wouldn't kill the window it was using. He noticed /dev/syscon had a major/minor number of 7, 1 (or 7, 2) depending on the window it was using, where it should be attached to /dev/window, and not /dev/w1 as major=7, minor=0. His temporary fix was to: # rm /dev/syscon # mknod /dev/syscon c 7 0 It would go away temporarily, but would creep back to the same problem every other reboot (or so). The problem was the /dev/window should be *LINKED* ln(1) to /dev/syscon, as likewise to /dev/systty. For some reason, still unknown to me /dev/syscon would get unlinked in the first place, but /dev/syscon's link was never recreated because he used the "rm" command and mknod(1M) to remake the character device. A better solution would be to: # ln /dev/window /dev/syscon crw-rw-rw- 3 root sys 7, 0 Jan 1 1970 /dev/syscon crw-rw-rw- 3 root sys 7, 0 Jan 1 1970 /dev/systty crw-rw-rw- 3 root sys 7, 0 Jan 1 1970 /dev/window If any can figure why a device minor should change in the first place, I would like to hear it. -Lenny -- Paper-net: Lenny Tropiano | @-net: lenny@icus.UUCP ICUS Software Systems | !-net: ...att \ PO Box 1 | boulder \ Islip Terrace, NY 11752 | talcott !icus!lenny Vocal-net: (516) 582-5525 [work] | pacbell / (516) 968-8576 [home] | sbcs / Telex-net: 154232428 ICUS | Another-net: attmail!icus!lenny
rjg@sialis.mn.org (Robert J. Granvin) (06/29/88)
In article <378@manta.UUCP> brant@manta.UUCP (Brant Cheikes) writes: >I've encountered this odd bug that I have so far been unable to find >an explanation for. It's pretty innocuous, doesn't happen very often, >and is cured by a reboot. The problem: the first shell spawned from >the user agent (e.g., using "Full-screen UNIX" in 3.51) is attached to >/dev/syscon instead of a /dev/wn. Subsequent shells get the usual >window device. This is not considered a bug. "syscon", by some descriptions is for "system console", which seems to appear during a subshell, rather than a login shell. Anyways... At least ATT doesn't consider it a bug, and I've never noticed any problems with it, and never even concerned myself with it since it's always happened here. ATT even puts checks for it in many of their scripts. When checking your device to make sure you're on the console screen, they'll check for both /dev/w and /dev/sys to make sure they catch it. >*something* must be wrong somewhere. I wouldn't be concerned by it. -- "I've been trying for some time to Robert J. Granvin develop a life-style that doesn't National Information Systems, Inc. require my presence." rjg@sialis.mn.org -Garry Trudeau ...{{amdahl,hpda}!bungia,rosevax}!sialis!rjg