Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!purdue!bu-cs!buengc!bph From: bph@buengc.BU.EDU (Blair P. Houghton) Newsgroups: comp.unix.ultrix Subject: Re: xcons murders the X server Message-ID: <4383@buengc.BU.EDU> Date: 28 Sep 89 18:54:10 GMT References: <4327@buengc.BU.EDU> <945@aoa.UUCP> Reply-To: bph@buengc.bu.edu (Blair P. Houghton) Followup-To: comp.unix.ultrix Organization: Boston Univ. Col. of Eng. Lines: 46 In article <945@aoa.UUCP> mbr@aoa (Mark Rosenthal) writes: >In article <4327@buengc.BU.EDU> bph@buengc.bu.edu (Blair P. Houghton) writes: >> [ Description of X-server going south when using xcons ] > >I seemed to be able to force the problem by filling up one of the disk >partitions.[...] I speculate that perhaps it has something to do with >the format of the error generated when a disk partition fills up, but >who knows. > >In any case, I never found a solution to the problem. DEC's support line was >no help at all. They took three days to come up with the answer that they >considered "xcons" and "xterm" to be unsupported products, and that I should >run DECwindows instead. "Your Guccis need a lace, but we don't know how to tie it, so here's some enormous rubber boots instead...buckle away." >Sadly, my solution is what you call "no solution". Comment out the xcons line >in /etc/ttys, and make sure your window manager has a refresh screen selection. Both done long ago. "Refresh" is at the top of the pop-up menu. Several people have mentioned using cat -u /dev/xcons which actually does the job for a while, but then causes the same server symptoms as running xcons(8X). I think you're right about the "format of the error generated" being the problem. I don't get it just by filling up disks, though. The "cat -u..." command has another problem: if the server dies, you can never kill that cat, even as root and logged in on a separate character terminal. It ignores kill -9. The only cure is reboot. Actually, I could live with the non-xcons screen-scribbling messages, but there's documentation to the effect that (and please don't ask me where, I think it was buried in the section on ed(1) :-) these messages will only become visible if you kill the server, which is true: when Xqdsg terminates, the invisible ink suddenly becomes readable, but only for the half-second it takes init to start up another Xqdsg... the only cure here must be to halt init(oyveh). --Blair "Hey, this one's got a busted buckle on it..."