dmenu_run does not dissapear after command run

Quardah · 2016-01-14 18:45:07

For some reason after a certain time, dmenu_run stops removing itself once the command is sent. Then it stays for a while (about 20 seconds) and then be gone (it timeouts or something).

Killing x and restart it does not solves the behavior. I have to reboot entirely.

I summon dmenu_run multiple times during the same uptime (it's my launcher) and it's bound on an unused key on my keyboard with xbindkeys if that's any help.

It there any way to prevent this behavior? Has anyone has this issue before me?

Many thanks.

sekret · 2016-01-14 21:28:03

Could you please launch dmenu_run from the command line and then see if
1. it behaves the same (that's what I'd expect)
2. if shows any output, which could be useful for us to see what's happening

I use a modified dmenu_run which basically does the same as the original and it works perfectly.

Last edited by sekret (2016-01-14 21:28:52)

Quardah · 2016-01-14 23:55:42

sekret,

It doesn't show anything at the time. I am having a hard time reproducing this bug. It happens sometimes at random.

What do you mean using a different dmenu_run? Why for?

Thanks.

Aerial Boundaries · 2016-01-15 03:07:24

- Check your .*shrc in case you made dmenu_run an alias at some point and forgot.
- Are you just using plain old dmenu or launching it via a script?
- Is it the one from the repos or a patched one from the AUR?
- Try reinstalling it or downgrading.

Last edited by Aerial Boundaries (2016-01-15 03:07:50)

Quardah · 2016-01-15 03:43:48

It's the standard dmenu_run from official repo. I do not have any alias in .bashrc

I tried reinstalling and didn't fixed it. Any more clues?

Last edited by Quardah (2016-01-15 03:55:24)

ayekat · 2016-01-15 09:21:53

Quardah wrote:

For some reason after a certain time, dmenu_run stops removing itself once the command is sent. Then it stays for a while (about 20 seconds) and then be gone (it timeouts or something).

Does the command execute immediately, even when the window still stays? Or does the execution of the command also delay?

dmenu_run is a shell script. Essentially it makes use of three things:

dmenu_path It runs through the directories in $PATH to check for executables - perhaps that one blocks at some point, e.g. due to an nfs share or something that isn't accessible. Try running it directly to see if it terminates immediately or not.
dmenu Perhaps it's buggy (unlikely). Try running it with a custom set of options, e.g.
```
printf "hello\nworld\nthese\nare\na\nfew\nselections\n" | dmenu
```
Also, try commenting out everything after `dmenu "$@"` in dmenu_run to see if it also blocks.
your shell dmenu_run pipes the selected command into the shell. Check the value of your $SHELL variable (perhaps it's launching some weird shell instead of the supposed one).

Quardah · 2016-01-16 07:58:21

ayekat,

The command is automatically executed. I can run again another instance of dmenu_run that will appear above the freezed one, and that will freeze after also instantly launching the command. I can do this on and on and on and they all freeze until i wait about 10 to 20 secondes for it to be gone.

There are no delays running the command, It's instant.

dmenu_path outputs instantly as well.

running dmenu with a set of options appears instantly with the options, and once i select one, the terminal outputs the selection and goes back to prompt while the instance of dmenu is also freeze just like any other.

My $SHELL is /bin/bash. Inside of the script after "$@" there is ' | ${shell:-"/bin/sh"} & ' which isn't the same.

I've also realized this kind of behavior only happens after the laptop wakes up. It never occurs until i close the lid then wake it up afterwards.

Last edited by Quardah (2016-01-16 07:58:44)

ayekat · 2016-01-16 14:45:00

I can't see anything wrong here - /bin/sh is just the system's default shell (on Arch, by default, it's a symlink to /bin/bash).

It doesn't block input, right? You can continue to work after the command is executed. So to me it seems to be a graphical "glitch", i.e. the dmenu-window doesn't get properly unmapped by the WM, or the area behind doesn't redraw its screen area.

On your screen, what else is in the area occupied by the dmenu window? Is it some task-/statusbar? Or the desktop? What happens if you drag a window over the area where the "blocked" dmenu remains? What WM/DE are you using?

Quardah · 2016-01-16 20:34:30

ayekat,

I am using openbox. There is only xmobar that "shares" the same area. My idea was to have xmobar up top and running dmenu would overlap the xmobar until i run a command. No other apps ever overlaps this area.

Furthermore, let's say i wake my laptop, even killing x and restarting it the same bug will occur. Both xmobar and dmenu that are on top of my screen have this issue, everything else works fine.

It looks like after i wake my laptop from sleep openbox has issues updating the graphical output on my top 28 pixels. The only way to fix this is a fresh reboot, which is a pain because i carry my laptop all day around at school. The issue persist after wake and as i said even killing x won't fix it, it requires a fresh reboot.

I think it's related to openbox. I'll try reproducing the bug with another wm.

ayekat · 2016-01-16 21:13:14

Quardah wrote:

It looks like after i wake my laptop from sleep openbox has issues updating the graphical output on my top 28 pixels.

Does xmobar cover 28 pixels or less (and if less, does the area below also show the same issues)?
Because right now, I have the impression that xmobar doesn't properly redraw itself - if it receives an XExpose event, it should redraw the areas that were previously covered by other windows. Try running dmenu without xmobar behind (or one of the two at the bottom of the screen), to see if that's the issue.

I think it's related to openbox. I'll try reproducing the bug with another wm.

I think it's not very likely that it's openbox' fault. But try it anyway, just to see.

Last edited by ayekat (2016-01-16 21:13:24)

Head_on_a_Stick · 2016-01-16 21:17:22

@OP: Are you running a compositor?

If so, does disabling it stop the problem?

Quardah · 2016-01-17 00:47:12

ayekat,

Both xmobar and dmenu_run covers exactly 28 pixels up top. Indeed i think it does not properly redraw itself for some reason after a wake. I'll try killing xmobar when the bug reproduces to see if it stops it from happening.

Head_on_a_Stick,

I have no explicitly install nor configured a compositor therefore i strongly believe i am not running one.

ewaller · 2016-01-17 01:03:30

Is the process still running? The way I suggest is to fire up htop, then set a filter for "dmenu". Then, start dmemu. Ensure that the process shows up in htop. then, hit escape and see if it goes away.

Quardah · 2016-01-17 01:09:37

ewaller wrote:

Is the process still running? The way I suggest is to fire up htop, then set a filter for "dmenu". Then, start dmemu. Ensure that the process shows up in htop. then, hit escape and see if it goes away.

Very intelligent debugging idea! Give me a moment i'll try this out.

EDIT 1 :

I have been trying very hard to reproduce the issue for the last 20 minutes or so and i just can get it to happen again (it's fairly random really). It doesn't seem to be affected by either being on AC or on battery, or running either the powersave or performance cpu governor. It's really a bummer that i can't put my finger on the root cause of this shy bug.

Stay tuned i will post the results as soon as i can get it to bug again.

I'd also like to take a line to thank you all for the efforts you put into helping me, i really appreciate.

Last edited by Quardah (2016-01-17 01:36:46)

Arch Linux

#1 2016-01-14 18:45:07

dmenu_run does not dissapear after command run

#2 2016-01-14 21:28:03

Re: dmenu_run does not dissapear after command run

#3 2016-01-14 23:55:42

Re: dmenu_run does not dissapear after command run

#4 2016-01-15 03:07:24

Re: dmenu_run does not dissapear after command run

#5 2016-01-15 03:43:48

Re: dmenu_run does not dissapear after command run

#6 2016-01-15 09:21:53

Re: dmenu_run does not dissapear after command run

#7 2016-01-16 07:58:21

Re: dmenu_run does not dissapear after command run

#8 2016-01-16 14:45:00

Re: dmenu_run does not dissapear after command run

#9 2016-01-16 20:34:30

Re: dmenu_run does not dissapear after command run

#10 2016-01-16 21:13:14

Re: dmenu_run does not dissapear after command run

#11 2016-01-16 21:17:22

Re: dmenu_run does not dissapear after command run

#12 2016-01-17 00:47:12

Re: dmenu_run does not dissapear after command run

#13 2016-01-17 01:03:30

Re: dmenu_run does not dissapear after command run

#14 2016-01-17 01:09:37

Re: dmenu_run does not dissapear after command run

Board footer