.Xsession_error upon wake-from-suspend

[enkore]

.Xsession_error upon wake-from-suspend

[lasers]

Solved via #380? Can we close this issue?

[enkore]

Probably duplicate of #101 ?

[enkore]

Confirmed not-a-duplicate of #101

What is the configuration (without passwords and so on of course) of the mail module?

[halocaridina]

See below.

status.register("mail",
email_client="/usr/local/bin/mutt",
format=": {unread}",
format_plural=": {unread}",
color_unread="#00FFFF",
backends=[
imap.IMAP(
# port and ssl are the defaults
host="XXXXX", port=993, ssl=True,
username="XXXXX", password="XXXXX"
)
])

There was also a similarly worded error on a recent wake-from-suspend involving the weather module. Unfortunately, I don't have the exact error message due to log rotation of .xsession_error. The weather module is configured like so:

status.register("weather",
location_code="XXXXX",
colorize=True,
units="imperial")

[enkore]

Does 9cdcfcc fix this for you?

[enkore]

Note: Might lead to issues with the dbus-based backends, like the Thunderbird one

[halocaridina]

Thank you. Just updated i3pystatus via:

pacaur -y i3pystatus-git

I'll report the results over the next 24-48 hours.

Thank you again and more soon.

[halocaridina]

Following the above update, logged out and back into i3 to ensure a clean start of i3pystatus and fresh .xsession_error. Suspended the machine for ~30 min with lid being closed. Upon awake, error is:

no connectionException in Thread-4 at Wed Aug 27 09:34:58 2014
Traceback (most recent call last):
File "/usr/lib/python3.4/site-packages/i3pystatus/core/threading.py", line 68, in call
self.workload()
File "/usr/lib/python3.4/site-packages/i3pystatus/core/modules.py", line 67, in call
self.run()
File "/usr/lib/python3.4/site-packages/i3pystatus/core/util.py", line 346, in wrapper
return method(_args, *_kwargs)
File "/usr/lib/python3.4/site-packages/i3pystatus/mail/init.py", line 46, in run
unread = sum(map(lambda backend: backend.unread, self.backends))
TypeError: unsupported operand type(s) for +: 'int' and 'NoneType'

First two lines (68 and 67) are as in original report while line 346 is new and line 44 has changed to line 46.

Hope this helps to narrow the issue down.

[enkore]

Good, I'll add some sort of DNS availability check to internet(), which should fix this.

[halocaridina]

Hi Enkore,

I noticed that this issue was closed. Unfortunately, I've been still experiencing issues with the IMAP module when resuming from suspend. Specifically, the module doesn't correctly resume until I do a restart via a custom script:

bindsym $mod+Shift+r exec --no-startup-id /usr/local/bin/reload_statusbar.sh

containing:

#!/bin/bash
/usr/bin/pkill -f nm-applet >/dev/null 2>&1
/usr/bin/pkill -f parcellite >/dev/null 2>&1
/usr/bin/pkill -f caffeine >/dev/null 2>&1
/usr/bin/pkill -f pasystray >/dev/null 2>&1
/usr/bin/pkill -f conky >/dev/null 2>&1
/usr/bin/i3-msg restart >/dev/null 2>&1
/usr/bin/pasystray &
/usr/bin/caffeine &
/usr/bin/parcellite &
/usr/bin/nm-applet &
/usr/bin/conky -c ~/.config/conky/bar_conkyrc >/dev/null 2>&1 &

If I don't do the above restart, I eventually receive the following error from the i3pystatus IMAP module within 5-10 min after resuming from suspend:

Mail: socket error [Errno 32] Broken pipe

I don't have any info from .Xsession_error to provide since I've make that file immuatable as a workabout for lightdm's inability to filter content being written to it (.Xsession_error was constantly growing with GTK3 warnings after the recent upgrade to 3.14).

FYI: I last updated i3pystatus ~3 days ago and still experience the IMAP issue.

In any case, executing the above script has become a normal routine following a suspend, so I (almost) don't notice the IMAP issue anymore.

Cheers and thanks again from developing i3pystatus,

halocaridina

PS Forgot to mention that the conky I'm running is not sending its output to i3status bar, its being drawn to the root window,

[enkore]

Thanks for the update :)

In theory it should start running in the next interval (default: 5 seconds) after the socket error exception is thrown...

To speed this process up you could try to set the default socket timeout explicitly to some low value (e.g. 2 seconds). See https://docs.python.org/3/library/socket.html#socket.setdefaulttimeout

[halocaridina]

Hi enkore,

Thanks for the suggestion. Unfortunately, setting the timeout on the socket doesn't help. Only reloading the i3statusbar (as above) results in expected behavior (either when the broken pipe error is printed or when the indicator doesn't come up at all following a suspend and new mail is present in the INBOX).

Cheers,

halocaridina

[sileht]

Perhaps #380 solves this issue.

Cheers,