Remote-Support-Client nimmt zunehmend mehr Speicher in Anspruch

[ChristophR]

Zur Info:
Ich hatte um 03:37 Uhr eine Zwangstrennung, seitdem ist der Prozess lt-armv7l_ELF auf 45% RAM-Nutzung gesprungen.

[LutzB]

Hast Du eine Idee, wo der Speicherbedarf vorher lag?

[ChristophR]

Hast Du eine Idee, wo der Speicherbedarf vorher lag?

War in der Liste glaube gar nicht drin, auf jeden Fall höchstens 1%

P.S: Korrigiere: Es waren 2,3% und war doch in der Liste

[ChristophR]

Ich habe zusammen mit der KI ein Script gebaut, welches alle 5 Minuten einen Screenshot im geöffneten Systeminfo macht.
Voraussetzung ist node.js mit puppeteer und chrome.
Läuft bei mir in einem Docker Image auf dem NAS.
Vielleicht kann das ja jemand gebrauchen:

Code: Alles auswählen

const puppeteer = require('puppeteer');
const fs = require('fs');
const path = require('path');

(async () => {
  const outputDir = '/mnt/sysinfo';
  const browser = await puppeteer.launch({
    executablePath: '/usr/bin/chromium',
    headless: true,
    args: ['--no-sandbox']
  });

  const page = await browser.newPage();
  await page.setViewport({ width: 1600, height: 900 });

  console.log('[INFO] Öffne Systeminfo-Seite...');
  await page.goto('http://openwb/openWB/web/maintenance/systeminfo.html', {
    waitUntil: 'load'
  });

  console.log('[INFO] Seite erfolgreich geladen – warte 15 Sekunden...');
  await new Promise(resolve => setTimeout(resolve, 15000));

  // 🟢 Erster Screenshot direkt nach dem Warten
  const firstTimestamp = new Date().toISOString().replace(/[:.]/g, '-');
  const firstFilename = `systeminfo-${firstTimestamp}.png`;
  const firstPath = path.join(outputDir, firstFilename);

  await page.screenshot({
    path: firstPath,
    fullPage: true
  });

  console.log(`[OK] Erster Screenshot gespeichert: ${firstFilename}`);

  // 🔁 Danach alle 5 Minuten Screenshot + Löschlogik
  const maxFiles = 500;

  console.log('[INFO] Screenshot-Loop gestartet – alle 5 Minuten wird gespeichert');

  setInterval(async () => {
    try {
      const timestamp = new Date().toISOString().replace(/[:.]/g, '-');
      const filename = `systeminfo-${timestamp}.png`;
      const filepath = path.join(outputDir, filename);

      await page.screenshot({
        path: filepath,
        fullPage: true
      });

      console.log(`[OK] Screenshot gespeichert: ${filename}`);

      const files = fs.readdirSync(outputDir)
        .filter(f => f.startsWith('systeminfo-') && f.endsWith('.png'))
        .sort();

      if (files.length > maxFiles) {
        const toDelete = files.slice(0, files.length - maxFiles);
        toDelete.forEach(f => fs.unlinkSync(path.join(outputDir, f)));
        console.log(`[CLEANUP] ${toDelete.length} alte Screenshots gelöscht`);
      }

    } catch (err) {
      console.error(`[ERROR] Screenshot fehlgeschlagen: ${err.message}`);
    }
  }, 5 * 60 * 1000); // alle 5 Minuten
})();

[LutzB]

Hast Du eine Idee, wo der Speicherbedarf vorher lag?

War in der Liste glaube gar nicht drin, auf jeden Fall höchstens 1%

P.S: Korrigiere: Es waren 2,3% und war doch in der Liste

[ChristophR]

Hast Du eine Idee, wo der Speicherbedarf vorher lag?

War in der Liste glaube gar nicht drin, auf jeden Fall höchstens 1%

P.S: Korrigiere: Es waren 2,3% und war doch in der Liste

Die Zwangstrennung um 3:36 Uhr hat den Speicherverbrauch nochmal nach oben getrieben:
Vor der Zwangstrennung:

systeminfo-2025-09-10T01-32-30-807Z.png

(480.39 KiB) Noch nie heruntergeladen

Danach:

systeminfo-2025-09-10T01-52-30-821Z.png

(466.42 KiB) Noch nie heruntergeladen

Um 4:40Uhr ist der Speicherverbrauch des Remoteclients dann verschwunden:

systeminfo-2025-09-10T02-37-30-598Z.png

(460.54 KiB) Noch nie heruntergeladen

Kurz vorher sah es so aus:

systeminfo-2025-09-10T02-32-30-498Z.png

(463.45 KiB) Noch nie heruntergeladen

Das remote_support.log sagt dazu:

Code: Alles auswählen

2025-09-10 04:33:45,598 - {RemoteSupport:106} - {INFO:Thread-1}: Connected
2025-09-10 04:33:45,662 - {RemoteSupport:126} - {DEBUG:Thread-1}: Topic: openWB-remote/valid_partner_ids, Message: []
2025-09-10 04:33:53,253 - {RemoteSupport:126} - {DEBUG:Thread-1}: Topic: openWB-remote/valid_partner_ids, Message: []

Gestern früh war die openWB noch authentifiziert, ich musste mich beim Aufrufen nicht neu anmelden.
Heute früh kam ein neuer Anmeldedialog.

[zut]

Vermutlich hat der OOM-Killer des Kernels den Remote Client als Speicherschwein identifiziert und beendet.

Ich schlage neben der Fehlersuche im Client vor, den Client nach einer Zeit der Inaktivität zu beenden, auch wenn das nur Symptome bekämpft.

[LutzB]

Vermutlich hat der OOM-Killer des Kernels den Remote Client als Speicherschwein identifiziert und beendet.

War zu erwarten.

Code: Alles auswählen

[119601.755900] Out of memory: Killed process 14979 (lt-armv7l_ELF) total-vm:809772kB, anon-rss:535280kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:600kB oom_score_adj:0

[ChristophR]

Vermutlich hat der OOM-Killer des Kernels den Remote Client als Speicherschwein identifiziert und beendet.

War zu erwwarten.

Code: Alles auswählen

[119601.755900] Out of memory: Killed process 14979 (lt-armv7l_ELF) total-vm:809772kB, anon-rss:535280kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:600kB oom_score_adj:0

Nachdem jetzt klar ist, dass der Client frei dreht, wenn er kein Internet findet, kann er sich (als Workaround) nicht selbst neu starten, wenn er keine Verbindung hinkriegt?
Ohne Internetverbindung ist er ja vermutlich gar nicht so wichtig...

[Gero]

Wenn er nicht ins Internet kommt, könnte er sich ja auch für ein paar Minuten schlafen legen und es dann nochmal probieren. Der sollte doch eh immer schlafen und darauf warten, von draußen angestupat zu werden, oder? Gut, er muss auch noch regelmäßig nachkucken, ob seine nach draussen kommunizierte Adresse immer noch gültig ist.

Das ist im Grunde ja die selbe Logik wie bei DynDNS, hier verwendet für Support und Cloud.