TeamViewer IOT Agent läuft obwohl in GUI disabled

[RR4711]

Hi,
ich hab hier den Effekt, daß ich in HTOP immer einen Prozess sehe, der zum Teamviewer gehört und der sich alle paar Sekunden durchaus auch mal 90% CPU Zeit gönnt (warum eigentlich?)
Mal schnell gegrepped:

Code: Select all

pi@sopdetpump ~$ ps -aux | grep "iot"
root      1686 22.2  1.6  49232 15904 ?        Ssl  10:27   9:56 /usr/libexec/teamviewer-iot-agent/teamviewer-iot-mon-agent -C /etc/teamviewer-iot-agent/iotmonagent.conf

und das obwohl in der Web GUI angezeigt wird daß der Teamviewer abgeschaltet ist. Wir das nicht "Echtzeit" geprüft von der GUI? Ich muss mich doch drauf verlassen können, daß Dienste die ich nicht brauche auch vollständig deaktiviert sind und keine Ressourcen verbrauchen.

Achja laut systemd ist der auch aus:

Code: Select all

pi@sopdetpump ~$ service --status-all
 [ + ]  alsa-utils
 [ + ]  apache-htcacheclean
 [ + ]  apache2
 [ + ]  avahi-daemon
 [ - ]  bluetooth
 [ - ]  console-setup.sh
 [ + ]  cpufrequtils
 [ + ]  cron
 [ + ]  dbus
 [ + ]  dhcpcd
 [ - ]  dphys-swapfile
 [ - ]  hwclock.sh
 [ - ]  keyboard-setup.sh
 [ + ]  kmod
 [ + ]  lightdm
 [ + ]  loadcpufreq
 [ + ]  networking
 [ - ]  nfs-common
 [ + ]  ntp
 [ - ]  paxctld
 [ - ]  plymouth
 [ - ]  plymouth-log
 [ + ]  procps
 [ - ]  raspi-config
 [ - ]  rpcbind
 [ - ]  rsync
 [ + ]  rsyslog
 [ + ]  ssh
 [ - ]  sudo
 [ - ]  teamviewer-iot-mon-agent
 [ - ]  teamviewer-revpi
 [ + ]  triggerhappy
 [ + ]  udev
 [ - ]  x11-common

WTF?

Markus

[dirk]

Hallo Markus, ich habe gerade einen schnellen Test gemacht und habe im WebStatus TeamViewer erst aktiviert und dann deaktiviert. Ich konnte sehen, dass die Prozesse noch kurz 'gezuckelt' haben dann aber beendet waren und auch nach einigen Minuten beendet blieben. Bist Du sicher, dass Du das aktuellste System hast? War das ein einmaliges Problem oder ist das öfter aufgetaucht?

[RR4711]

Es ist nicht ganz aktuell, weil es das System ist wo wir noch mit Euch intern die Tests mit den AIO Karten machen und ich wollte es noch nicht komplett updaten. Sollte aber trotzdem nicht sein oder?

Ich mach die Tage mal ein Image davon bevor ich es update, und melde mich dasnn nochmal wenn das Problem nach dem Update weg sein sollte.

Markus

[dirk]

Danke für Deine Mithilfe hier.

[RR4711]

Nebenbei: es "überlebt" auch jeden reboot. Also ja, ist reproduzierbar. Alles weitere dann nach Update.

[RR4711]

Das scheint jetzt OK zu sein nach dem Update. Dafür kommt das Pictory nicht mit meiner alten Config klar, weil es da ja noch mehr "Action" Bits gab. Da muss ich jetzt mal das alte Posting rauskramen, da gabs glaub schon nen Fix.

Markus

[RR4711]

Ich werd noch bekloppt.
Nach reboot ist das Ding plötzlich wieder da (evtl. delayed, das konnte ich jetzt nicht ausschließen)



WEB Interface:



Services:

Code: Select all

pi@sopdetpump ~$ service --status-all
 [ + ]  alsa-utils
 [ + ]  apache-htcacheclean
 [ + ]  apache2
 [ + ]  avahi-daemon
 [ - ]  bluetooth
 [ - ]  console-setup.sh
 [ + ]  cpufrequtils
 [ + ]  cron
 [ + ]  dbus
 [ + ]  dhcpcd
 [ - ]  dphys-swapfile
 [ - ]  hwclock.sh
 [ - ]  keyboard-setup.sh
 [ + ]  kmod
 [ + ]  lightdm
 [ + ]  loadcpufreq
 [ + ]  networking
 [ - ]  nfs-common
 [ + ]  ntp
 [ - ]  paxctld
 [ - ]  plymouth
 [ - ]  plymouth-log
 [ + ]  procps
 [ - ]  raspi-config
 [ - ]  rpcbind
 [ - ]  rsync
 [ + ]  rsyslog
 [ + ]  ssh
 [ - ]  sudo
 [ - ]  teamviewer-iot-mon-agent
 [ - ]  teamviewer-revpi
 [ + ]  triggerhappy
 [ + ]  udev
 [ - ]  x11-common
pi@sopdetpump ~$

