Home / ubuntu / Questions / 398143
In Process
cprofitt
Asked: 2014-01-01 06:30:51 +0800 CST

What log files should be examined to troubleshoot shutdown issues in relation to USB devices?

  • 772

I am currently having the following issue:

Close lid of laptop - laptop suspends Open lid of laptop - laptop resumes Select Shutdown from menu - computer reboots

Suspend computer from menu - laptop suspends Press key on keyboard - laptop resumes Select Shutdown from menu - computer shuts down

Suspend computer from menu - laptop suspends Close laptop lid - no action Open lid of laptop - laptop resumes Select Shutdown from menu - computer reboots

I have looked at dmesg, kern.log, pm-suspend.log but not found any information that appears useful. While this may be a bug I would still like to know what log files I should be examining.

UPDATE: 12/31/2013

This issue is related to having an Anker USB 3.0 hub attached to the laptop. The problem does not happen unless the hub is attached. Not sure why the USB hub would be an issue, but there is some interaction between this USB hub and suspend/resume.

UPDATE: 1/2/2014

It appears that the issue is just using the USB 3.0 port. I am wondering how to check and see what settings a USB hub gets in regards to being able to wakeup the computer. Perhaps the hub is getting set incorrectly on resume.

usb

1 Answers

  1. You seem to be assuming that there are a) log files and b) that those log files are persistent, or at the very least, rotated, rather than deleted at reboot or log in time.

    Identifying which log file to look for is difficult, because you'd need to know which process or component is actually causing the problem. For example, it could simply be a bug on the client side, and not a system level process. The problem could be in gnome-session, gnome-settings-daemon, or indicator-session on the client side, none of which I think have log files, or necessarily use extensive logging in their code. They seem to just dump any warnings or log messages that occur, to STDERR or STDOUT, so you'd need to look at ~/.xsession-errors to see what they output. However, that file is replaced every time you log in, and I do not know that if it is rotated or not. You can enable more verbose logging by ensuring that G_MESSAGES_DEBUG=all is set in the environment, by exporting in ~/.profile or in a file added in the /etc/profile.d/ directory. It may or may not give you more information where you want it, though.

    The best thing you can do in these situations is to first file a bug in the highest level component (where you're making the clicks, in this case, the indicator-session package), and see if the maintainers/developers can perform the same actions to get the same results, and work downward to the lower levels from there, with their help.

    • 0