For the past few months, I have experienced periodic unresponsiveness of openbox, the same problem described in this post. My setup is linux 4.9.0-3-amd64, debian 9.0, openbox 3.6.1. As described in the linked post, the session will frequently (every few days) become unresponsive to certain keyboard and mouse inputs. The mouse cursor can still be observed to move across the screen and focus can be transferred to different windows, but modification of windows (movement, minimization, maximization, closing) or use of them (clicking on buttons within the window) are no longer possible (selecting text in an open xterm window by clicking and dragging is still possible). Keyboard input also fails to register: one cannot type in an open xterm emulators, nor do key bindings work (e.g., Alt+tab, custom bindings set in $HOME/.config/openbox/rc.xml). Windows still update their contents (e.g., progress of an ongoing rsync job is dynamically updated) and any jobs that were running continue to run, but interaction with the system by keyboard and mouse is severely limited. Two forms of keyboard input have been found to still work. Firstly, after the display locks (I have slock enabled with a timer by the presence of xautolock -time 60 -locker sloc in ~/.config/openbox/autostart), the screen locker accepts a password and allows resumption of the otherwise frozen X11 session. Secondly, as suggested in this answer to the linked post, Ctrl+Alt+F1 to Ctrl+Alt+F6 works (though Ctrl+Alt+Backspace does not), and I am able to login and startx from the new console, at which point I have a frozen X11/openbox session in the first X11 console (Ctrl+Alt+F1) and a functioning one in the second (Ctrl+Alt+F2). Eventually, the second X11 instance will freeze and interestingly, when this happens, the first instance unfreezes and I am able to work there again. Thus, simply alternating between two instances that periodically freeze and reciprocally unfreeze allows me to avoid having to hard-reboot the system, which was the solution before finding that Ctrl+Alt+F2-6 permits a form of system rescue (though any process with a GUI in the frozen session has to be restarted in the new session if I wish to continue using it).

I have been unable to find the cause of this problem and would appreciate any help in diagnosing it. I have been running debian/openbox for years, and this problem only happened in the last few months. Checking top after X11 freezes does not reveal any obvious problems; dmesg and /var/log/messages are unrevealing as well. I would like to find the source of the problem to prevent it from recurring.

  • There aren't many details that you have shared, for instance is this supposed to work or emulate a modem (openbox AFAIK is usually used in many modems, notably most D-Link modems have and use them in favor of something like bash or zsh due to not needing much ram.) Another query would be if you any or made any tmpfs. While it is possible that openbox or some tool of it might be leaking RAM, it is equally possible it does not have to enough RAM or tmpfs to do its work. Without more info., it would be hard to diagnose what's happening.
    – shirish
    Jan 2, 2018 at 5:41

1 Answer 1


I've also been trying to figure out what problem this is that affects the 3.6.1 version of openbox. What I could find so far is that there is an "partial" node related to mouse in your ~/.config/openbox/rc.xml file, this problem occurs. Two options I've found so far:

1 - copy the full node from /etc/xdg/openbox/rc.xml to your local one; 2 - simply remove the local file node.

Of course, if you need to change a mouse-related setting, you will need to use a first option. Do not use obconf to set up mouse actions, this will resurrect the problem.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .