Rofi (drun) stops working properly after resuming from suspend

shako · 2023-09-01 14:06:30

Interesting scenario:

I'm on sway and using rofi-lbonn-wayland-git (a rofi fork which runs natively on wayland). After I resume my system to suspend, rofi -show drun (application launcher) won't work as before (pre-suspend): applications entries appear on the menu, but selecting one of them won't launch it. Notably, this happens only for GUI applications (i.e. after resuming from suspend I can launch ranger or kitty, but not Firefox). A few things i noticed:

1) If I open a terminal and manually launch "rofi -show drun" (rather than with its keybind) it works just fine, even with GUI applications after resuming from suspend.
2) There is no significant difference in the stdout of rofi when launching a GUI app before/after suspend. Only thing, when it succeeds in launching the app (= before suspend), a fraction of the application's stdout is visible in rofi's stdout.
3) There is absolutely zero change in my environmental variables before and after suspend (the output of "env" is precisely the same).

I am personally out of ideas on how to investigate the issue more deeply. Any hint?

Best, shako

deviantsemicolon618 · 2023-09-01 18:27:06

Does

journalctl -b | grep rofi

or running rofi in a terminal give you any errors?

seth · 2023-09-01 20:06:06

kitty /is/ a GUI application, but firefox will likely default to xwayland - X11 is hostname sensitive, so please post the output of

hostnamectl

Fwwi, https://wiki.archlinux.org/title/Firefox#Wayland

shako · 2023-09-01 23:03:28

deviantsemicolon618 wrote:

Does
journalctl -b | grep rofi
or running rofi in a terminal give you any errors?

If I launch rofi -show drun from a terminal, it works just fine even after resuming from suspend. It throws a couple warnings in stdout, but no errors:

(process:1235): Modes.Window-WARNING **: 00:52:51.601: Unsupported window field name :role. Wayland window switcher supports only 'title' and 'app-id' ('class') fields

Also, I see no errors in journalctl. Here is the full output of journalctl -a | grep rofi (maybe it's useful):

https://pastebin.com/M3uSGTQ3

seth wrote:

please post the output of
hostnamectl

Here it is:

Static hostname: erebus
Icon name: computer-laptop
Chassis: laptop ?
Machine ID: 277b1bb6876a4b529c7aab644c7ce8cd
Boot ID: 62e6edd37c9f48b091cd20defc8e1a02
Operating System: Arch Linux                      
Kernel: Linux 6.4.12-zen1-1-zen
Architecture: x86-64
Hardware Vendor: Lenovo
Hardware Model: ThinkPad T490
Firmware Version: N2IETA1W (1.79 )
Firmware Date: Mon 2023-01-16
Firmware Age: 7month 2w 1d

EDIT: as you suggested @seth I think the issue might be linked to Wayland/X11, as I actually can launch a few applications even after resuming from suspend, but all of those are running natively on wayland (xeyes is not aware of the corresponding windows).

Last edited by shako (2023-09-01 23:13:02)

seth · 2023-09-02 06:29:57

You've a static hostname, so no risc there.

There is absolutely zero change in my environmental variables before and after suspend (the output of "env" is precisely the same).

But you're comparing those in the interactive shell where

I open a terminal and manually launch "rofi -show drun" (rather than with its keybind) it works just fine

the problem doesn't exist, right?

Compare the environments that rofi sees:

tr '\0' '\n' < /proc/(pidof rofi)/environ

shako · 2023-09-02 08:41:18

seth wrote:

the problem doesn't exist, right?

That's right, the problem exists only then I launch rofi -show drun from its keybind in sway, not "manually" from a terminal. I thought that maybe sway could be the culprit, but I found nothing interesting in its log...

seth wrote:

Compare the environments that rofi sees:
tr '\0' '\n' < /proc/(pidof rofi)/environ

I ran:

rofi & tr '\0' '\n' < /proc/$(pidof rofi)/environ

And once again the two outputs are identical. Here they are:

https://pastebin.com/fLvVjbuE

seth · 2023-09-02 11:15:55

rofi & tr '\0' '\n' < /proc/$(pidof rofi)/environ

Pastebin is 404 and of course you do *not* want to run rofi from the interactive shell but launch it via the shortcut because that's gonna be the most interesting environment.

shako · 2023-09-02 11:57:13

seth wrote:

rofi & tr '\0' '\n' < /proc/$(pidof rofi)/environ
Pastebin is 404 and of course you do *not* want to run rofi from the interactive shell but launch it via the shortcut because that's gonna be the most interesting environment.

Eheh, you are right. Unfortunately, rofi grabs all inputs from mouse and keyboard, so I did this:

sleep 5 && tr '\0' '\n' < /proc/$(pidof rofi)/environ

and launched rofi from my keyboard shortcut immediately after.

Here's diff pre_suspend.txt post_suspend.txt:

13c13
< DESKTOP_STARTUP_ID=5c5b272f41cd621cadfba1dce8b3a351
---
> DESKTOP_STARTUP_ID=78302be3e8dfa88206062511a08b56f6
22c22
< XDG_ACTIVATION_TOKEN=5c5b272f41cd621cadfba1dce8b3a351
---
> XDG_ACTIVATION_TOKEN=78302be3e8dfa88206062511a08b56f6

Last edited by shako (2023-09-02 12:01:16)

seth · 2023-09-02 12:04:56

That's probably not relevant

Can you launch

bash -c 'xterm >> /tmp/rofi.dbg 2>&1'

from rofi?
If not, /tmp/rofi.dbg might now tell us what's wrong.

shako · 2023-09-02 12:24:30

seth wrote:

Can you launch
bash -c 'xterm >> /tmp/rofi.dbg 2>&1'
from rofi?
If not, /tmp/rofi.dbg might now tell us what's wrong.

Launched rofi in run mode and ran the command you mentioned. The content of /tmp/rofi.dbg is:

xterm: cannot load font "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1"

But I don't think it's relevant...

Last edited by shako (2023-09-02 12:25:14)

seth · 2023-09-02 13:59:15

But xterm didn't start either?
Do you get the same error when running xterm from an interactive shell?

shako · 2023-09-02 14:21:48

seth wrote:

But xterm didn't start either?
Do you get the same error when running xterm from an interactive shell?

No no, xterm started normally in both cases. And yes, same error from the interactive shell.

seth · 2023-09-02 14:40:22

Launched rofi in run mode

Via the problematic sway shortcut?
Since you changed the context, does just running "/usr/bin/xterm" from the "bad" rofi instance start xterm (where using the xdg desktop service fails)?

shako · 2023-09-03 07:50:16

Ok. I fixed the issue but have absolutely no idea how nor why.

For debugging purposes, I changed the command assigned to rof's keybind in my sway config from "rofi -show drun" to "rofi -show drun > ~/rofi.log 2>&1". And now magically, rofi works flawlessly even after resuming from suspend. Does this give you any insight?

Back to your previous question: to launch rofi -show run from the problematic sway shortcut (as you asked before), I changed rofi's keybind in my sway config "rofi -show drun" to "rofi -show run" in my sway config. But, pressing the keybind would cause rofi (in run mode) to briefly flash on the screen before crashing almost immidiately. Redirecting stdout/stderr to a file (= changing the keybind's command to "rofi -show run > ~/rofi.log 2>&1" fixed everything even this time.

I then ran used the sway shortcut to launch "rofi -show run > ~/rofi.log 2>&1" in my system resumed from suspend, and then launched /usr/bin/xterm from that instance of rofi. Once again, I think the log doesn't say anything meaningful:

(process:11210): Helpers.IconFetcher-WARNING **: 09:47:39.011: Failed to load image: Failed to open file “context.lua”: No such file or directory
xterm: cannot load font "-misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1"

I'd still like to investigate this more deeply and understand the reason behind the issue, if you're up to. I don't think it's specific to this particular machine: I have a similar setup on another machine (ThinkPad t460s) and got the same issue in the past, which got fixed simply by redirecting sway's stdout/stderr to a file (which didn't work this time)... I wasn't able to understand which the actual issue was even back then.

