Teamviewer memory leak causes periodic reboot

[matthewh]

Hi All,
We have a Revolution Pi installed at a client site with our own custom software acting as a Modbus data concentrator. The Pi was experiencing a periodic reboot, with quite a specific period. A reboot every 710 hours, plus or minus a few hours (that's around 29 days). The site is difficult to access and has no external network connection, so it was difficult monitor. We rewrote our software to try to eliminate any leaks, with no change.
Finally we got to site at a time when we could observe what was going on. Here is the output of "top" after 20 days:

top - 08:43:42 up 20 days, 34 min, 1 user, load average: 3.15, 3.08, 3.08
Tasks: 160 total, 1 running, 159 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.3 us, 1.0 sy, 0.0 ni, 96.4 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st
KiB Mem : 949036 total, 29560 free, 605972 used, 313504 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 265236 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
[other processes elided]
1504 root 20 0 597516 556340 4092 S 0.0 58.6 4:31.90 teamviewer-iot-
[other processes elided]

It seems the "teamviewer-iot-" process is gradually consuming all the memory.

Note that we are not using teamviewer and had the teamviewer service set to disabled on the services web page of the revolution pi.

We attempted to disable teamviewer from the command line like this:
sudo teamviewer-iot-agent disable daemon
sudo teamviewer-iot-agent stop daemon

However, the teamviewer process returned after reboot.

Finally we managed to disable it like this:
sudo systemctl disable teamviewer-iot-mon-agent.service
sudo systemctl stop teamviewer-iot-mon-agent.service

I hope this is helpful to anyone else experiencing this issue.
Perhaps also the teamviewer "disable" switch on the web page could be investigated to make sure it really does disable this service.

Regards,
Matthew

[dirk]

Hi matthewh, thank you for your report and your ideas. I have allowed me to move your post here to the TeamViewer board. Could you be so kind to post or send us a SOS report so that we are able to investigate this important issue?

[matthewh]

Thanks Dirk. This particular pi will never again be connected to the Internet, so we would require an offline installer for the SOS report tools. In practical terms, we will probably not return to this site for a while unless the problem is not actually resolved and further reboots occur.
If I get an opportunity, I will try to set up a simulation on a pi in the office to see if we can replicate the problem, although we don't have the same model pi available.

[matthewh]

Hi Dirk. I can see the same problem on my test Pi in the office, so I have collected and sent the SOS report as requested.
I have disabled teamviewer on the web page. I can see using "top" that the teamviewer-iot-agent process is running, and the memory usage gradually increases. On this pi it increased by about 1% of total memory per hour.
Matthew

[dirk]

Hi Matthew, thank you so much for your detailed support here and for emailing us an SOS report. After a review I can say that I can't really pick out anything really noticeable.
It looks like your system is intentionally running at a lower frequency so not at full clock speed. Furthermore, it is not clear to me if you accidentally configured a DIO module,
because it is configured but could not be found.

One idea is to pull up the system on Buster. You can download an image from the store. On occasion I will test the things you mentioned with the Buster image.

[dirk]

Hi Matthew, thanks for your bug report. I just tested again with the latest Buster image and I can say that this unpleasantness has been fixed.
If in the web status the TeamViewer service was activated and also deactivated again,
these settings are now immediately active. Even after a reboot.