Xmonad logout when urgency hint with timer upon mod-q

[davama]

This does not happen to often but pretty annoying when it does. I had submitted a ticket on arch forum some time ago but now thought maybe come here, since im using Git xmonad.

It was a long time ago but i remember going on IRC and it was narrowed down to the urgentConfig timer causing the issue.

Basically when an urgency hint is activated and i press "mod-q" xmonad --restart i get kicked out of my xmonad session and go back to my lxdm screen.

I had tried clearing the urgent with xdotool "mod+shift+backspace" before "mod-q" but still get kicked out. Also tried clearing the hint by making the window client visible but still get booted.

This does not happen when i remove the remindWhen timer on my xmonad.hs config.

--myUrgencyConfig = urgencyConfig {suppressWhen= Visible, remindWhen = (Every (minutes 1.0))}
myUrgencyConfig = urgencyConfig {suppressWhen= Visible}

Why does this happen? Granted, how often do you restart xmonad on the fly? But when the circumstances are just right, it sucks.

Thanks Dave

[f1u77y]

the only difference related to restart is that with remindWhen = Dont it does store Reminder PersistentExtension.

couldn't you give some logs(they could be in ~/.xsession-errors)?

try to clear reminders state before restart as a workaround(not sure if it should work)

[davama]

Thank you for the reply @f1u77y Unfortunately my ~/.xsession-errors file is empty but it does get created upon login. I've tried figuring out why lxdm does not log it but no good. No the only one with this issue

try to clear reminders state before restart as a workaround(not sure if it should work)

i dont quite understand what that means but what i did and just did again right now is: Scenario 1

• create an urgent
• bring window client "nspscratchpad" where urgent is
• wait 60+ sec
• xmonad --restart
• all is GOOD

Scenario 2

• create an urgent
• bring window client "nspscratchpad" where urgent is
• not wait and xmonad --restart
• get booted

So if i wait for more than the RemindWhen timer there is no issue. Interesting

Thanks

[geekosaur]

Re-tracked this down. I had misremembered; it's not the window that has gone missing, it's the X.U.Timer and its associated thread. These are being persisted, but the thread and timer cannot be propagated to the new xmonad.

On Fri, Oct 21, 2016 at 1:27 PM, Brandon Allbery [email protected] wrote:

On Fri, Oct 21, 2016 at 10:56 AM, Dave [email protected] wrote:

Why does this happen?

We tracked this once as far as determining that something was trusting an invalid XID (a window that had gone away with the original xmonad, I think) without a userCode or catchX. We never figured out what code path was not using userCode though.

brandon s allbery kf8nh sine nomine associates [email protected] [email protected] unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

brandon s allbery kf8nh sine nomine associates [email protected] [email protected] unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

[geekosaur]

On Fri, Oct 21, 2016 at 10:56 AM, Dave [email protected] wrote:

Why does this happen?

We tracked this once as far as determining that something was trusting an invalid XID (a window that had gone away with the original xmonad, I think) without a userCode or catchX. We never figured out what code path was not using userCode though.

brandon s allbery kf8nh sine nomine associates [email protected] [email protected] unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

[geekosaur]

Correction: subprocess, not thread. Which is where I got lost last time I tried to track this down. The UrgencyHook even runs the ClientMessageEvent action and the urgencyHook in userCodeDef already, so it shouldn't be dying on an exception; and X.U.Timer itself doesn't persist any risky state.

On Sun, Oct 23, 2016 at 5:20 PM, Brandon Allbery [email protected] wrote:

Re-tracked this down. I had misremembered; it's not the window that has gone missing, it's the X.U.Timer and its associated thread. These are being persisted, but the thread and timer cannot be propagated to the new xmonad.

On Fri, Oct 21, 2016 at 1:27 PM, Brandon Allbery [email protected] wrote:

On Fri, Oct 21, 2016 at 10:56 AM, Dave [email protected] wrote:

Why does this happen?

We tracked this once as far as determining that something was trusting an invalid XID (a window that had gone away with the original xmonad, I think) without a userCode or catchX. We never figured out what code path was not using userCode though.

brandon s allbery kf8nh sine nomine associates [email protected] [email protected] unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

brandon s allbery kf8nh sine nomine associates [email protected] [email protected] unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

brandon s allbery kf8nh sine nomine associates [email protected] [email protected] unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

[davama]

Thanks for replying @geekosaur i think i understood. The X.U.Timer and all associated subprocesses are basically abandoned upon xmonad restart. I would assume that a restart would kill/restart all xmonad related processes and start fresh. (Not including external programs dzen,xmobar etc)

The X.U.Timer not dying, is that by design or something that can be resolved?

Thanks!

[davama]

Sorry for the bump but im still interested in this. (just happened yesterday during a pacman update which caused other issues...) :/

Just a recap: when mod-q withing the remindWhen time, xmonad session dies and i got back to my login manager lxdm Willing to test Thank you all for the support. looking forward to V0.13

[pjones]

I'm going to be working on xmonad bugs next week and I'll put this on my list.

[pjones]

@davama Would you please try to reproduce your issue with this config file. For some reason I can't seem to get the urgency hook to repeat.

Once we can reproduce the issue I will work up a fix for it.

Thanks!

[davama]

@pjones thanks!

Was not able to test today but will do tomorrow

[pjones]

Just an FYI, I've decided to move forward with the 0.13 release without a fix for this bug. This issue is important and I'm moving it to the next release milestone which will hopefully happen in the next few months.

[geekosaur]

Probably smart since it's been an issue for several years and tracking it down is an utter nightmare. (I did it once as previously described... do not have notes from it, only recollections, and have repeatedly gotten lost trying to reproduce since then. Frustrating.)

[davama]

@pjones sorry for the delay

i've tested your code here i've been fiddling with it trying to understand what is it's doing. didnt add X.C.Desktop since done need it. also using latest xmonad git

But regarding logout; i dont get kicked any more. urgency stays active until i bring or goto window client with the urgency.

Now idk if it's me or what but i shorten the remindWhen timer to 30 secds (using old code) and i dont get the alert any more. not sure it some behavior change with V0.13

thank you very much for the support

[pjones]

I'm going to assume that this only occurs when the repeat timeout is greater than 30. I'm going to leave this ticket open so that if someone is interested they can play with this.