Last edited by shako (2023-09-03 07:54:13)

seth · 2023-09-03 10:55:16

The significant change would be the stdout condition, you could try "rofi -show drun > /dev/null 2>&1" instead as well.
Notably (reading on your post b/c of

which got fixed simply by redirecting sway's stdout/stderr to a file

Though why that would only impact xwayland clients is beyond me, perhaps the problem is that only they (systematically) generate output ("cannot load font…")?
Did you check the contents of the log?

As for getting sway into this, did you try to close its stdin or feed it "< /dev/null"?

shako · 2023-09-06 09:55:33

Ok, here I am. Sorry for replying now.

seth wrote:

The significant change would be the stdout condition, you could try "rofi -show drun > /dev/null 2>&1" instead as well.

That's exctly what I changed my rofi keybind to, and works flawlessly now.

seth wrote:

Though why that would only impact xwayland clients is beyond me, perhaps the problem is that only they (systematically) generate output ("cannot load font…")?
Did you check the contents of the log?

It seems to me that wayland clients generate stdout as well. But even assuming you are right, and the problem is in fact stdout, I still don't understand how and why resuming from suspend would enter the equation.

seth wrote:

As for getting sway into this, did you try to close its stdin or feed it "< /dev/null"?

That's curious. I will later try to resume my original rofi keybind (without stdout/stderr redirection) and feed "< /dev/null" to sway i my session manager. Thanks!

Arch Linux

#1 2023-09-01 14:06:30

Rofi (drun) stops working properly after resuming from suspend

#2 2023-09-01 18:27:06

Re: Rofi (drun) stops working properly after resuming from suspend

#3 2023-09-01 20:06:06

Re: Rofi (drun) stops working properly after resuming from suspend

#4 2023-09-01 23:03:28

Re: Rofi (drun) stops working properly after resuming from suspend

#5 2023-09-02 06:29:57

Re: Rofi (drun) stops working properly after resuming from suspend

#6 2023-09-02 08:41:18

Re: Rofi (drun) stops working properly after resuming from suspend

#7 2023-09-02 11:15:55

Re: Rofi (drun) stops working properly after resuming from suspend

#8 2023-09-02 11:57:13

Re: Rofi (drun) stops working properly after resuming from suspend

#9 2023-09-02 12:04:56

Re: Rofi (drun) stops working properly after resuming from suspend

#10 2023-09-02 12:24:30

Re: Rofi (drun) stops working properly after resuming from suspend

#11 2023-09-02 13:59:15

Re: Rofi (drun) stops working properly after resuming from suspend

#12 2023-09-02 14:21:48

Re: Rofi (drun) stops working properly after resuming from suspend

#13 2023-09-02 14:40:22

Re: Rofi (drun) stops working properly after resuming from suspend

#14 2023-09-03 07:50:16

Re: Rofi (drun) stops working properly after resuming from suspend

#15 2023-09-03 10:55:16

Re: Rofi (drun) stops working properly after resuming from suspend

#16 2023-09-06 09:55:33

Re: Rofi (drun) stops working properly after resuming from suspend

Board footer