<exiting> tip processes on the SUN

[Mario Dorion SSE Sun Montreal]

In article <1000 at ursa-major.SPDCC.COM> dyer at 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 at ursa-major.spdcc.com aka {ima,harvard,rayssd,linus,m2c}!spdcc!dyer
>dyer at arktouros.mit.edu, dyer at hstbme.mit.edu

Actually there is an easier way, at least with Sun OS. The gcore
command (syntax: /usr/ucb/gcore <pid>) has the undocumented
side-effect of effectively killing an <exiting> process. The trace
command (syntax: trace -p <pid>) acts the same way. 

If a tty incoming line is hang <exiting> 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.