•  

Announcement

Announcement Module
Collapse
No announcement yet.

unauthenticated user

Page Title Module
Move Remove Collapse
Conversation Detail Module
Collapse
  • Page of 1
  • Filter
  • Time
  • Show
Clear All
new posts

  • unauthenticated user

    #1
    Hi All,

    I'm looking at our show full processlist and am seeing in the "User" column:

    unauthenticated user

    We have several application servers connecting to the database and it seems to primarily be coming from one of these servers, although I just so it from another one, but that does not happen that often.

    The hosts files are updated so its unclear what this is?

    Is there a way to find out more information?

    Thanks
    Tags: None

  • #2
    this is DNS issue, start mysql with --skip-name-resolve

    Comment


    • #3
      Is there a way to turn that option on in a production environment? how do I add it to the configuration file?

      Comment


      • #4
        simply add skip-name-resolve in my.cnf

        Comment


        • #5
          What I'm not clear on, is that this issue does not seem to be a name resolution issue so I'm not sure why the skip-name-resolve option would solve it.

          Here's an example of what the show full processlist command shows regarding this issue, as you can see, "s5" was resolved correctly, its the username column that's not clear?

          Is it just because it hasn't actually authenticated yet?


          | 14462476 | unauthenticated user | s5:42320 | NULL | Connect | NULL | Reading from net

          Comment


          • #6
            THere isn't really an easy way to find out what it is. Usually it's DNS lookups and can be fixed with skip_name_resolve but sometimes other parts of the login process can cause it, such as a slow network between the server and client.

            Comment


            • #7
              Thanks for the advise. We've turned off name resolution (skip-name-resolve).

              Based on other recommendations, we've updated our wait_timeout and interactive_timeout values which were set at 10 and 10. They are now set at 30 and 600.

              These low values probably explain why we were constantly being disconnected from the data server (i.e. connection closed) even in command line interactive mode. This may also be the culprit of the "admin quit" showing up in the slow query log.

              I'm going to watch the situation for the next few days post update and see how it goes.

              Comment

              Working...
              X