[SERVER-4754] Profiling silently fails with --auth Created: 24/Jan/12 Updated: 29/Jul/14 Resolved: 21/May/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Security |
| Affects Version/s: | 2.0.1 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Minor - P4 |
| Reporter: | A. Jesse Jiryu Davis | Assignee: | Unassigned |
| Resolution: | Done | Votes: | 3 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Mac OS X 10.7, 64-bit |
||
| Attachments: |
|
||||||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||||||
| Operating System: | OS X | ||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||
| Description |
|
It seems that when I start a mongod with --auth, then do db.setProfilingLevel(2) and a find(), nothing is stored in system.profile. Repeating the same test without --auth succeeds. I run the attached test_profile.sh against a mongod started with and without auth: $ mongod --dbpath ./data/db4000 --port 4000 --logpath ./log/db4000.log --fork find { "_id" : ObjectId("4f1ee0ca17b5b6b96b6ec15d") }setting profiling level to 0 { "was" : 2, "slowms" : 100, "ok" : 1 }db.system.profile.find() , "ntoreturn" : 1, $ mongod --dbpath ./data/db4000 --port 4000 --logpath ./log/db4000.log find { "_id" : ObjectId("4f1ee0bd5f245c46ab557b47") }setting profiling level to 0 { "was" : 2, "slowms" : 100, "ok" : 1 }db.system.profile.find() |
| Comments |
| Comment by Andreas Nilsson [ 21/May/14 ] |
|
With the reduction of the localhost exception in 2.7.1 there will be no profilable options when running in --auth mode without users. |
| Comment by Githook User [ 16/May/14 ] |
|
Author: {u'username': u'estolfo', u'name': u'Emily Stolfo', u'email': u'emily@mongodb.com'}Message: Skip tests with 2.0 relying on profiling info until |
| Comment by Andy Schwerin [ 01/Mar/12 ] |
|
After a little investigation, it appears that this problem is limited to the case where there are no users set up on the admin database, and so all connections from localhost are permitted. In this scenario, the auth-check logic creates a read context for verifying that there are no users in the "admin" database, and this context has the unfortunate problem of clearing the curOp's "_dbprofile" level, which controls whether or not the op gets profiled at the end. A solution could be to set the _dbprofile to the max value seen while processing the operation, but a more satisfying solution may have to wait. |
| Comment by auto [ 09/Feb/12 ] |
|
Author: {u'login': u'', u'name': u'A. Jesse Jiryu Davis', u'email': u'jesse@10gen.com'}Message: Skip test_profiling_info until |