In dem Modul sehe ich für das Feld „OSVersion“ schon die Version des Betriebssystems, nicht die vom IP-Symcon.
Und darüber bin ich gestolpert: in der Ausgabe von @traxanos kommt ja „5.5.11“ raus und bei dir „4.14.114“.
Wenn die OS-Version bei IPS-Updates gleich bleibt - dann ist das ja nicht anders als auf den anderen Systemen, auch da geben ich ja die Version des Ubuntu bzw vom Raspbian aus.
Die IPS-Version kann ja jeder mit IPS_GetKernelVersion() bzw. IPS_GetKernelRevision() ermitteln.
4.14.114 ist übrigens die Version vom genutzten Kernel - nicht unbedingt die „Version“ vom OS. Die OS Version wäre für mich sowas wie Ubuntu 20.20. Und das passende Gegenstück wäre SymOS 5.5. Die Kernel-Version 4.4.114 ist wieder etwas anderes
Ah, wichtige Info. Ich verstehe das gleiche wie Du, die Kernelversion ist im Regelfall eher unwichtig, bei mir steht da „Ubuntu 18.04.5 LTS“ resp. „Raspbian GNU/Linux 10 (buster)“.
Also mach ich das, wie von @traxanos vorgeschlagen, unter Berücksichtigung, das dort mehrere Dateien stehen können und ich die jüngste nehme.
Aktuel spiele ich mit Prometheus / Grafana rum, da wir das in der Firma auch nutzen wollen für Linux-Systeme.
Docker - naja, bin kein Freund davon
Ich werde aber vermuttlich erst mal meine VM’s auf einen anderen Server umziehen, der kleine IntelNUC ist speichermässig am Ende , das muss was größeres her.
„Model of CPU“ funktioniert bei mir (pi4 mit buster),
Raspbian GNU/Linux 10 (buster)
$ lsb_release -ds
Raspbian GNU/Linux 10 (buster)
$ lscpu
Architecture: armv7l
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
Vendor ID: ARM
Model: 4
Model name: Cortex-A53
Stepping: r0p4
CPU max MHz: 1200,0000
CPU min MHz: 600,0000
BogoMIPS: 38.40
Flags: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
ich habe es gerade auch auf einen ‚stretch‘ versucht
$ lsb_release -ds
Raspbian GNU/Linux 9.13 (stretch)
$ lscpu
Architecture: armv7l
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
Model: 4
Model name: ARMv7 Processor rev 4 (v7l)
CPU max MHz: 1200,0000
CPU min MHz: 600,0000
BogoMIPS: 38.40
Flags: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
kannst Du mal das bei dir ausprobieren, was da kommt? und bitte mal „cat /proc/cpuinfo“
„Swap“: ja, kein Problem, baue ich ein
@traxanos, @HarmonyFan: könnte ihr mal bitte schauen, ob bei ‚cat /proc/meminfo‘ die Array-Elemente SwapTotal und SwapFree dabei sind (also Docker und SymBox) ?
Hi demel,
bei mir sieht es gut aus. Ich benutze Docker mit erweiterten Rechten, d.h. ich komme u.a. vom Docker an die Festplatten ran. Interessant wäre es wenn sich jemand meldet der ein Docker ohne diese erweiterten Rechte benutzt.
Ich habe kein einziges System in den letzten 10 Jahren mehr mit Swap im Einsatz. Warum sollte ich in der Zeit von soviel RAM noch einen Swap verwenden. Selbst unsere Server im Rechenzentrum verwenden keinen Swap. Schau mal wie die Performance einbricht wenn ein Server swappen muss.
hmm, spannend, natürlich ist es klar, das ein Server, der active pages swappen muss in Stress gerät bis zur trashen, aber bei zur Zeit nicht benötigten Pages (und das ist u.U. ein erheblicher Teil des Codes) ist das ja nun überhaupt kein Problem. Bei den üblichen Unix/Linux-Derivaten wird der Swap ja vorsorglich gefüllt um schnell Pages freigeben zu können,
Das man darauf achten sollte, mehr als genug Speicher da ist, logisch und heutzutage auch mit überschaubaren Kosten verbunden. Aber warum auf die Sicherheit zu verzichten, das das System auch bei - vielleicht nur temporär knapper Resource - noch ordnungsgemäß läuft kämen mir nicht den Sinn. Immerhin wird das System bei knappem Speicher dann einfach Prozesse killen und das kann dann auch gerade mal der Prozess sein, der wirklich wichtig ist. Ich verwend Unix-Server schon mein ganzes Berufsleben (35J+) in medizinischen Einsatzumfeld.
Aber egal, so hat jeder sein Vorgehensweise, die zu zu seinem Anforderungsprofil passt, hatte mich einfach mal interessiert.
Wir betreiben hochverfügbare Systeme. Wenn dir da ein Prozess Amok läuft und anfängt zu Swapen ist der komplette Server nicht mehr erreichbar Load im hochen stelligen Bereich. Kein SSH-Login mehr, SDS Impact… Also kommst du nicht mal mehr in den Genuss den Dienst zu beenden. Und da man ja heutzutage nicht mehr nur eine Anwendung auf einem Server laufen lässt hat das Problem Auswirkungen auf alles Anwendungen bzw. teilweise sogar auf den kompletten Cluster. Da plane ich lieber Reserven ein.
nun, dann hätte ich in ApplyChanges() dem Memory-Status abrufen müssen - und in ApplyChanges() möchte ich nur auf so wenig Dinge ausserhalb des Moduls zugreifen (also hier exec()).
On the fly Variable zu erzeugen oder wegzunehmen, halte ich für nicht sehr intuitiv und mache es daher nicht.
Zudem wäre das eine implizite Logik des Moduls, die der Anwender wissen müsste, wenn er sich wundert, warum Swap nicht erscheint.
Und das README hilft nur, wenn es gelesen wird
Sorry, gestern und heute war mehr „Hardware“ basteln, meine Sägetisch-/Werkbank ist etwas aufwändiger und benötigt Aufmerksamkeit. Ganz im Sinne von Albert „Planung ersetzt Zufall durch Irrtum“.
Das hoffe ich doch :), check, natürlich nicht :(.
Mit der Beta werden die Werte auch gefüllt.
Hier trotzdem die Ausgaben:
pi@symcon01:~ $ lscpu
Architecture: armv7l
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 1
Core(s) per socket: 4
Socket(s): 1
Vendor ID: ARM
Model: 4
Model name: Cortex-A53
Stepping: r0p4
CPU max MHz: 1400.0000
CPU min MHz: 700.0000
BogoMIPS: 59.73
Flags: half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
pi@symcon01:~ $ cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 4 (v7l)
BogoMIPS : 44.80
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 1
model name : ARMv7 Processor rev 4 (v7l)
BogoMIPS : 44.80
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 2
model name : ARMv7 Processor rev 4 (v7l)
BogoMIPS : 44.80
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
processor : 3
model name : ARMv7 Processor rev 4 (v7l)
BogoMIPS : 44.80
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
Hardware : BCM2835
Revision : a020d3
Serial : 00000000fc4dab46
Model : Raspberry Pi 3 Model B Plus Rev 1.3
Ich finde keinen anderen Beitrag zu dem Modul, dann also hier die Frage.
Seit 19.05.2022 habe ich immer wieder das Problem, dass der (interne) Timer vom Modul nicht aktiv ist. Wenn ich das Aktualisierungsintervall ändere und die Instanz speichere läuft es wieder, aber meist nicht lange.
Ist dazu irgendetwas bekannt? Nutzt das Modul jemand?
Leider überwache ich die Überwachung nicht, somit fällt mir der Ausfall selten auf .
.