Too Many HTML Connections Message

[waynes]

When trying to access a controller through System Manager, I am getting the message "Too many HTML connections".  Has anybody else seen this?  Is there a way to determine who or what connections are connected to the filer through http or https?

[chris_hague]

I'm being told it's fixed in 8.1.2 but that there is no ETA for that

We are nearly at the 1 year anniversary of this issue starting. At this rate I will be buying a cake & a candle!!

[chris_hague]

Out of interest, the BURT states;

"One sign of a pathological case (requiring scheduled reboot) is of the form:

"The maximum number of administrative http connections specified by

httpd.admin.max_connections has been exceeded"

(and raising that connection limit will only increase the depth of the hold that can be dug."

What are other people using as the setting for this value? I'm sure we were advised to raise the limit to 1023, but I'm wondering if lowering it back to 512 may help?

[felixschroeder]

Hi,

I hit the bug 552607 today. I tried every workaround, nothing helped. But a reboot of the filer was not possible.

When every workaround written down in this thread you might use the System Shell, you have to unlock the diaguser before.

Beware, this is unsupported. If anything goes wrong, NGS will not help you.

filer> priv set diag; useradmin diaguser unlock; useradmin diaguser password

Set a password w/ 8 chars.

filer*> systemshell

Login with diag:password

sudo -s

bash-3.2# ps auwx|grep

httpd www     1662  0.0  2.4 26084 13748  ??  Ss   Fri05PM   0:00.68 /sbin/httpd -X -DHTTPEnabled -k start root   36798  0.0  0.1   468   292  p0  R+    9:23AM   0:00.00 grep httpd

bash-3.2# kill -9 1662

Wed Jul  4 09:23:56 CEST [filer03b:spm.httpd.process.exit:error]: The web server (httpd) with ID 1662 exited as a result of signal 9. This server will attempt to restart.

bash-3.2# ps auwx|grep httpd

www    36799  0.0  2.4 26084 13932  ??  Ss    9:23AM   0:00.74 /sbin/httpd -X -DHTTPEnabled -k start root   36822  0.0  0.2  3268   948  p0  S+    9:24AM   0:00.00 grep httpd

TL;DR: Killed the httpd process, everything works now.

Cheers,

Felix

[shane_williams]

Hi Ben,

Are you able to confirm that this issue has been resolved  in DOT 8.1.2 RC2 ?

Cheers,

Shane.

[joekr1234]

@ Chris..  Over a year?  That's absurd.  Your sales rep should be buying you the cake (as well as a steak dinner!)

I'll try dropping mine down to 512 (currntly I believe I've got it set to 1023)..  but I don't think it's going to matter.  I watched this on/off for a day a couple of weeks back and it kept bouncing up and down.

[chris_hague]

Yeah, first reported on 16/09/2011 to netapp after we upgraded from 7.3.2 to 8.x ... Their advice then was to raise the httpd.admin.max_connections to 1023.

Been ongoing ever since.

Dropped it back down to 512 now and will see if makes any difference...

[joekr1234]

I dropped mine down and it made no difference.  Initially I could get into the GUI, but then it would go unresponsive and that was the end of the show...

[mcgue]

Can everyone who has posted here ensure that 1) you have a support case with NetApp that reflects this problem and 2) that the support engineer has associated the case with this bug (552607)?  The cases associated with a bug are visible and weighted in the details the engineering team sees and helps in the decision making process on release.  Thank you.

[brauntvr2swiss]

Hi All

We run yesterday in the same Problem with 8.0.2P3 and OnCommand 5.0.. Our Solution (short Version) was to set following Option in DFM:

dfm options set snapDeltaMonitorEnabled=no

Hope this help others to fix the Issue

regards,

Thomas

[chris_hague]

@braunt-vr2swiss

Many thanks for updating us with your findings..
I dont want to tempt fate, but since setting;

dfm options set snapDeltaMonitorEnabled=no

We haven't had an SMVI failure and httpstat -s is at 0 every time I have checked it.

I'll let you know if anything changes.

Chris.

[chris_hague]

Not even 1 week after implementing this workaround, SMVI has started misbehaving again. Sporadic snapshots being taken at odd times and jobs being stuck in the VC task list for 12 hours+

It's definitely better than it was, but is still not reliable enough to call it a fix.

Hoping 8.1.2 will bring better results....

[mcgue]

Chris,

I would suggest two things.  First, open a technical case for SMVI.  Let's ensure SMVI isn't having a unique problem outside of this issue.  Second, take a look at the auditlog file in the /etc/log directory.  It takes a little massaging, but you can pull the different HTTP connections that occurred in the log.  Are they all expected connections from all expected source IP addresses?

[1netapp4me]

-sh-3.2$ dfm options set snapDeltaMonitorEnabled=no

Changed enable snapshot-delta-info API use to 0.

-sh-3.2$

Applied the change to our DFM server and will see if this fixes our problems.

Thanks for the tip!

[abuchmann]

Hi Thomas

It seems like the mentioned workaround has solved the problem for us. Thank you!

kind regards,

adrian

[brauntvr2swiss]

Hi adrian

Good news from you.. Its a good thing that we have the possibillity to help each other in the community :-)..

regards,

Thomas

[gestionesan]

hi, this solutions doen't work in my case ... FAS3170 NetApp Release 8.1.1P1 7-Mode

[batkinson]

Hi All,

Just to confirm that Thomas's fix has also worked for me.

[DAVE_WITHERS]

Had this issue this morning.  Setting the httpd timeout to 30 and min connections to 1, then back to their default values fixed the issue for me.  I am monitoring to see if we actually have hit this bug or not, but so far the counters are not increasing again.  Thanks to all who contributed to this post for suggestions.

[gestionesan]

hi, this solutions doen't work in my case ... FAS3170 NetApp Release 8.1.1P1 7-Mode

[pclayton99]

We just had this problem last week on one controller within a FAS-3240 running 8.1.3/7-Mode.

The fix for us, in this instance was to put the controller into maintenance mode within Microsoft System Center Operations Manager (SCOM), after which the connections dropped to nothing. We use the Quest QMX product in conjunction with SCOM to monitor the filers.