# unauthenticated user

**URL:** <https://forums.percona.com/t/unauthenticated-user/1518>\
**Category:** Other MySQL® Questions\
**Created:** [September 28, 2010, 9:18am UTC](https://forums.percona.com/t/unauthenticated-user/1518 "2010-09-28T09:18:16Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![iberkner](https://avatars.discourse-cdn.com/v4/letter/i/c67d28/32.png) [@iberkner](https://forums.percona.com/u/iberkner)\
**Post date:** [September 28, 2010, 9:18am UTC](https://forums.percona.com/t/unauthenticated-user/1518/1 "2010-09-28T09:18:16Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![yogesh77](https://avatars.discourse-cdn.com/v4/letter/y/f08c70/32.png) [@yogesh77](https://forums.percona.com/u/yogesh77)\
**Post date:** [September 28, 2010, 9:25am UTC](https://forums.percona.com/t/unauthenticated-user/1518/2 "2010-09-28T09:25:57Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![iberkner](https://avatars.discourse-cdn.com/v4/letter/i/c67d28/32.png) [@iberkner](https://forums.percona.com/u/iberkner)\
**Post date:** [September 28, 2010, 9:29am UTC](https://forums.percona.com/t/unauthenticated-user/1518/3 "2010-09-28T09:29:24Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![yogesh77](https://avatars.discourse-cdn.com/v4/letter/y/f08c70/32.png) [@yogesh77](https://forums.percona.com/u/yogesh77)\
**Post date:** [September 28, 2010, 9:34am UTC](https://forums.percona.com/t/unauthenticated-user/1518/4 "2010-09-28T09:34:57Z")

</div>

simply add skip-name-resolve in my.cnf

---

<div class="post-metadata">

**Author:** ![iberkner](https://avatars.discourse-cdn.com/v4/letter/i/c67d28/32.png) [@iberkner](https://forums.percona.com/u/iberkner)\
**Post date:** [September 28, 2010, 10:07am UTC](https://forums.percona.com/t/unauthenticated-user/1518/5 "2010-09-28T10:07:27Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![xaprb](https://avatars.discourse-cdn.com/v4/letter/x/49beb7/32.png) [@xaprb](https://forums.percona.com/u/xaprb)\
**Post date:** [September 29, 2010, 4:23pm UTC](https://forums.percona.com/t/unauthenticated-user/1518/6 "2010-09-29T16:23:34Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![iberkner](https://avatars.discourse-cdn.com/v4/letter/i/c67d28/32.png) [@iberkner](https://forums.percona.com/u/iberkner)\
**Post date:** [September 29, 2010, 10:25pm UTC](https://forums.percona.com/t/unauthenticated-user/1518/7 "2010-09-29T22:25:34Z")

</div>

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.
