i3: i3 hangs after unlock when resuming from suspend or waking up screen

Hello,

I’m submitting a…

[x] Bug
[ ] Feature Request
[ ] Documentation Request
[ ] Other (Please describe in detail)

Current Behavior

Sometimes, upon resuming from suspend, unlocking with i3lock, and receiving notifications which had been held until unlock, i3 hangs. I can somewhat interact with the window on the current workspace (usually Emacs) which reacts to focus changes (switching between focussed and unfocussed faces on the mode-line) but not to keyboard or mouse inputs. The time on my i3bar (i3blocks) is still running, as are most of the other blocks except some of the icons in the tray. The notifications received prior to the hang remain on screen past their expiration time and cannot be dismissed. I cannot change workspace or restart/exit i3, and it doesn’t react to SIGCONT sent from another a newly opened tty. SIGKILL kills i3 and drops me back in the original tty.

Expected Behavior

Upon resuming from suspend, unlocking with i3lock, and receiving notifications which had been held until unlock, i3 runs normally.

Reproduction Instructions

This is the first bug report I ever submit, so please bear with me as I familiarise myself with the method.

So far, I’ve encountered about 10 hangs like the one described above, and I was able to get logs for most of them (systemd journals for all of them, and i3 logs for the last 6). The problem is that I can’t find a reliable way to reproduce them. Somehow, the easiest way to reproduce the problem is to resume the computer from a long suspend session (e.g. from night to morning). However, it also happened a couple of times when waking up the screen and unlocking. As is usually the case with random hangs, it’s hard to pinpoint exactly what the issue may be. All I know is that they started happening this week. I’ve been investigating my logs, and I wasn’t able to find anything conclusive so far. My educated guess would be that it comes from an interaction between i3, my notification service (dunst with dunstify), and the update of my i3blocks via RTMIN signals. Desperate as I was for clear reproducible steps, I’ve checked in my Linux journal if I had installed or tweaked anything remotely incriminating. I’ve uncovered four possible trails: 1) modifying the DRI and TearFree options in 20-intel.conf, 2) forcing acceleration in Firefox via modifying variables in about:config 3) an overhaul of the systemd service I use for locking my laptop on screen-off and suspend, and 4) the creation of an edit-in-emacs script which required the addition of a couple of lines to my i3/config. The first three proved inconclusive, since reverting them didn’t prevent further hangs, and the change to my i3/config was so insignificant in (4) that I doubt that it’d be the culprit. At first, I suspected a repeat of #2539 or #polybar435, but SIGCONT wasn’t able to resume i3. The i3 logs didn’t speak a whole lot to me. All I can tell is that once the hang occurs, i3 does not log anything, which would seem to indicate a problem with i3 itself, hence my submitting a bug report here rather than on i3blocks or dunst. I also use the i3-gaps patch, but it seems to be reliable enough to not consider it as a player in this issue.

Environment

Output of i3 --moreversion 2>&-:

Binary i3 version:  4.15.0.1 (03-13-2018) © 2009 Michael Stapelberg and contributors
Running i3 version: 4.15.0.1 (03-13-2018) (pid 24969)rt…)
Loaded i3 config: /home/zaeph/.config/i3/config (Last modified: Sat 26 May 2018 16:08:48 CEST, 68046 seconds ago)

The i3 binary you just called: /usr/bin/i3
The i3 binary you are running: i3

i3/config The lines which have been changed within the last two weeks are the following:

for_window [title="edit-in-emacs.txt"] floating enable
for_window [title="edit-in-emacs.html"] floating enable

For now, I will only include a link to the shortest i3 log, namely the one which occured only 5 min after startx. The log is fairly large, probably because I tried to overload my notification system prior to locking my laptop to see if I could reproduce the hang. I’ve also included my systemd journal from startx until I moment I switched to tty2, which I did right after the hang happened (I’ve expunged some GPG info). i3.log (Last 10s on pastebin: i3.log) journalctl-relevant-part.log (pastebin)

- Linux Distribution & Version: Arch
- Are you using a compositor (e.g., xcompmgr or compton): No.

Please excuse me for the length of the report and its lack of pinpointing. I’m at a loss after a week of troubleshooting, and the randomness of it all makes it difficult to track on my own. I hope you’ll be able to assist me, and in the meantime, I’ll see if I can refine my investigation.

Thank you.