Awesome window manager stops recognizing shortcuts

Question

I recently started using Awesome (the X windows manager) in my Ubuntu. It is awesome! But some times (once a day max) it kinda crashes — or at least stop accepting shortcuts input. I get stuck on the workspace (tag, I belive they call it) I am. Clicking on the other ones, or using Mod4+numbers won't work. It simply stops listening. If I type mod4+j, it types j, as if only the awesome's keylistener had aborted or something. But everything runs fine in the current workspace, the awesome UI still render on the top, and even the clock keeps ticking!

The only thing left to do is to manually shut down the machine, as I can't even turn it off properly... I have no idea what is going on. It might as well be a shortcut to disable all shortcuts or something that I eventually accidentally type, or a weird semi-crash, but I've searched Google a lot for references and found nothing. Does anyone have a clue on what happens and how to fix it (or better yet, prevent from happening)?

Answer 1

Going by your description, the window manager hasn't crashed: it's still responding to window-related events, the problem is that it is no longer detecting keyboard events.

What is probably happening is that your keyboard configuration has changed in a way that awesome doesn't recognize. Check that ignore_modifiers is set correctly: if it's missing Lock or your NumLock modifier, then your keyboard and mouse shortcuts won't work while Caps Lock / Num Lock are on. Also, check that the key that you think sends Mod4 is still sending that modifier.

To check what your keyboard is sending, run the command xev in a terminal and press keys in the xev window. If you press A then you should see something like

KeyPress event, serial 33, synthetic NO, window 0x4a00001,
    root 0xab, subw 0x0, time 291526925, (443,-11), root:(454,44),
    state 0x0, keycode 38 (keysym 0x61, a), same_screen YES,
    XLookupString gives 1 bytes: (61) "a"
    XmbLookupString gives 1 bytes: (61) "a"
    XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x4a00001,
    root 0xab, subw 0x0, time 291527038, (443,-11), root:(454,44),
    state 0x0, keycode 38 (keysym 0x61, a), same_screen YES,
    XLookupString gives 1 bytes: (61) "a"
    XFilterEvent returns: False

If you see a state that's different from 0x0 then some modifier is on, for example 0x2 indicates that Caps Lock is on. When you press the Mod4 key, the state should change to 0x40.