ntop produces 100% CPU load after suspend

[Ralfk]

Binary package hint: ntop

this bug happens regularly on my laptop, which is a Thinkpad R400 from Lenovo. I think this could be related to a not existend WLAN connection after suspend.

ProblemType: Bug
Architecture: i386
Date: Mon Oct 26 15:32:44 2009
DistroRelease: Ubuntu 9.10
ExecutablePath: /usr/sbin/ntop
Package: ntop 3:3.3-11ubuntu1
ProcEnviron:
 PATH=(custom, no user)
 LANG=C
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: ntop
Uname: Linux 2.6.31-14-generic i686

[Ralfk (ralf-kohrt)]

Architecture: i386
DistroRelease: Ubuntu 9.10
Package: ntop 3:3.3-11ubuntu1
PackageArchitecture: i386
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=de_DE.UTF-8
 LANGUAGE=
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
Uname: Linux 2.6.31-14-generic i686
UserGroups: adm admin audio cdrom dialout dip floppy fuse lpadmin plugdev video

[Ralfk (ralf-kohrt)]

As you can see now, this is reproduceable...

In the File XsessionErrors.txt it looks like an Firefox related bug, thats why i have tried to reproduce the bug, by killing Firefox(after that, ntop had still 100% CPU load) before collection informations with apport, which I forgot yesterday.

[Eero Aaltonen (ejn)]

sudo service ntop restart

at least removes the symptoms

[Eero Aaltonen (ejn)]

This might be caused by some lib that is also used by libspotify. See https://sourceforge.net/projects/xtestify/forums/forum/958612/topic/3482665?message=7893874

[Eero Aaltonen (ejn)]

Interestingly, this symptom disappeared when I switched network-manager to wicd

[David Fraser (davidf)]

I had this when turning on and off the Wireless option from Network Manager manually. I attached gdb to the process and got the attached stack trace. I then continued execution, saw the CPU usage go up again, interrupted and got exactly the same stack trace. So this should represent at least some of what's going on in this situation.

[Jon Jennings (jon100)]

Also affecting me. Occurs whether monitoring eth0 or wlan0

Architecture: i386
Machine: Acer AS 1410
DistroRelease: Ubuntu 10.04
Package: ntop 3:3.3-13
Kernel: 2.6.32-23-generic

[Nathan Moore (nategoose)]

The same thing happens to dumpcap when you hibernate while capturing with WireShark.

[strk (strk)]

I get the 100% CPU used by ntop too. Dunno in which conditions, but happened twice already.
I kill the process to fix.
Closing anything else doesn't help.
Doesn't happen right after resume from hibernate, but sometime later (no idea triggered by what)

[Justin Cook (jcook713)]

This happens to me like clockwork -
Fresh start -> 1st suspend ntop goes to 100%
I kill the ntop process and I'm fine for all future suspends.

Package: ntop 3:3.3-13
PackageArchitecture: i386
ProcEnviron:
 SHELL=/bin/bash
 PATH=(custom, user)
 LANG=en_US.utf8
ProcVersionSignature: Ubuntu 2.6.32-29.58-generic 2.6.32.28+drm33.13
SourcePackage: ntop
Tags: lucid
Uname: Linux 2.6.32-29-generic i686

On a Dell XPS M1330 - the one that originally came direct from Dell with Ubuntu preinstalled.

[Justin Cook (jcook713)]

Note on my previous comment that everything is ok(ntop not at 100%) on fresh start, trouble comes after 1st suspend.

[Ludovico Cavedon (cavedon)]

On 03/03/2011 11:55 AM, Justin Cook wrote:
> This happens to me like clockwork -
> Fresh start -> 1st suspend ntop goes to 100%
> I kill the ntop process and I'm fine for all future suspends.

Do you mean that you kill it, restart it (how? "service ntop restart"?),
and then for future suspends ntop keeps running without going to 100% of
CPU?

So it looks like it only happens for the first suspend after the machine
boot...

What happens if you do this:
1. fresh boot
2. stop ntop (service ntop stop)
3. suspend
4. resume
5. start ntop (service ntop start)
6. suspend
7. resume

Is it going to 100%?

> Package: ntop 3:3.3-13

This version is pretty old and not maintained.

Could you try with version 4.0.3 from
https://launchpad.net/~cavedon/+archive/ppa
please?

Thanks,
Ludovico

[Justin Cook (jcook713)]

On 03/03/2011 04:47 PM, Ludovico Cavedon wrote:
> On 03/03/2011 11:55 AM, Justin Cook wrote:
>> This happens to me like clockwork -
>> Fresh start -> 1st suspend ntop goes to 100%
>> I kill the ntop process and I'm fine for all future suspends.
>
> Do you mean that you kill it, restart it (how? "service ntop restart"?),
> and then for future suspends ntop keeps running without going to 100% of
> CPU?

 I kill it with "sudo kill <pid>" and that is it, I don't manually
restart it. I couldn't tell you if ntop is or isn't running after future
suspends, I will look from now on and see.

> So it looks like it only happens for the first suspend after the machine
> boot...
>
> What happens if you do this:
> 1. fresh boot
> 2. stop ntop (service ntop stop)
> 3. suspend
> 4. resume
> 5. start ntop (service ntop start)
> 6. suspend
> 7. resume
>
> Is it going to 100%?

 Give me a bit and I'll attempt this and report back...

