How to really shutdown TCPIP services ?

NFS couldn't be started, but there was still:

TCPIP SHOW DEVICE:[color=blue]
> Port Remote
> Kernel_socket Type Local Remote Service Host
>
> 1.1 STREAM 2049 0 *
> 1.2 DGRAM 2049 0 NFS *[/color]


And netstat still showed "something" was listening to 2049. And
telnet/port=2049 would still connect and evehtually issue some NFS error
(even though NFS was shutdown/disabled).

Normally, one can use TCPIP DISCONNECT DEVICE BGxxxx where BCxxxx is
part of the SHOW DEVICE output. Does anyone know if there is a way to
disconnect/remove/kill/euthanise/decapitate those "kernet socket" 1.1
and 1.2 ?


Similarly, I tried to shutdown TCPIP Services, but the TCPIP$INETACP
refused to go away. It ignored STOP/ID STOP/IMAGE as well as the TCPIP
services shutdown procedure. And since it was still there, TCPIP$STARTUP
would fail.

Any idea how to really kill off that process ?


In the end, I had to do what Windows users do: REBOOT.

(Alpha VMS 8.3 TCPIP services 5.5)

On 23 Apr, 15:47, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:[color=blue]
> NFS couldn't be started, but there was still:
>
> TCPIP SHOW DEVICE:
>[color=green]
> > * * * * * * * * * * * * * *Port * * * * * * * * * * * Remote
> > Kernel_socket *Type * *Local *Remote *Service * * * * * Host[/color]
>[color=green]
> > * 1.1 * * * * STREAM * *2049 * * * 0 * * * ** * * * * *
> > * 1.2 * * * * DGRAM * * 2049 * * * 0 *NFS * * * * * * **[/color]
>
> And netstat still showed "something" was listening to 2049. And
> telnet/port=2049 would still connect and evehtually issue some NFS error
> (even though NFS was shutdown/disabled).
>
> Normally, one can use TCPIP DISCONNECT DEVICE BGxxxx where BCxxxx is
> part of the SHOW DEVICE output. *Does anyone know if there is a way to
> disconnect/remove/kill/euthanise/decapitate those "kernet socket" 1.1
> and 1.2 ?
>
> Similarly, I tried to shutdown TCPIP Services, but the TCPIP$INETACP
> refused to go away. It ignored STOP/ID STOP/IMAGE as well as the TCPIP
> services shutdown procedure. And since it was still there, TCPIP$STARTUP
> would fail.
>
> Any idea how to really kill off that process ?
>
> In the end, I had to do what Windows users do: REBOOT.
>
> (Alpha VMS 8.3 TCPIP services 5.5)[/color]

Presumably NFS still had something connected (or at least thought it
did), maintained the process/devices to keep NFS running so wouldn't
kill INETACP off until NFS had finished, which it never did.

[email]etmsreec@yahoo.co.uk[/email] wrote:
[color=blue]
> Presumably NFS still had something connected (or at least thought it
> did), maintained the process/devices to keep NFS running so wouldn't
> kill INETACP off until NFS had finished, which it never did.[/color]


NFS was dead. But when it died, it left something in the kernel that
made the kernel continue to think NFS was there. Because of that, NFS
couldn't restart (since port 2046 was already taken by a phantom NFS).

There was no process to kill. And when shutting down TCPIP, it would
only complain about one BG device which belonged to TCPIP$INETACP ...

On a serious system, one would expect to be able to zap NFS out of the
kernel without even having to shutdown other TCPIP services.

On a less serious system, one would expect that just shutting down TCPIP
would work and that it would be able to get rid of all traces of itself
so it could restart cleanly.

On a windows system, you'd expect to have to reboot to get a clean slate
because it just isn't possible to cleanly shutdown an app withot leaving
garbage around.

Unfortunatly, VMS acted like a windows system here.

On 23 Apr, 16:58, JF Mezei <jfmezei.spam...@vaxination.ca> wrote:[color=blue]
> etmsr...@yahoo.co.uk wrote:[color=green]
> > Presumably NFS still had something connected (or at least thought it
> > did), maintained the process/devices to keep NFS running so wouldn't
> > kill INETACP off until NFS had finished, which it never did.[/color]
>
> NFS was dead. But when it died, it left something in the kernel that
> made the kernel continue to think NFS was there. Because of that, NFS
> couldn't restart (since port 2046 was already taken by a phantom NFS).
>
> There was no process to kill. And when shutting down TCPIP, it would
> only complain about one BG device which belonged to TCPIP$INETACP ...
>
> On a serious system, one would expect to be able to zap NFS out of the
> kernel without even having to shutdown other TCPIP services.
>
> On a less serious system, one would expect that just shutting down TCPIP
> would work and that it would be able to get rid of all traces of itself
> so it could restart cleanly.
>
> On a windows system, you'd expect to have to reboot to get a clean slate
> because it just isn't possible to cleanly shutdown an app withot leaving
> garbage around.
>
> Unfortunatly, VMS acted like a windows system here.[/color]

I think that's inevitable with the way that TCP/IP integrates with
VMS. For example, there's no way of replacing the BG device driver on
a live system - the only way to replace the image is to reboot.