[SERVER-8118] serverStatus locks and recordStats have invalid text in keys Created: 09/Jan/13 Updated: 25/Sep/14 Resolved: 25/Sep/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | HTTP Console |
| Affects Version/s: | 2.2.2 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | Morris Jones | Assignee: | Ramon Fernandez Marina |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||
| Issue Links: |
|
||||||||
| Operating System: | Linux | ||||||||
| Participants: | |||||||||
| Description |
|
I discovered this problem while trying to solve a problem with a Nagios MongoDB monitoring plugin that was returning "CRITICAL - General MongoDB Error: 'utf8' codec can't decode bytes in position 0-1: illegal encoding" while checking several MongoDB statistics from the serverStatus command. See the attached output from serverStatus using a browser. First note the interesting and large array of fields in "locks" and "recordStats". The documentation doesn't explain that. Note near the bottom of each field alphabetically there are several keys that appear to be binary and possibly badly encoded. I'm supposing that these badly formed strings are breaking the python string codec in the monitoring plugin. Restarting the mongodb instance resolves the issue by removing nearly all of the locks and recordStats. |
| Comments |
| Comment by Ramon Fernandez Marina [ 25/Sep/14 ] |
|
Hi morrisjones, this is to let you know we're closing this old ticket. The issue of restricting the names and encodings that can be accepted by MongoDB is being discussed in Regards, |
| Comment by Morris Jones [ 09/Jan/13 ] |
|
I think I know the source of the bad data. I suspect it's coming from an automated security scan generated internally. (I'm at Disney.) The http interface is useful, but given no other workaround for this problem, I certainly will have to turn it off. Unfortunately I don't know enough Python to make the monitoring plug-in tolerant of malformed strings in the json. |
| Comment by Tad Marshall [ 09/Jan/13 ] |
|
If you don't have a need for the HTTP interface, you can turn it off with --nohttpinterface on the mongod command line. This should prevent a recurrence of this problem. Even over the normal interface, strings are not checked for UTF-8 validity unless --objcheck is turned on, so I'm not surprised that garbage sent to the HTTP interface could result in invalid UTF-8. |
| Comment by Morris Jones [ 09/Jan/13 ] |
|
Thanks for mentioning that. I really wanted to know how all that garbage data could have been generated. This sample log is one of about a dozen servers in development space. The HTTP access is open, but the machines do not have public visibility. They're on a private network behind a VPN. |
| Comment by Tad Marshall [ 09/Jan/13 ] |
|
This json file is full of "<script> alert" fragments, and it looks like the set of collections contains a lot of garbage. Do you allow access to the HTTP interface and is it possible that the REST interface has been inadvertently used to flood the server with bogus collection names? Names like "_vti_cnf" suggest FrontPage extensions, as if someone tried to update the HTTP URL with an update intended for another server. |