Open J0nnyMak0 opened 2 years ago
When Push stops working, do you still see the Push notification? If so, what text does it display?
There's not much we can do without more information. You need to capture a log right after Push fails (and doesn't recover). You might be able to accomplish that by leaving your device connected to a PC. See https://github.com/k9mail/k-9/wiki/LoggingErrors
Instead of adb logcat -d --pid=<PID> > k9-log.txt
use adb logcat --pid=<PID> > k9-log.txt
. Once you've captured the error, press CTRL+C to stop the logging.
When Push stops working, do you still see the Push notification? If so, what text does it display?
Do you mean the persistent notification? It still says "Waiting for new emails", but I don't get any other notifications.
There's not much we can do without more information. You need to capture a log right after Push fails (and doesn't recover). You might be able to accomplish that by leaving your device connected to a PC. See https://github.com/k9mail/k-9/wiki/LoggingErrors
Instead of
adb logcat -d --pid=<PID> > k9-log.txt
useadb logcat --pid=<PID> > k9-log.txt
. Once you've captured the error, press CTRL+C to stop the logging.
Ok, thanks. I'll will try that. I will try to increase the # of push folders and see if I can force this to happen sooner.
Most servers have a limit of how many connections per user they allow. Usually this manifests as an error during authentication. After an authentication error, K-9 Mail's Push code will back off and only retry an hour later.
"Too many open connections" is a condition that could happen if the Android device frequently loses and regains connectivity. From the point of view of the server the old connections will remain open until the server's IDLE timeout is reached, even if there's nobody on the other side of the connection anymore.
After an authentication error, K-9 Mail's Push code will back off and only retry an hour later.
Does the persistent notification text change when k9 is in this mode?
Good question. I don't have time to check right now. I'm guessing the text won't change.
This is still happening from time to time. This is what I was able to capture with the suggested method. k9log.txt
I have two accounts: One Gmail account and one at IONOS. If i stop being notified immediately on arrival of new mails, but mails still arrive at refresh or triggered by a timer (might be once per hour, but feels faster) that happens for both accounts simultaneously.
Have now told my android not to optimize K9 for battery usage: I suspect that the original reporter of this problem and I both just see the results of our cellphones trying to save some energy.
I suspect that the original reporter of this problem and I both just see the results of our cellphones trying to save some energy.
Nope. Sorry, not in my case. Should have mentioned it, I took K-9 off battery optimization. From the log above it looks like there actually is some sort of an abort? Not sure if "Software caused connection abort" is server side or client side.
04-26 15:34:37.127 19644 19694 V AndroidPowerManager$AndroidWakeLock: AndroidWakeLock for tag ImapFolderPusher-Work-Deleted Messages / id 9: acquired with no timeout.
04-26 15:34:37.134 19644 19694 V ImapFolderPusher: Exception in ImapFolderPusher
04-26 15:34:37.134 19644 19694 V ImapFolderPusher: javax.net.ssl.SSLException: Read error: ssl=0x77724fd388: I/O error during system call, Software caused connection abort
04-26 15:34:37.134 19644 19694 V ImapFolderPusher: at com.android.org.conscrypt.NativeCrypto.SSL_read(Native Method)
04-26 15:34:37.134 19644 19694 V ImapFolderPusher: at com.android.org.conscrypt.NativeSsl.read(NativeSsl.java:411)
04-26 15:34:37.134 19644 19694 V ImapFolderPusher: at com.android.org.conscrypt.ConscryptFileDescriptorSocket$SSLInputStream.read(ConscryptFileDescriptorSocket.java:549)
A quick update. I recently upgraded to a Pixel and running K9 on Android 13. I'm still running into this issue. As @cketti suspected, I think the issue is when I switch from wifi to mobile network and vice versa. I have set my IDLE keep alive to 60 minutes to minimize connections to server.
I think it would be great if there can be a setting where IDLE renews when there is either a change in network connection or an interruption in network connection. If there is such a setting then, when the IDLE connection drops due to network interruptions, there wouldn't be a delay in getting a new connection to the server.
If you think this is worth it, I can submit a new feature request at the thunderbird project. Thanks!
I also run into this - IMAP idle is almost useless and doesn't work properly anywhere. That's why I used EAS in the past but it's buggy and unreliable. Maybe JMAP will fix things - new standards always do... /s
Btw, while almost unrelated, there exists a standard called Unified Push on Android. There's even a feature request for k9. But imap servers, afaik, don't support this.
I think it would be great if there can be a setting where IDLE renews when there is either a change in network connection or an interruption in network connection. If there is such a setting then, when the IDLE connection drops due to network interruptions, there wouldn't be a delay in getting a new connection to the server.
And I always thought that's how IMAP IDLE works, to be able to deliver push notifications instantly. Is that not how k9 does it? Is it not the standard way of doing it?
I think it would be great if there can be a setting where IDLE renews when there is either a change in network connection or an interruption in network connection. If there is such a setting then, when the IDLE connection drops due to network interruptions, there wouldn't be a delay in getting a new connection to the server.
I wouldn’t expect this to be a setting. I’d expect this to be the default behavior. The IDLE connection should be reset (i.e., TCP reset) when switching between WiFi and data and the app should instantly reestablish the connection, try a couple times before backing off to save power if that fails, and retry instantly upon any network change which hints at a potential change in internet availability. If the IDLE connection doesn’t get reset, something like an application-layer ping should be sent during the refresh interval to force detection of the break (that is one of the purposes of that refresh setting, right?).
When this push connection dies, does it recover during the “normal” mail fetch interval? I am wondering about the OP’s experience. I noticed that I need to set both the normal fetch interval and push. Oftentimes push works and I get instant notifications, but often I won’t get a notification until the normal fetch interval. Ideally I could set my fetch interval high so that IDLE triggers fetch, but that just isn’t reliable enough. When I am sitting at my PC, that is fine because normally Thunderbird gets an instant notification when my phone doesn’t and vice versa x.x.
To me this sounds like a energy saver built into the phone's OS that basically randomly kills services hoping that will kill the user experience
To me this sounds like a energy saver built into the phone's OS that basically randomly kills services hoping that will kill the user experience
If that were the case, wouldn’t the normal “fetch mail” interval fail to work too? The app uses a foreground service/notification to avoid this and I have also configured the necessary “battery optimization” features for this app on my phone (this was already mentioned here). The instant push works most of the time but seems to sometimes get stuck and wait for the next “fetch mail” interval. I think that I sometimes see a similar (temporary) dropped push even on my desktop email client. I will try to be more attentive and keep this thread in mind.
@J0nnyMak0 I am wondering, do you have the “fetch mail” interval turned off completely in order to rely only on push? If you have it enabled, does your push functionality recover on the next interval (that might be hard to test if you need to check on the email)?
Checklist
App version
6.000
Where did you get the app from?
Google Play
Android version
10
Device model
No response
Steps to reproduce
Expected behavior
Expect to keep getting messages pushed to my Inbox
Actual behavior
Stop receiving emails
Logs
I'd like some help with understanding how to capture useful info since it takes days for this problem to manifest. However, this is what I see when I refresh my inbox manually after emails stop getting pushed. Killing k9 on my phone and restarting, fixes the problem for a few days until it happens again. I've tried playing around with IDLE refresh times but that doesn't seem to help. Reducing # of max push folders to 5 seems to increase the time between failures.
Not sure it has anything to do with this, but for completeness, I access the same mailbox from a different client on the desktop that also uses IMAP IDLE (refresh set to 15 minutes) and it continues to work fine, pushing emails.
Just before the above, everything seems ok, but I don't get any emails showing up in k9: