lefko@vaxwaller.UUCP (Marty Lefkowitz) (08/27/90)
first, thanks for the pointer to dirent. I loaded that library up and am now running bash. (now if I only had a manual). I'm having another problem though maybe someone else has run across. For some reason my machine decided to not let me log back in after I log out. I have to reboot the system. When I log out the window manager comes on the screen, whether I've been using the windows or not, with no menu. I just get a blank window. Does anybody know whats wrong?
yarvin-norman@cs.yale.edu (Norman Yarvin) (08/29/90)
In article <4486@vaxwaller.UUCP> lefko@vaxwaller.UUCP (Marty Lefkowitz) writes: >I'm having another problem though maybe someone else has run across. >For some reason my machine decided to not let me log back in after I >log out. I have to reboot the system. When I log out the window >manager comes on the screen, whether I've been using the windows or >not, with no menu. I just get a blank window. Does anybody know >whats wrong? The window manager pops up its window whenever it becomes the current window. Generally that happens when you click on it, but in this case it's because it just happened to be next in line to become the active window. I think each window has a 'parent' window to which focus shifts after the window dies. In any case, your problem is that you have no getty running. (/etc/getty; the program that prints out the login prompt.) Init is supposed to respawn another getty whenever the first getty dies. Thus either: 1) The new getty is exiting as soon as it is started, or is not starting up correctly. (not much reason for this to happen.) 2) Init wasn't set up right to respawn the new getty. (If you didn't change /etc/inittab, there's not much reason for this to happen either.) 3) The first getty didn't exit. Since 'exit' is a loose term here, more explanation is in order. Getty normally execs login, subsequently to which login execs your shell. However, the process id is retained through calls to exec, so your shell has the same pid as the original getty. Thus after you log in, init is waiting for your shell to exit. And, surprise, you just changed to a new shell (bash). :-) So, perhaps it's time to go hunting for bashes which have overstayed their welcome. -- Norman Yarvin yarvin-norman@cs.yale.edu "Praise the humanities, my boy. That'll make them think you're broadminded!" -- Winston Churchill
donlash@uncle.uucp (Donald Lashomb) (08/29/90)
In article <4486@vaxwaller.UUCP> lefko@vaxwaller.UUCP (Marty Lefkowitz) writes: >first, thanks for the pointer to dirent. I loaded that library up and >am now running bash. (now if I only had a manual). > >I'm having another problem though maybe someone else has run across. >For some reason my machine decided to not let me log back in after I >log out. I have to reboot the system. When I log out the window >manager comes on the screen, whether I've been using the windows or >not, with no menu. I just get a blank window. Does anybody know >whats wrong? Sounds like the problem I had awhile ago when I installed the 3.51m aka FixDisk2 stuff. The problem seems to be in the init-getty-login area. Even though a fellow with source code at AT&T was trying to help me with my trouble, I never did resolve the problem. What I did in the end was scrap the init, getty and login programs that came with FixDisk2 and reload the original versions of them. This, however, is not a perfect solution, as there were bugs in the original versions of these programs, or else AT&T wouldn't have released new ones with the FixDisk2, would they :-) Also now I occasionally find the file /etc/utmp.lck on my system. This file is supposed to be a temporary lock file while init, ph or smgr muck with the utmp file- one of these guys is not cleaning-up properly, I suspect ph. utmp.lck doesn't seem to prevent init from respawning a getty on the console/windows, but it does prevent my uugetty from working in tty000. I know the above probably ain't much help to you, but if you are running the 3.51m - FixDisk2 stuff, then you got the same problem I do. Maybe someone with source code can take a fresh look at it and nail-down the problem. -Don Donald Lashomb donlash@uncle.UUCP -or- Cranberry Lake, NY uncle!crlake!{root install donny}