Bug 294441

1 confirm for Arch Linux running KDE 4.8.0

I removed the configuration related to Kmail in .kde4/share/{apps,config} and the problem persists.

I confirm too.
Deleting the whole .kde4 does not solve this neither.

confirm too for fresh installed kde-meta 4.8 on archlinux.
the above two commands work but need to run every startup.

*** This bug has been confirmed by popular vote. ***

Same problem here with KDE 4.8.

However, it is possible to send mail. After clicking 'send' your mail goes to your local outbox folder. Then you have to right click the outbox folder and choose "send queued messages". KMail will ask you if you want to go online, you click "go online" (or whatever it's written) and your mail will be dispatched.

But this is only a workaround...

Same on Arch Linux x86_64, KDE 4.8.0, Lenovo Thinkpad E520.

Workaround OK but not satisfying.

It would be interestiung to figure out if it is related to a real pb in a daemon or if it is because kded4 is started too early.

Changing network management backend in information sources in system settings does not help :(

I experience this particular brokenness often after resuming from suspend. Even after switching to online status by accepting the dialog, kmail will not be in online state, and sending mail is about impossible. Log out and back in works until next suspend/resume.

im sure there is a way to communicate with solid and/or networkmanager when network state changes!

I even think the problem might be in "Hardware Integration Configuration with Solid" (System settings -> Information sources). The network management backend does not correctly report the online status. Even when I start Kopete it starts in offline mode, even though I've set initial status as 'online'. Obviously it detects that system is offline in the same way kmail detects that, and that is through information sources or Solid...

So I think this bug is not necessarily a bug in kmail, but a bug in system settings/information sources->network management backend (i.e. Solid).

Here is a log I have in KSystemLog under Authentication menu:

[system] Rejected send message, 11 matched rules; type="error", sender=":1.7" (uid=1000 pid=708 comm="kdeinit4: kded4 [kdeinit]                       ") interface="(unset)" member="(unset)" error name="org.freedesktop.DBus.Error.UnknownMethod" requested_reply="0" destination=":1.0" (uid=0 pid=552 comm="/usr/sbin/NetworkManager ")

There is something wrong here between kded4 and NetworkManager ...

Any clue ?

kmail2 is the only application in my system suffering from this. The networkmanager applet shows that there is a connection, and ALL other applications uses the network without complaining (I'm not sure if they try to decide if it is possible though)

I confirm the bug since KDE 4.8
I don't use Network Manager, but my internet connection is instable. If kmail dettecs the lack of internet, automatically switch all IMAP accounts to "Offline". But when the connection is restablished, the folders remain in offline mode. The clicks in the message "Kmail is in offline mode. Click here to switch online" are ignored.
If i close Kmail and reopen it, it show a message saying "Kmail is now in offline mode. Do you want to continue?". If i click in "Work online", the problem is fixed, but only in the selected IMAP folder. I need do the same for each IMAP account

Regards
PD: the descripted messages can vary, because i use the spanish translation

For me the problem occurs on a fresh install of kde 4.8 Arch x86_64.

I have another machine under Arch i686, updated from kde 4.7 (and previous) for which the issue is not present.

What is the common spec that make this happen (hardware, modules, daemons, acpi conf, etc.) ?

Mine:
Lenovo Thinkpad E520
Arch x86_64
Latest KDE SC 4.8
Broadcom brcmsmac module for Wifi

I'll try to attach some more when back home.

Severity of the bug should be changed as, even if the workaround works, it is blocking for me for a daily usage.

(In reply to comment #9)
> I even think the problem might be in "Hardware Integration Configuration with
> Solid" (System settings -> Information sources). The network management backend
> does not correctly report the online status. Even when I start Kopete it starts
> in offline mode, even though I've set initial status as 'online'. Obviously it
> detects that system is offline in the same way kmail detects that, and that is
> through information sources or Solid...
> 
> So I think this bug is not necessarily a bug in kmail, but a bug in system
> settings/information sources->network management backend (i.e. Solid).

When running:
qdbus --system org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.state
I get result 70, which is correct value returned by NetworkManager given these specs : http://projects.gnome.org/NetworkManager/developers/api/09/spec.html#type-NM_STATE

When running:
qdbus org.kde.kded /modules/networkstatus org.kde.Solid.Networking.Client.Status
I get value 1 which is not good. Value 4 is expected.

So I agree with Nena, Solid's network status is not correctly updated by NetworkManager, once the latter gets connected after kde has started.
I'd suspect kded_networkstatus to be the problem ...

This problem affects all remote akonadi resources, my calendars and addressbooks stored in owncloud are considered offline too.

Got broblem fixed by doing this :

In Systemsettings > Network. In "Network connections" menu, select "Wireless" tab. Select current wireless connection and click "modifiy".
Under "Connection name" is a check box with "System connection". Check this box apply everything (nay need passord).
Reboot (maybe logout is sufficient, no tried).

Now qdbus org.kde.kded /modules/networkstatus org.kde.Solid.Networking.Client.Status retruns 4 and no offline popup from kmail when opening it.

Now I need to validate that solution has no side effect. I just feel my wifi connection drops more since...

Hope that helps.

(In reply to comment #16)
> Got broblem fixed by doing this :
> 
> In Systemsettings > Network. In "Network connections" menu, select
> "Wireless" tab. Select current wireless connection and click "modifiy".
> Under "Connection name" is a check box with "System connection". Check this
> box apply everything (nay need passord).
> Reboot (maybe logout is sufficient, no tried).
> 
> Now qdbus org.kde.kded /modules/networkstatus
> org.kde.Solid.Networking.Client.Status retruns 4 and no offline popup from
> kmail when opening it.
> 
> Now I need to validate that solution has no side effect. I just feel my wifi
> connection drops more since...
> 
> Hope that helps.

PS: Given menu names may not be accurate because my system is in French

@wazyk

My wired network connection on laptop already is a system connection and on my home PC I don't even use Network manager - I use dhcpcd at boot time. However, KDE thinks that I'm offline.

Since this is quite an annoying problem and as recently I was unable to send encrypted mail using kmail (this bug is known and has been reported), I temporarely switched to using thunderbird on KDE...

I confirm too. Archlinux kde 4.7.4 and 4.8.0
with this bug makes impossible to use kmail (and kget)

Also present in kde 4.8.1. I believe this affects all akonadi resources, so that remote calendars and addressbooks are also not updated when this brokenness is active.

On my system this state is entered after resume from suspend.

(In reply to comment #19)
> I confirm too. Archlinux kde 4.7.4 and 4.8.0
> with this bug makes impossible to use kmail (and kget)

ups sorry I was wrong, for me this bug is still present on kde 4.8.0 and 4.8.1 (not 4.7.4)

The are a communication problem between networkmanager and kded after suspend to ram or network failure. If you are connected with wicd, this is not appends and kmail stay online.

I am the Network Management maintainer in KDE, I use NetworkManager 0.9 and do not have this problem. Networkstatus works as expected here.

Is everybody with this problem using only Arch? Does Arch stop NetworkManager when suspend to disk?

qdbus org.kde.kded /modules/networkstatus org.kde.Solid.Networking.Client.Status == 1 means some program has marked the system as Unconnected (offline), usually it is networkstatus that does that.

Restarting kded4 helps with this problem  because the networkstatus module tries to detect the network status when kded4 starts.

Networkstatus has three backends: NetworkManager, Wicd and NTrack. NTrack is the fallback backend (if it is was compiled) and as so it is used only when neither NetworkManger nor Wicd are running. I can say NTrack is the most problematic of those three. If you have NTrack installed I suggest that you recompile kde-runtime after uninstalling NTrack. There is no other way to disable the NTrack backend. Enabling NTrack is a decision of the distribution, in my case Gentoo does not enable NTrack and I do not need it anyway since I use NetworkManager.

Do do not mess with the configuration in systemsettings -> Information Sources. Use the correct backend (usually NetworkManager 0.9 or Wicd) and that is it. If you change from NM to Wicd (or vice-versa) change the backend in Information Source or your network support is going to be unstable or even not work at all. Never run too network management software (NM, Wicd, ifplugd, etc) at the same time, choose only one and disable all the others.

Thanks Lamarque.
Nice you joined the offline crew for help.

It may be an Arch only issue, yes, introduced in 4.8.

Now, since setting my connection as "System connection" kind of fixed the issue for me (at boot time and resume only, reconnection after disconnection makes me offline), can it be a permission issue ?

How is networkstatus supposed to behave ?

On boot, since networkmanager is not connected, it is ok for me that networkstatus sends value "1".
But when networkmanager is connected kded daemon should notify it to the system and send value "4".

Is there a way to track that more precisely ?

If the problem only happens in Arch this is probably an upstream bug. According to this https://bbs.archlinux.org/viewtopic.php?id=135284 NetworkManager is probably denying access to networkstatus to listen to the StateChanged signal. Without this signal networkstatus never updates system status when using NetworkManager as backend.

Run this command as normal user and check if it returns an error:

dbus-monitor --system "type='signal',sender='org.freedesktop.NetworkManager',interface='org.freedesktop.NetworkManager'"

if it returns an error then that's is the problem and Arch must configure polkit to allow normal users to listen to that signal.

Thanks Lamarque. Executing dbus-monitor --system "type='signal',sender='org.freedesktop.NetworkManager',interface='org.freedesktop.NetworkManager'" gives me this:
signal sender=org.freedesktop.DBus -> dest=:1.78 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.78"

The only way I've found to reconnect kmail and akonadi-google is to execute qdbus org.kde.kded /modules/networkstatus org.kde.Solid.Networking.setNetworkStatus "ntrack" 0 every time I resume from suspend to RAM. I have no swap (SSD), so cannot try suspending to disk.

(I'm also an Arch user)

If you have ntrack installed you should try recompiling kde-runtime without it as I suggested in my first post. I should not have being used since the NetworkManager backend has precedence, but who knows? By what you are saying it is interfering with networkstatus. If when kded starts networkstatus is not able to contact NetworkManager then it will try Wicd, if it cannot contact Wicd then it will use NTrack if it has been compiled.

With TuxOnIce (TOI) you can suspend to disk using files instead of swap, actually you can use both at the same time :-D I am really disappointed the kernel developers have never allowed TOI to get into the vanilla kernel, it's way better than the stock implementation: it uses all cores to compress and/or encrypt the image (the stock implementation uses only one core, does not compress the image and IIRC also does not encrypt it), it supports saving the image to file instead of only to swap partition, it can save the kernel's disk cache to prevent a flood of disk activity right after resume (like it always happens with the stock implementation), and have a nice themable GUI interface instead of a text only interface (TOI also includes a text only interface).

In my opinion, the most annoying problem is that kmail2 does not go into online mode when you choose "File->Work online" after a suspend (see Anders Lund's report for example). In my case my laptop takes longer to get connected so this occurs on a fresh boot as well. Akonadiconsole shows the Mail Dispacher Agent grayed out so I can't close it and open it again.

Everything works well if you are connected and choose "File->Work offline" followed by "File->Work online", but if for some reason the connection drops then you're in trouble.

I'm using Arch as well, but no mainstream network manager, so no signals are being sent.

Created attachment 69542 [details]
PKGBUILD for kdebase-runtime

I rebuilt kdebase-runtime from abs without ntrack as Lamarque suggested (Comment #23, Comment #27). Ntrack is a dependency on arch linux by default, so I had to uninstall the package first. Now everything works fine. Thanks a lot, Lamarque!

I attach the PKGBUILD I used (removed dependency "ntrack", path to source corrected).

(In reply to comment #29)
> Created attachment 69542 [details]
> PKGBUILD for kdebase-runtime
> 
> I rebuilt kdebase-runtime from abs without ntrack as Lamarque suggested
> (Comment #23, Comment #27). Ntrack is a dependency on arch linux by default,
> so I had to uninstall the package first. Now everything works fine. Thanks a
> lot, Lamarque!
> 
> I attach the PKGBUILD I used (removed dependency "ntrack", path to source
> corrected).

yeah,  (with this small fix) work perfect for me too, thanks Jan Schumacher and Lamarque thanks a lot for your detailed explanation. I think this should be fixed in official package in Archlinux.

I still would like to understand why exactly is happening with the NTrack backend. It should only be used if NetworkManager and Wicd are not running and of course it should not set the system as offline when it is not.

Next weekend I will install ntrack here and see what is going on with it.

Yes *please* let us have updated arch package! The situation is unbearable, unacceptable!

Kmail have problems however, why does sending mails not become enabled when kmail is switched to online status? It asks if I want to go online, and then does not.

Has anybody opened a request/bug under Archlinux with all the upper gatherd infos ?

BTW, Ntrack seems to be a kdebase-runtime dependancy since a long time now.
Something must be broken with 4.8 around it.
A agree that Ntrack must not be involved in any way when NetworkManager is used.

The command:
dbus-monitor --system "type='signal',sender='org.freedesktop.NetworkManager',interface='org.freedesktop.NetworkManager'"
gives me this output:
signal sender=org.freedesktop.DBus -> dest=:1.51 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.51"
No error, so I guess it is ok for permission stuff.

Hope that Arch packagers/mainterner of KDE will fix that soon

As I could not find any report on bugs.archlinux.org I filed it there:
https://bugs.archlinux.org/task/28880
Hope the report is sufficent, please comment on bugs.archlinux.org if not or if it's a duplicate.

Hi all, I cannot reproduce this in Arch. This was an issue with 4.8.0, but got fixed with the update to 4.8.1.

Anyway, if Lamarque suggests to disable Ntrack from kde-runtime, I'll drop it.

Hi all, I cannot reproduce this in Arch. This was an issue with 4.8.0, but got fixed with the update to 4.8.1.

Anyway, if Lamarque suggests to disable Ntrack from kde-runtime, I'll drop it.

I have this problem with archlinux and kde 4.8.1, though not all the time like before, but often. For example if I resume in a place with no network, or possibly just a different network (in the first case networking should be disabled, but fails to come up later after connecting or resuming in a location with a known network).

Seems like it depends on the network being up before kmail or akonadi or whatever it is decides if it should be disabled.

(In reply to comment #37)
> Hi all, I cannot reproduce this in Arch. This was an issue with 4.8.0, but
> got fixed with the update to 4.8.1.

Hmmm then maybe my commit d0ce3b783382016a0b6049a78066a5fdb089043b to kde-runtime-4.8.1 fixed this issue. NetworkManager emits the StatusChanged signal but network is not  really accessible for a couple of seconds. My commit adds a 2s delay before networkstatus relays the StatusChanged signal to all other KDE programs. Maybe I need to increase the delay I contact NetworkManager developers to ony emit StatusChanged when network is really online.
 
> Anyway, if Lamarque suggests to disable Ntrack from kde-runtime, I'll drop
> it.

Now I am not sure if ntrack is the culprit here, Kubuntu also enables NTrack by default and no Kubuntu user has complained so far. The problem with NetworkManager seems more logical to cause this problem. Does anyone here use Wicd?

Two weeks ago, because I was unable to connect with NM, I have to use wicd and after resume from suspend to ram I didn't have problems with offline state.

https://bugs.archlinux.org/task/28850
Looks like Ntrack dependency is removed in next update

Solved to me in ArchLinux updating to 4.8.1 and manually removing the ntrack package (Pacman will inform us that this package is no longer required by any other)

I can confirm, I don't have this problem anymore on archlinux :)

I have not been prompted by pacman to remove any package, or maybe I did not see. I did not remove anything myself. But my kde-runtime has been upgraded and now it works !

Resolved for me.

Please users keep the ArchLinux comments in our bugtracker; this is the KDE bug tracker.

This issue has been "fixed" on arch removing the QNtrack support in kde-runtime, but it HAS NOT been fixed in KDE/Ntrack code. So this still is a KDE bug or a ntrack bug.

(In reply to comment #45)
> Please users keep the ArchLinux comments in our bugtracker; this is the KDE
> bug tracker.

Since this problem happens only with Arch users and not users from other distributions that also use NTrack I am inclined to think that there is a problem in the NTrack version you use (0.16) when other distributions use 0.15.

On the other hand networkstatus should have never activated ntrack support if NetworkManager or Wicd is running. But ntrack should not have set system as offline too. There seems to be more than one problem here. Does ArchLinux use systemd?
 
> This issue has been "fixed" on arch removing the QNtrack support in
> kde-runtime, but it HAS NOT been fixed in KDE/Ntrack code. So this still is
> a KDE bug or a ntrack bug.

I will take a look at the ntrack support in networkstatus next weekend.

Yes, Arch uses systemd, but not as default. I use systemd on my system.

>Does ArchLinux use systemd?

I was experiencing the problem and I'm not using systemd.

Ok, we figured out what is wrong here:

. ntrack and wicd support are already enabled. So I was wrong in comment #46.

. NetworkManager support is only compiled in if NetworkManager's headers are installed and that is probably the Arch's problem. According to this http://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/kdebase you are compiling kde programs without NetworkManager support. Because of that ony ntrack support is functional and since ntrack has this bug that never sends the online signal the system is set to offline for ever.

. all KDE programs (or at least they should) treat system as online in unknown state, so if you set ntrack state to 0 (unknown) the programs start to work.

. Since Wicd backend is always enabled the Wicd status overrides the ntrack status and everything works.

So, please compile kde-runtime with NetworkManager support and everything should work even with ntrack support enabled. You can re-enable ntrack support once they fix their problem. 

I just do not know how to close this bug, it's both upstream (ntrack) and downstream (Arch) :-)

Thanks for clarifying this Lamarque, but there's nothing in the kde-runtime's cmake output that says to install NetworkManager to build the networkmanager support in KDE.

Perhaps you're confusing with kde-workspace? NetworkManager is a dependence of kde-workspace.

(In reply to comment #50)
> Thanks for clarifying this Lamarque, but there's nothing in the
> kde-runtime's cmake output that says to install NetworkManager to build the
> networkmanager support in KDE.

I will add a warning for when NetworkManager is not found when compiling kde-runtime. Networkstatus is in kde-runtime, not kde-workspace. What is in kde-workspace are the Solid backends for NetworkManager, ModemManager and Wicd.
 
> Perhaps you're confusing with kde-workspace? NetworkManager is a dependence
> of kde-workspace.

No, I am not. I have commited several patches to NetworkManager support in both kde-workspace and kde-runtime.

Git commit 1f53a1675319a8fb15ef6f11f59d7202bedbd4fd by Lamarque V. Souza.
Committed on 14/03/2012 at 15:25.
Pushed by lvsouza into branch 'KDE/4.8'.

Add log message indicating if NetworkManager support in kded's
networkstatus module has been enabled or not.
(cherry picked from commit b0a42e9d262d0168cd19529ec5e1978547bacd40)

M  +1    -0    solid-networkstatus/kded/CMakeLists.txt

http://commits.kde.org/kde-runtime/1f53a1675319a8fb15ef6f11f59d7202bedbd4fd

Le mercredi 14 mars 2012 14:29:52 vous avez écrit :
> https://bugs.kde.org/show_bug.cgi?id=294441
> 
> Lamarque V. Souza <lamarque@kde.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
> Status|NEW                         |RESOLVED
>          Resolution|---                         |DOWNSTREAM

(In reply to comment #46)
> (In reply to comment #45)
> > Please users keep the ArchLinux comments in our bugtracker; this is the KDE
> > bug tracker.
> 
> Since this problem happens only with Arch users and not users from other
> distributions that also use NTrack I am inclined to think that there is a
> problem in the NTrack version you use (0.16) when other distributions use
> 0.15.
> 
> On the other hand networkstatus should have never activated ntrack support
> if NetworkManager or Wicd is running. But ntrack should not have set system
> as offline too. There seems to be more than one problem here. Does ArchLinux
> use systemd?
>  
> > This issue has been "fixed" on arch removing the QNtrack support in
> > kde-runtime, but it HAS NOT been fixed in KDE/Ntrack code. So this still is
> > a KDE bug or a ntrack bug.
> 
> I will take a look at the ntrack support in networkstatus next weekend.

I have this issue using Mageia so it is not just an Arch issue. I understand that it is solved but I wanted it known that Mageia uses ntrack-0.16 so that seem most likely the problem.

Hello,
Bug was also reproduced in mageia 2 by users *not* using networkmanager. Users using networkmanager (like me :p ) are not affected ( kde-runtime is built with nm support).
Building kde-runtime without ntrack support fix the issue.
ntrack version is the 016.

Regards,