telldusd CPU + memory usage >80%!

[jefft]

Hi,

Can anyone help me to work out what's causing this problem, please?

I'm running telldusd 2.1.0, compiled on Fedora Core 16 x86 64-bit. It seems to work, apart from the annoying "An error occurred while communicating with TellStick" after each command to tdtool (the commands via tdtool do work as long as they're one at a time, but multiple activations don't).

However, here's the big problem:
$ top
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1099 nobody 20 0 1006m 540m 1496 S 99.2 13.7 8:04.36 telldusd

The telldusd daemon is chewing up a whole CPU core and an awful lot of memory. This snapshot is 10 mins after a system reboot and before telldusd has been asked to do anything at all to any device. What on earth is it doing with 1.5GB of my memory and a whole CPU 2GHz core?! That smacks of a loop, or memory leakage on a grand scale.

This slows down the whole server so much that I've had to switch off telldusd for the moment and revert to manual control for the devices

Any ideas what's wrong are very much appreciated! Also, if there's a fix for the "An error occurred..." gremlin, that would be nice too but it's very much secondary.

Thanks in advance,

Jeff


More system info: ----------------------------------------------------------------------------------------------------------------------------------

The Tellstick is batch 13.

$ telldusd --version
telldusd 2.1.0

Copyright (C) 2011 Telldus Technologies AB

Written by Micke Prag <micke.prag@telldus.se>

$ uname -a
Linux machine.subdomain.local 3.1.6-1.fc16.x86_64 #1 SMP Wed Dec 21 22:41:17 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

$ which telldusd
/usr/local/sbin/telldusd

$ ls -l /usr/local/sbin/telldusd
-rwxr-xr-x 1 root root 602872 Dec 24 16:12 /usr/local/sbin/telldusd

$ grep "telldus|ftdi" /var/log/messages
Dec 25 20:58:08 machine kernel: [ 31.043903] ftdi_sio 2-2:1.0: FTDI USB Serial Device converter detected
Dec 25 20:58:08 machine kernel: [ 31.046392] usbcore: registered new interface driver ftdi_sio
Dec 25 20:58:08 machine kernel: [ 31.046394] ftdi_sio: v1.6.0:USB FTDI Serial Converters Driver
Dec 25 20:58:08 machine kernel: [ 35.146990] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
Dec 25 20:58:08 machine kernel: [ 35.147037] ftdi_sio 2-2:1.0: device disconnected
Dec 25 20:58:08 machine telldusd: telldusd daemon starting up

--------------------------------------------------------------------------------------------------------------------------------------------------------

[jefft]

Having left it running for 24 hours or so since the reboot, it's become steadily worse...

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1099 nobody 39 19 3502m 3.0g 80 S 98.5 76.7 1340:52 telldusd

Three and a half gigabytes of memory, and a whole CPU! This is killing the system, so much so that the next command I'm going to have to give is "kill -9 1099" Cannot have processes that behave like this on the system, it's fatal. The next biggest memory user is only 500M and that's a database server, which is doing work, not a daemon sitting idle waiting for commands to pass to a USB port.

[mdv]

I have a similar problem.

I run 64-bit Arch linux and two days ago I noticed that the system became very sluggish. An 'uptime' revealed that the CPU load was over 50 (on a dual core system)! I traced the problem to telldusd and at the time I had to restart my system because it was simply not responding but after the restart I have monitored the CPU load, I have found that when it inexplicably is rising a simple '/etc/rc.d/telldusd restart' brings it down again.

Now I have put in my crontab that telldusd restarts every hour, but it should not have to be like that I suppose. It is funny though that the problems started two days ago since it has worked flawlessly before.

BR,
Martin

[stefan.persson]

Could you first make sure that only one telldusd is running? Two or more running at the same time can cause this. Could you then check if ftdi_sio is loaded in the kernel?

[mdv]

Thanks. I will check if the ftdi_sio module is loaded.

I had to make an addition to what I did in the post above. Simply restarting telldusd was not enough; I ran a 'top' this morning which told me that I had 790 tasks (many of which were telldusd). After a 'killall telldusd', I had only 97. So, that seems to be my problem, but perhaps that will be resolved once the ftdi_sio module is loaded (for the moment I am assuming that it is not)?

[stefan.persson]

If more than one telldusd runs at the same time, it will cause high CPU usage. Not surprising that you got a high CPU usage with that many telldusd running.

So, why are there so many telldusd? Do you have a script to restart them or something?

It's actually the contrary with ftdi_sio, if it IS loaded it may cause problems. But you can probably ignore that, the problem is most probably due to all the telldusd-processes.

[mdv]

I do not know why I had all the telldusds running, it of course starts when booting but on Sunday last week (when the problems started), it was 20 days or so since last reboot. On Sunday, the system became very slow and I noticed the high CPU load. Now there were all those telldusds running and to be honest I do not know why.

I have scripts running tdtool, but not telldusd per se. I do use the C program for callback published on the telldus developer site, but I have been using that for a few months now and it has been working well. I added a line in my crontab to run 'killall telldusd' every hour at HH:58, but now, about 30 minutes later it seems I do not have a lot of telldusds running, just one.

Well, thank you for your input. I will continue monitoring this closely and if I find out why I had all those telldusds running, I will post back here. I cannot check the log files as I had to disble logging, since presumably all those telldusds exploded input into the logfiles and they ballooned into huge files that eventually filled the entire disk.