My original query:
Systems: Sparcstation 1, 1+, 2, IPC, Classic
SUNOS 4.1.3 (4.1.3c on Classics)
16MB RAM per system
207MB HD per system
My problem is this: I have written a small shell script to reboot any or all
stations in my undergraduate laboratories. This script remote-shells to
each station and runs 'reboot' as a background process. After 10 seconds, a
'kill -9' is performed on the originating station to make sure the calling
process is killed after the remote station starts the reboot task.
After doing this over the course of a few days, I start getting this message:
rsh ______ "reboot" <------an echo from my script where '______' is the
system getting rebooted
socket: all ports in use
And, of course, the task never completes. Also, performing a 'netstat -aA'
yields many lines like the following:
ff68528c tcp 0 0 ch212a.587 ch405a.shell FIN_WAIT_2
which, I assume, is telling me that the socket was allocated but not cleared
by the 'kill -9'.
I still need to do periodic reboots to clear problems with some older
software. Can anyone help, either with a way to clear the sockets (PLEASE!!)
short of a reboot of the originating system, or an alternative way to
remote-reboot stations over the net? I would appreciate it, and will
summarize.
BTW, my summary of 'NIS over subnets' has been delayed due to local net
problems, but I will summarize it as soon as they get resolved. Stay tuned!
======================================
I got replies on this one even before I received my own bounceback message!
Pretty slick! The replies are short enough for me to bounce them to
everyone. I know there will be more, but I have my answer. If something
important comes along that needs to be appended, I will do a second summary.
----------------------------
Joel,
Have you tried using a cron job on each machine? This would let each
machine reboot itself and not involve remote shells that might hang.
Dan
>>>NOTE: I would, but I can't always do it on a set schedule. -jls <<<
================
> After 10 seconds, a 'kill -9' is performed on the originating station
> to make sure the calling process is killed after the remote station
> starts the reboot task.
Why are you leaving the socket open? Why try to do a kill of the rsh?
Run it completely in the background -
rsh hostname -n "/usr/etc/reboot >& /dev/null &"
>>>NOTE: I tried this one immediately, and it worked! I tried a variant of
it at one time, but didn't direct standard out to /dev/null...
-jls
<<<
Run it using a shellscript and rdist -
rdist -f distfile
distfile:
CLIENTS = (hostname1 ... hostnameN)
COMMAND = (reboot.sh)
clients:
${COMMAND} -> ${CLIENTS}
install -y /tmp;
special ${COMMAND} "/tmp/reboot.sh 1>/dev/null 2>&1" ;
reboot.sh:
#!/bin/sh
/usr/etc/reboot
> I still need to do periodic reboots to clear problems with some older
> software.
Why not just write a script to clear up the problems created by "some
older software" rather than rebooting the systems?
>>>NOTE: I couldn't. Even the companies in question didn't help much as
the software was old... -jls<<<
Aydin Edguer
-----------------------------
I'm not sure if i quite understand your request, however, it appears to
me that you are having to 'kill' rsh procs for remote reboot, because you
aren't throwing the 'rsh's out correctly.
A remote reboot process like:
rsh -n reboothost '( reboot ) < /dev/console >& /dev/console' \
</dev/null >&/dev/null
should work by disassociating controlling stdio from the 'rsh', and
ensuring
the remote shutdown is attached to the console, and not the 'rsh'
stream.
Thus, the originating process will complete almost imediately, and not
hang around.
(i *think* this is what you're asking)
--stephen
===========================
I have not had any replies concerning how to clear stuck sockets... any
advice welcome. It may come in before this summary reaches everyone. If
any info follows, I will summarize it as well.
Thanks to the following and any other posters later:
Dan Zegarac (zegarac@gdls.com)
Aydin Edguer (edguer@alpha.ces.cwru.edu)
Steven Dowdy (dowdy@bruno.cs.colorado.edu)
Joel L. Seber | Dry humor is wasted around here.
SUN Workstation Laboratory Manager |
Center for Manufacturing Research | -Joel L. Seber
and Technology Utilization |
Tennessee Technological University | recursive, adj.
Cookeville, TN 38505 | See 'recursive'
|
jls2013@tntech.edu |
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:08:31 CDT