Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!rutgers!sun-barr!newstop!east!theglove.Sun.COM!mario From: mario@theglove.Sun.COM (Mario Dorion SSE Sun Montreal) Newsgroups: comp.unix.wizards Subject: Re: tip processes on the SUN Summary: A Cure Message-ID: <1324@east.East.Sun.COM> Date: 2 Jan 90 15:26:42 GMT References: <21875@adm.BRL.MIL> <1000@ursa-major.SPDCC.COM> Sender: news@east.East.Sun.COM Reply-To: mario@theglove.Sun.COM (Mario Dorion SSE Sun Montreal) Followup-To: /dev/null Organization: Sun Microsystems - Montreal Canada Lines: 31 In article <1000@ursa-major.SPDCC.COM> dyer@ursa-major.spdcc.COM (Steve Dyer) writes: > >You can issue a "kill" as much as you want. What it will do each time, >however, is to interrupt the sleep and restart the exit code. The exit >code will loop through all open files and call the device-specific close >routine again and get stuck one more time. Without rewriting the device >driver to handle this pathological situation (or ingenious adb hacking >on an active kernel), the easiest way to recover from this is to reboot. > >This is a general description of what can go wrong--it isn't Sun-specific. > >-- >Steve Dyer >dyer@ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer >dyer@arktouros.mit.edu, dyer@hstbme.mit.edu Actually there is an easier way, at least with Sun OS. The gcore command (syntax: /usr/ucb/gcore ) has the undocumented side-effect of effectively killing an process. The trace command (syntax: trace -p ) acts the same way. If a tty incoming line is hang and its corresponding process is 'killed' using one of these method, init will not know about it and won't restart a getty on that line, you should kill and restart init. Still you can have a script that does that job and even have a cron entry hunting and killing exiting processes every few minutes if you have a serious exiting problem. This should be simpler than rebooting :) Hope this helps.