Mir fällt nix mehr ein, evtl. ein Cronjob der da "vergessen" wurde? Ich hab nichts an der crontab editiert wissentlich.

Edit: crontab -e fragt mich erstmal nach dem Standardeditor, also da wurde definitiv noch nie was gefummelt (zumindest als pi user).

Als root sieht es ähnlich aus:

Code: Select all

pi@sopdetpump ~$ sudo crontab -e
no crontab for root - using an empty one

Select an editor.  To change later, run 'select-editor'.
  1. /bin/ed
  2. /bin/nano        <---- easiest
  3. /usr/bin/code-oss
  4. /usr/bin/jed
  5. /usr/bin/vim.tiny

Choose 1-5 [2]: 

Ich geb auf. Könnte sich das bitte mal jemand anschauen wo dieser Prozess gestartet wird anhand des Pfades z.B.?

Markus

[RR4711]

So, also es scheint so zu sein, daß da zwei Symlinks in /etc/rc5.d "stehengelassen" werden, welche dann den Prozess starten. (Edit: auch in den anderen runlevels)
Ich weiß nicht, ob die beim Updaten vom Teamviewer Paket dort automatisch dort hingeschrieben werden (was ich mir durchaus vorstellen könnte). Die müsste dann von der WebGUI beim deaktivieren gelöscht werden, bzw. es müsste geprüft werden, ob sie vorhanden sind und die Anzeige in der WebGUI muss dann auf "aktiviert" springen.

Code: Select all

pi@sopdetpump /etc/rc5.d$ ll
total 0
lrwxrwxrwx 1 root root 29 Mar 14  2019 K01apache-htcacheclean -> ../init.d/apache-htcacheclean
lrwxrwxrwx 1 root root 24 Nov 13  2018 K01dphys-swapfile -> ../init.d/dphys-swapfile
lrwxrwxrwx 1 root root 22 Nov 13  2018 K01raspi-config -> ../init.d/raspi-config
lrwxrwxrwx 1 root root 26 Feb 26  2020 K01teamviewer-revpi -> ../init.d/teamviewer-revpi
lrwxrwxrwx 1 root root 17 Mar 14  2019 S01apache2 -> ../init.d/apache2
lrwxrwxrwx 1 root root 22 Nov 13  2018 S01avahi-daemon -> ../init.d/avahi-daemon
lrwxrwxrwx 1 root root 19 Nov 13  2018 S01bluetooth -> ../init.d/bluetooth
lrwxrwxrwx 1 root root 26 Nov 13  2018 S01console-setup.sh -> ../init.d/console-setup.sh
lrwxrwxrwx 1 root root 22 Mar 14  2019 S01cpufrequtils -> ../init.d/cpufrequtils
lrwxrwxrwx 1 root root 14 Nov 13  2018 S01cron -> ../init.d/cron
lrwxrwxrwx 1 root root 14 Nov 13  2018 S01dbus -> ../init.d/dbus
lrwxrwxrwx 1 root root 16 Nov 13  2018 S01dhcpcd -> ../init.d/dhcpcd
lrwxrwxrwx 1 root root 17 Nov 13  2018 S01lightdm -> ../init.d/lightdm
lrwxrwxrwx 1 root root 21 Mar 14  2019 S01loadcpufreq -> ../init.d/loadcpufreq
lrwxrwxrwx 1 root root 13 Apr  7 18:57 S01ntp -> ../init.d/ntp
lrwxrwxrwx 1 root root 17 Nov 13  2018 S01paxctld -> ../init.d/paxctld
lrwxrwxrwx 1 root root 18 Nov 13  2018 S01plymouth -> ../init.d/plymouth
lrwxrwxrwx 1 root root 15 Nov 13  2018 S01rsync -> ../init.d/rsync
lrwxrwxrwx 1 root root 17 Nov 13  2018 S01rsyslog -> ../init.d/rsyslog
lrwxrwxrwx 1 root root 13 Nov 13  2018 S01ssh -> ../init.d/ssh
lrwxrwxrwx 1 root root 34 Feb 26  2020 S01teamviewer-iot-mon-agent -> ../init.d/teamviewer-iot-mon-agent
lrwxrwxrwx 1 root root 22 Nov 13  2018 S01triggerhappy -> ../init.d/triggerhappy

Das dürfte den Teil erklären, allerdings nicht, warum der Prozess sporadisch > 90% CPU zieht. Ich schmeiß die Symlinks jetzt auf jeden Fall mal bei mir raus.

Markus

[RR4711]

systemd startet das Teil immer noch. Obwohl es laut service --status-all deaktiviert ist. Ich schmeiß jetzt das teamviever paket runter, das wird mir zu albern.

[dirk]

Hallo Markus, ohje ich hoffe Dein Frust sitzt nicht allzu tief. Ja sicherlich ist das Entfernen des Paketes dann die beste alternative. Wir haben das nochmals genauer untersucht und konnten einen Fehler feststellen.
Ein Symlink wird nicht entfernt. Wir sind dran. Vielen Dank für Deine Mithilfe.