1752315 Members
5488 Online
108786 Solutions
New Discussion юеВ

Re: DEVLISTFULL

 
SOLVED
Go to solution
matthew robey
Frequent Advisor

DEVLISTFULL

VMS 7.3-2 Decnet V over TCPIP V5.4 eco 4.

Each VMS system has dual nics configured with
seperate ip addresses and IP failover.

When I do:

$ set displ/node="192.168.xx.xx" /transp=tcpip/create/perm
%SYSTEM-F-DEVLISTFULL, device unit limit reached; no unit added

Whilst this is a for terminal creation, Oracle listener (for example) cant create anymore processes.

Had to reboot to workaround the problem.

$ sysconfig -q net
net:
arpkillc = 1200
arpkilli = 180
arprefresh = 120
arpunicast = 1
ifqmaxlen = 1024
lo_devs = 1
lo_def_ip_mtu = 4096
nslip = 0
ovms_unit_count = 208
ovms_unit_creates = 9369551
ovms_unit_fast_credel = 1
ovms_unit_limit = 32766
ovms_unit_minimum = 2
ovms_unit_maximum = 32767
ovms_unit_seed = 18969

Anyone any ideas ?

Thanks,

Matt
13 REPLIES 13
Volker Halle
Honored Contributor

Re: DEVLISTFULL

Matt,

it looks like you've reached the maximum number of BG devices on your system. Should be 32767 on OpenVMS V7.3-2.

$ SHO DEV BG[/FULL] should show them all, $ TCPIP SHOW DEV[/FULL] should list their TCPIP attributes.

Maybe some process is creating and not freeing/deassigning those devices (sockets). You should watch the no. of BG devices in your system to find, if the no. of devices is constantly growing. Then try to find out who is using them:

$ pipe show dev bg | search/stat sys$pipe bg/noout
(look for Records matched count).

Volker.
Volker Halle
Honored Contributor
Solution

Re: DEVLISTFULL

Matt,

next time this happens, force a crash (>>> CRASH) instead of just rebooting your server. Then you have enough time to dig through the crash to find out, who/what's using up all your BG devices (or is not freeing them).

As already said, you can probably pro-actively watch the no. of BG devices and take action, before they reach 32767...

Volker.
Wim Van den Wyngaert
Honored Contributor

Re: DEVLISTFULL

To watch the number of connections :

ana/sys
tcpip show inet/stat
(the line with sockets)

I monitor this number and alarm myself when it gets above 600, which is high for us.

At our side it means a program had connections problems and tried to open new connections without closing the old ones.
A restart of the program solves the problem (has been corrected years ago but not yet in production).

Wim
Wim
John Gillings
Honored Contributor

Re: DEVLISTFULL

Matt,

If you can identify "dead" BG devices, you may be able to recover without rebooting or even restarting TCPIP using:

TCPIP> DISCONNECT DEVICE BGnnnn

Of course, how to identify them may be non-trivial...

Please log a case with your customer support centre for deeper diagnosis.
A crucible of informative mistakes
matthew robey
Frequent Advisor

Re: DEVLISTFULL

Unfortunately I think I'll need to log a call.

As displayed in the sysconfig -q net, the number of bg devices is actually very low (208), and yet Oracle cannot create a TNS listener process.

Matt
Volker Halle
Honored Contributor

Re: DEVLISTFULL

Matt,

do you 'believe' that ovms_unit_count value at any time ?

Test is with a couple of

$ sysconfig -q net
$ pipe ucx sho dev | sea sys$pipe bg/noout/stat

and look for differences. Maybe ovms_unit_count does not reflect ALL BG devices ?

What do you expect from opening a call, if you have no 'hard evidence', i.e. a forced crash or at least a SHOW DEV BG/FULL from that situation ?

Volker.
Brian Reiter
Valued Contributor

Re: DEVLISTFULL

Could this be related to the CHANNELCNT parameter in SYSGEN?

I know we had to up this past the default of 256.
Volker Halle
Honored Contributor

Re: DEVLISTFULL

Brain,

the SYSGEN parameter CHANNELCNT limits the no. of channels an individual process can assign.

The system service status SS$_DEVLISTFULL is returned, if you attempt to create a new (BG) device and the maximum no. of active (BG) devices has been reached. In OpenVMS V7.3-2, this limit has been increased from 9999 to 32767.

Volker.