<exiting> tip processes on the SUN
Mario Dorion SSE Sun Montreal
mario at theglove.Sun.COM
Wed Jan 3 02:26:42 AEST 1990
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.
More information about the Comp.unix.wizards
mailing list