I have statically configured network in /etc/network/interfaces. No network manager (due to timing issues with NFS mounts on boot). After a hibernation and probably also on other occurences I have it that KMail things it is in offline mode, while the network connection is available and pings are working. Reproducible: Sometimes Steps to Reproduce: I have no reliable reproducer yet. Maybe hibernate and resume. Especially with a night in between. Actual Results: - KMail says it is in offline mode. - Clicking "online" to switch to online mode does not have any effect. - Restarting Akonadi does not have any effect. - Quitting and starting KMail does not have any effect. Only thing that worked so far is: ms@mango:~> cat bin/fix-kde-network-status.sh #!/bin/bash # https://bbs.archlinux.org/viewtopic.php?pid=1057200#p1057200 killall -9 kded4 kded4 & disown So this may be an kded issue instead, please reassign if so. I dislike using this script tough (and may at least remove the -9 from the kill command). Before I used the script I tried to fiddle around with it with qdbus and got this: ms@mango:~> qdbus org.kde.kded /modules/networkstatus org.kde.Solid.Networking.Client.status 1 Does it mean that it actually thought the network is available? If so, then KMail didn´t know about this. Expected Results: KMail / kded detects actual network status. Akonadi itself is operational. Kontact's journal does work for example.
Bug #294441: kmail stays in offline mode, unable to send emails seems related. But the bug is still there. I don't use network manager and for a long time it worked without issues, with the statically configured connection. Since about a month or so it doesn't anymore.
https://bbs.archlinux.org/viewtopic.php?pid=1069317#p1069317 has a more fine grained approach: ...online: qdbus org.kde.kded /modules/networkstatus org.kde.Solid.Networking.setNetworkStatus "ntrack" 0 ...offline: qdbus org.kde.kded /modules/networkstatus org.kde.Solid.Networking.setNetworkStatus "ntrack" 1 Additionally, kmail has to stop/resume network jobs: qdbus org.kde.kmail2 /KMail stopNetworkJobs qdbus org.kde.kmail2 /KMail resumeNetworkJobs Okay, if 0 says its online and 1 says its offline, kded4 network module really thought it was offline in my case.
Yesterday I upgraded from Kubuntu 14.10 to 15.04, in both cases using the Kubuntu Backports and Update PPAs. The upgrade changed kMail from 4.14.2 to 4.14.6. Note that I'm currently still using upstart instead of systemd because with systemd the system does not boot to the login prompt but simply stops midway. Since the upgrade, I'm running into this problem - I'm starting my wired network connection manually using dhclient. kMail will not recognize the network connection and manually switching the mail sending agent to online mode will also not work. Shutting down the network interface and re-running dhclient while kMail is running however works, kMail somehow gets notified and can send mail from this point on...
(In reply to Gunter Ohrner from comment #3) > Shutting down the network interface and re-running dhclient while kMail is > running however works, kMail somehow gets notified and can send mail from > this point on... Unfortunately, this does not help always - eg. if I switch from one network to another and kill/rerun dhclient to get network connectivity in the other network, kMail will stop to work, insisting that it does not have a network connection. The commands from Comment 2 do not help at all - kMail always states in the status bar that it will continue network access only if a network connection was recognized. Network and internet connection DOES work fine for me, however - Thunderbird works and the web is also accessible, otherwise I could not submit this message... ;) Pretty annoying, is there any other workaround which might help in my case?
Does someone have an example how to reliably reproduce this? I've uninstalled networkmanager and tried several times to trigger this with: ifdown eth0 && ifup eth0 && dhclient even inserting several sleep times between the ifdown and ifup. and afterwards checking qdbus org.kde.kded /modules/networkstatus org.kde.Solid.Networking.Client.status Always showed the correct status.
(In reply to Andre Heinecke from comment #5) > Does someone have an example how to reliably reproduce this? Unfortunately, no. However, I have Network Manager installed but do not use it for wired networks. I'm manually using dhclient instead. Maybe this does not properly work? I've never tried without network manager being installed. BTW, a workaround to get kMail going (most of the times, though) is to perform the dhclient comment twice: $ dhclient -v eth0 ; killall dhclient ; ifconfig eth0 down ; dhclient -v eth0 This will often do the job for me.
I have about the same problem in Debian Jessie (kmail 4.14.1) Network manager is not installled and after hibernate/resume, imap accounts go offline and refuse to go back online. Restarting akonadi and kmail won't help. I tried the dhclient-trick in the previous comment and it worked.
I'm currently running Kubuntu 15.10 with kMail 5.0.3 and on this system connectivity recognition seems to work reliably. So a single "dhclient -v eth0" is sufficient now. However, keep in mind that I have Network Manager installed and simply do not use it for wired networks. (I do use it for WLAN.)
I confirm this bug. I experience this problem with KMail 4.14.1 && KDE 4.14.2 from Debian Jessie For historical reasons I use wcid instead of network-manager and I have the same problem with KMail as Martin Steigerwald described. The workaround described in report works for me too (Thanks for it)
Yesterday evening I put my work computer to hibernate with: echo disk >/sys/power/state And this morning when I woke it up by pressing the power button, kmail fetched some emails that had arrived during the night and later decided that it is offline. So it seems that hibernation doesn't immediately cause the offline, but causes it to happen later. I hope this helps solving the problem.
For me it just seems to happen "randomly" at the moment - in most cases, kMail works fine, but then suddenly decides it's offline and cannot be convinced that actually it's not... I have to logout and re-login in fact to get it working again, which is pretty disruptive during work... Even switching to Network Manager for managing my ethernet connection, which I now finally did, hoping it would solve these issues, did not help...
As mentioned in #322602: This still happens here with kmail/kontact/akregator 5.3.0, frameworks 5.27.0, qt 5.7.0 and no networkmanager
Can you check your ntrack Version, we had a customer that encountered the same problem in their KMail deployment and after some analysis we were pretty sure that the ntrack library was to blame. As KDE services just forward the network status from that library and ntrack reported it was offline when kmail wrongly thought it was offline, too. So we updated ntrack to 017 as they changed the way they discover the online state a bit ( https://launchpad.net/ntrack/+announcement/13058 ). This solved the problem for the customer who has not seen further disconnect / connect problems since deploying libntrack-017 Please check if libntrack installed on your system is >= 017 If so reopen this bug or comment please. I really think this is an upstream problem and you should ask your distributors to ship ntrack 017 or built it from source or so. Packages for Ubuntu trusty are published here: http://apt.intevation.org/dists/trusty/kdepim-4.14/binary-amd64/ntrack/
Sorry, i don't have ntrack, i don't need ntrack except for this [useless] for me "feature" (network cable plugged into desktop pc is not gonna roam around). Is there really no way of specifying an "assume always online" mode for this usecase?
Forgot to mention that this issue appeared for me when i transitioned to the kf5 based kmail/akregator/kontact.
Adittionally, how is one supposed to use ntrack with KF5? from kdelibs4support/src/solid-networkstatus/kded/CMakeLists.txt: # FIXME: Re-enable the above when: # * QNTrack has been ported to Qt5 # * cmake/modules/FindQNtrack.cmake has been adapted to the Qt5 dependency #find_package(QNtrack) #set_package_properties(QNtrack PROPERTIES DESCRIPTION "Network status tracking library" # URL "http://launchpad.net/ntrack" # TYPE OPTIONAL # PURPOSE "Provides data input for Solid network status" # ) set(QNTRACK_FOUND FALSE) # Forced to false, see above FIXME
Andre, ntrack is not used, KF5 solid simply has no network status API any longer. Reopening.
Thank you for reporting this bug in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Sorry, I do not have spare laptop to test this now. But if you have, you can try to remove network-manager and install wicid, for Wi-Fi usage. If you will be able to make kmail work after wicid goes offline and then online, then problem, the way I knew it, is no longer there...
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!