>> Package: ntop 3:3.3-13
>
> This version is pretty old and not maintained.
>
> Could you try with version 4.0.3 from
> https://launchpad.net/~cavedon/+archive/ppa
> please?

 I will after I attempt the above.

> Thanks,
> Ludovico
>

much thanks,

Justin

[Ludovico Cavedon (cavedon)]

On 03/03/2011 03:22 PM, Justin Cook wrote:
>> Do you mean that you kill it, restart it (how? "service ntop restart"?),
>> and then for future suspends ntop keeps running without going to 100% of
>> CPU?
>
> I kill it with "sudo kill <pid>" and that is it, I don't manually
> restart it. I couldn't tell you if ntop is or isn't running after future
> suspends, I will look from now on and see.

Oh, ok, I assumed you were restarting it, as ntop is not restarted on
its own.

Then no need to do the test about the multiple suspends.

>>> Package: ntop 3:3.3-13
>>
>> This version is pretty old and not maintained.
>>
>> Could you try with version 4.0.3 from
>> https://launchpad.net/~cavedon/+archive/ppa
>> please?
>
> I will after I attempt the above.

Please just do this test.

Thanks for your reply,
Ludovico

[Justin Cook (jcook713)]

On 03/03/2011 07:06 PM, Ludovico Cavedon wrote:
>>>> Package: ntop 3:3.3-13
>>>
>>> This version is pretty old and not maintained.
>>>
>>> Could you try with version 4.0.3 from
>>> https://launchpad.net/~cavedon/+archive/ppa
>>> please?
>>
>> I will after I attempt the above.
>
> Please just do this test.

 Upgraded to this version, and after several days and suspends it seems
the problem continues if I restart ntop. As in subsequent
suspend/resumes ntop goes to 100% cpu. So I was preventing future
problems by simply stopping and not restarting ntop.

Consider this a quick update, I will see how it goes with restarting
ntop on future suspend/resumes just to test.

Justin

[Justin Cook (jcook713)]

Still a problem on resume from suspending - basically have to shut the service ntop off. Is ntop neccessary? Can I just uninstall it? I'm afraid one of these days I'm going to resume from an initial suspend and forget and this is going to burn my CPU out.

Package: ntop
Versions:
3:4.0.3+dfsg1-3~lucid1~ppa2 (/var/lib/apt/lists/ppa.launchpad.net_cavedon_ppa_ubuntu_dists_lucid_main_binary-i386_Packages) (/var/lib/dpkg/status)
 Description Language:
                 File: /var/lib/apt/lists/ppa.launchpad.net_cavedon_ppa_ubuntu_dists_lucid_main_binary-i386_Packages
                  MD5: b5c31998529e1e9f052e8890689a8ebd

3:3.3-13 (/var/lib/apt/lists/mirrors.us.kernel.org_ubuntu_dists_lucid_universe_binary-i386_Packages)
 Description Language:
                 File: /var/lib/apt/lists/mirrors.us.kernel.org_ubuntu_dists_lucid_universe_binary-i386_Packages
                  MD5: dc3c6cda127daed2b0986f866adae213

Reverse Depends:
  ntop-data,ntop 3:4.0
  ntop-data,ntop 3:4.0
  ntop-data,ntop 3:4.0.3+dfsg1-3~lucid1~ppa2
  harden-nids,ntop
Dependencies:
3:4.0.3+dfsg1-3~lucid1~ppa2 - libc6 (2 2.4) libgdbm3 (2 1.8.3) libgeoip1 (2 1.4.6.dfsg) libpcap0.8 (2 0.9.8) libpython2.6 (2 2.6) librrd4 (2 1.3.0) zlib1g (2 1:1.1.4) debconf (18 0.5) debconf-2.0 (0 (null)) ntop-data (5 3:4.0.3+dfsg1-3~lucid1~ppa2) python-mako (0 (null)) net-tools (0 (null)) adduser (0 (null)) passwd (0 (null)) graphviz (0 (null)) gsfonts (0 (null))
3:3.3-13 - libc6 (2 2.7) libgdbm3 (2 1.8.3) libpcap0.8 (2 0.9.8) librrd4 (2 1.3.0) libssl0.9.8 (2 0.9.8k-1) zlib1g (2 1:1.1.4) debconf (18 1.2.0) debconf-2.0 (0 (null)) adduser (0 (null)) graphviz (0 (null)) gsfonts (0 (null))
Provides:
3:4.0.3+dfsg1-3~lucid1~ppa2 -
3:3.3-13 -
Reverse Provides:

[R.B. Boyer (rboyer)]

This happens to me like clockwork on an up-to-date install of lucid. As advertised, killing the ntop process "fixes" it, though I suspect killing ntop has undesirable side effects.

Has anyone been able to reproduce on precise yet?

[jvin248 (jvin248)]

Had this happen after resume from suspend on 10.04 installation with all recent updates applied (July 2012).
Another option, aside from killing ntop, that also works is the suggestion:

$ sudo /etc/init.d/ntop restart

[max (max-illis)]

Does anyone know if this is being looked at? ntop is frequently consuming 100% of 1 CPU

I 'kill' ntop and then at some point it occurs again - twice today :(
for the moment I've uninstalled it

in my case this is not related to suspend at all

btw - I'm running 12.10

[Ludovico Cavedon (cavedon)]

I was not able to reproduce the issue by playing with the network interfaces and suspending (with version 4.99.3).
It might be a big that has already been fixed by upstream.

I have uploaded it to my PPA. Can you try with it, please?
https://launchpad.net/~cavedon/+archive/ntop/

Thanks.