Ubuntu – How to identify the program that has written information to a log file

12.04authenticationlogsudo

I recently got a message that something had failed to sudo on my Ubuntu laptop. At the time, I don't believe I was running anything that would need sudo. The messages that appeared in /var/log/auth.log are:

Jul 16 11:50:56 laptop sudo: pam_unix(sudo:auth): conversation failed
Jul 16 11:50:56 laptop sudo: pam_unix(sudo:auth): auth could not identify password for [mv]
Jul 16 11:50:56 laptop sudo: pam_unix(sudo:auth): conversation failed
Jul 16 11:50:56 laptop sudo: pam_unix(sudo:auth): auth could not identify password for [mv]
Jul 16 11:50:56 laptop sudo: pam_unix(sudo:auth): conversation failed
Jul 16 11:50:56 laptop sudo: pam_unix(sudo:auth): auth could not identify password for [mv]
Jul 16 11:50:56 laptop sudo: mv : 3 incorrect password attempts ; TTY=unknown ; PWD=/home/mv ; USER=root ; COMMAND=/usr/bin/env -u LANGUAGE LC_MESSAGES=C /bin/sh /tmp/tmpBHXhYV/:script:

The similarity to the log in this question makes me think this was generated by update-manager.

Is there a way to confirm whether it was update-manager or another program that caused this error to be logged to /var/log/auth.log? Alternatively, has anyone seen this particular sequence of log lines before?

Thanks for your help.

Edit:

  • /tmp/tmpBHXhYV/ directory no longer exists
  • From what I can see, while update-manager is running, it creates these /tmp/tmpXXXXXX/ directories (where the X's are random). To clarify my question somewhat, I'd like to know if/how I can directly reference something in the update-manager code that generates lines of this format. I've had a look through the source code for my update-manager version, but wasn't able to work this out.

Thanks again!

Best Answer

  • Well, your pasted data has all some useful info: COMMAND=/usr/bin/env -u LANGUAGE LC_MESSAGES=C /bin/sh /tmp/tmpBHXhYV/:script:

    So env was called to execute ~/tmp/tmpBHXhYV/:script:` with sh. If that file is still there, it might help you. It was not called from a TTY, so probably from within another running application.