Thanks to those who responded:
wallen@cogsci.UCSD.EDU (Mark R. Wallen)
Lars-Gunnar Olsson <Lars-Gunnar.Olsson@data.slu.se>
kevin@uniq.com.au (Kevin Sheehan {Consulting Poster Child})
Tim Gurbick <teg@logos.ucs.indiana.edu>
This is apparently a fairly common occurrence. Mark wrote in the most
direct and simple answer:
% adb -k -w /vmunix /dev/mem
physmem 7fa4
ff65598c+8/W 0
Lars came up with a Bourne-shell script:
#! /bin/sh
for i in `netstat -A | grep CLOSING | awk '{ print $1 }'`; do
echo "Closing $i";
adb -w /vmunix /dev/kmem <<EOF
$i+8/w 0
\$q
EOF
echo "$i will close in a couple of minutes";
done
Kevin offered a solution just as direct as Mark's, with an explanation:
> I think what you want here is
> ff65598c+8/1X
> ./W 0
>
>
> (. just says at the current address)
>
> which does a write. The > command sets variables, not memory. You will
> also have to issue the -w flag or the $W command for writable mode.
And Tim had some input on the wisdom of doing this:
> Use ff65598c+8/w0. Note that this can be a bad idea, though, as some
> kernel network resources might not be free'd correctly. You're setting
> the t_state in an unusual manner, so weirdness may follow. I believe
> you'll also get better success by using kmem instead of /dev/mem. Don't
> forget it may take 2 minutes for this to take effect, too.
I entered the adb command to overwrite memory as suggested, and sure
enough the port was freed up but Gopher now complains about an address
being already in use when I try to start it on that port. I figure
that with all my careening about in the kernel in my ignorance of adb,
it's a miracle it is still running, so it could have been easy for
something to be amiss such that the "address in use" would appear. My
regular preventative maintenance cycle is coming up this weekend
though, so the problem will be solved then, but I'd be interested in
finding out if this port nuking trick works in the future.
Thanks again go out to everyone who responded.
Anthony Yen - SPARC Sysadmin - Department of Economics - UT/Austin
ECB 3.138, MS#63100 - 471-3211 ext 170 - tyen@mundo.eco.utexas.edu
The original query:
> Sun-Managers:
>
> I'm running a Gopher server on a SPARCsystem 670MP, under SunOS 4.1.3,
> and after a kill -9 on the server daemon it left port 70 in a CLOSING
> state. As advertised by "netstat -A | grep CLOSING":
>
> ff65598c tcp 0 289 mundo.gopher 144.92.120.201.2133 CLOSING
>
> So I grab the Gopher FAQ and it "says do this, do that" (mainly some
> hacking on the live kernel with dbx). Only problem is, I'm not
> entirely convinced that the FAQ is quite right. It suggests using "dbx
> -k /vmunix /dev/mem", when there is no such flag option for dbx
> (although there is one for adb). Using "adb -k /vmunix /dev/mem" gives
> me slightly more useful results, but I can't seem to change the port
> setting back to zero:
>
> mundo# adb -k /vmunix /dev/mem
> physmem 7fa4
> ff65598c+8/1X
> 0xff655994: 70000
> ff65598c+8 > 0
> ff65598c+8/1X
> 0xff655994: 70000
> ff65598c+8>0
> ff65598c+8/1X
> 0xff655994: 70000
>
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:16 CDT