Unfortunately the -G option doesn't do anything without the -w option.
The new image with timeout command works good.
(only took lot of effort to get an image)
Unfortunately the -G option doesn't do anything without the -w option.
The new image with timeout command works good.
(only took lot of effort to get an image)
Thanks.
I was looking for a solution that shows the APR requests/replies as I'm struggling with an issue that is only present for limited time (~15-30min).
During that time I'm not able to connect to the LE RPi3 from one pc (no ping, no ssh), but works ok from another.
Suspect my WiFi-Mesh network is causing some asymmetric behaviour after a 'mobility event'.
I compiled a new LE-9.2.8 image with the timeout command available.
Waiting for a next event...
Is it possible to add the timeout command to LE?
This would allow to script capturing of packets e.g. timeout 300 tcpdump -nnpi wlan0 arp
Timeout is part of busybox Core/Coreutils section of the config, and not selected (in 9.2 and 10.0 what I have seen).
Thanks a lot!
Installed fine and see a directory with files in /storage/.kodi/userdata/addon_data/service.persistent-journal/journal
Is it possible to extent the logging of journalctl to a day or longer?
Or make it permanent (e.g. similar to mkdir -p /var/log/journal)?
(I tried mkdir ~/.kodi/temp/journal and restart journald with systemctl restart systemd-journald.service)
found the logs in /run/log/journal/<dir>
But is covering the same as
# journalctl |head -n 1
-- Logs begin at Thu 2022-09-15 13:18:40 CEST, end at Thu 2022-09-15 18:22:02 CEST. --
Edit:
Forgot to add, I'm on LE-9.2.8 on a RPi3b
Hi,
Just an update on my findings so far.
In the last days of last year I started to use Plex live TV & PVR i.s.o. TVHeadend (mainly for a daily recording of new and weather).
In the graph you can see that the constant increase of memory usages moved from Kodi to Plex Media Server...
I also found a memory release issue with SABnzb-2, not releasing its memory.
In a week or so I hope to move to a x86_64 system.
Don't think there will be a solution for this issue.
Do you have an older version of SABnzb that I can try?
In my script I also capture the content of /tmp with df -hT | grep 'Filesystem\|tmpfs' >> $dumpfile.
Verified the value for /tmp, and this is 0% used for the last event.
In my config, the download folders, and in special 'wait_for_dfolder' is selected, and I have one server configured.
Don't think something else non-default is selected.
I do have hd-idle running with the following parameters hd-idle -i 120 -l /storage/.kodi/temp/hd-idle.log
The hd-idle logging indicates the disk was spinning-down a number of times during the download period.
Download period (incl. post processing) 2020-12-31 01:45:46 to 2020-12-31 04:03:09.
below the logs (with 2 spin-up events before start, and after DL).
Based on the 'stopped' period, I think I better increase the period before spinning-down to 300 seconds (i.s.o. 120 seconds now).
date: 2020-12-30, time: 13:43:03, disk: sda, running: 121, stopped: 145
date: 2020-12-31, time: 00:31:45, disk: sda, running: 10633, stopped: 28289
date: 2020-12-31, time: 01:30:47, disk: sda, running: 2473, stopped: 1069
date: 2020-12-31, time: 01:46:01, disk: sda, running: 121, stopped: 793
date: 2020-12-31, time: 01:51:27, disk: sda, running: 289, stopped: 37
date: 2020-12-31, time: 01:57:05, disk: sda, running: 205, stopped: 133
date: 2020-12-31, time: 02:02:42, disk: sda, running: 289, stopped: 48
date: 2020-12-31, time: 02:08:20, disk: sda, running: 169, stopped: 169
date: 2020-12-31, time: 02:13:58, disk: sda, running: 181, stopped: 157
date: 2020-12-31, time: 02:19:12, disk: sda, running: 193, stopped: 121
date: 2020-12-31, time: 02:37:37, disk: sda, running: 985, stopped: 120
date: 2020-12-31, time: 03:12:15, disk: sda, running: 1910, stopped: 168
date: 2020-12-31, time: 03:17:53, disk: sda, running: 181, stopped: 157
date: 2020-12-31, time: 03:23:31, disk: sda, running: 181, stopped: 157
date: 2020-12-31, time: 03:29:09, disk: sda, running: 193, stopped: 145
date: 2020-12-31, time: 03:34:46, disk: sda, running: 181, stopped: 156
date: 2020-12-31, time: 03:40:24, disk: sda, running: 181, stopped: 157
date: 2020-12-31, time: 03:43:50, disk: sda, running: 181, stopped: 25
date: 2020-12-31, time: 14:50:34, disk: sda, running: 1309, stopped: 38695
date: 2020-12-31, time: 20:20:26, disk: sda, running: 121, stopped: 19671
Display More
Edit test with hd-idle set to 300 seconds idle time.
Still same behaviour:
With a idle time of 300 s the hd isn't spinning-down/up during the download/post-processing.
DL was from 19:11:34 to 20:15:07
hd-idle.log:
The download goes to a USB connected device:
Temporary Download Folder:
/var/media/sda1-usb-ST1000VN_000-1HJ/downloads//incomplete
Completed Download Folder:
/var/media/sda1-usb-ST1000VN_000-1HJ/downloads/
A 'systemctl restart service.sabnzbd.service' corrects the issue.
I only recently started monitoring memory usage, and observed the same issue with all 3 downloads I started.
I'm using SABnzb 2.3.9 from the Thoradia add-ons on LibreELEC 9.2.6 on a RPi3b.
This works very well except that it appears that SABnzb doesn't release its memory after download/par processing/unpacking.
I'm monitoring memory usage for a high amount of Kodi crashes (still an issue), and now also see that SABnzb doesn't release its memory after use.
The graphs below are made from the output of 'top' sorted by memory usage collected every 30 minutes.
Graph of first occurrence:
(what you see it total memory usage in % in blue, Kodi in orange, Python in grey, and TVH in yellow. Added with some additional time events including the actual download period of SABnzb. And time goes from right t=0 to left. Just look at the most left part for the grey line.)
Graph of second occurrence:
(In above graph again total memory usage in % in blue, Kodi in purple/orange, Python in grey, and TVH in yellow. Added with some additional time events including the actual download period of SABnzb. Look at the grey line which doesn't go down after the download/processing finished.)
Just wonder of other have observed the same...
Happy NewYear All.
There was a new crash of kodi (on 14-Dec at 21:54:14).
This time I 'saw' it happen.
dmesg has more messages than with previous crashes starting with
[Mon Dec 14 21:51:54 CET 2020] rcu: INFO: rcu_sched self-detected stall on CPU
Memory utilization (system, kodi, python and tvheadend):
The daily and weelkly MRTG graphs:
Yes, indeed. Even with 3% memory usages increase each day it should run for a week or 2, before it is getting into problems.
And I might have found a reason for the crashes.
Planning to leave Plex Media Server (PMS) stopped for ~ a week or so longer to see if the frequent crashes stopped.
On the Plex Media Server (PMS) forum, for ARM, I found the following note "There are some unresolved memory issues with the DLNA server support (at least on ARM). Disabling DLNA is currently recommended."
In the PMS logs for the 4 crashes I checked I do see "DEBUG - NetworkServiceBrowser: Parsing SSDP schema for xxx" reasonably close to when the crashes happen (in the minute before or minute after a crash. I have not yet started PMS to verify the setting, but likely it is enabled (as ~ indicated by the log messages).
Also with PMS stopped there was a memory usages increase of 3%/day for 2 days, and it nearly flattened for the last 2 days.
Lets see in a few days.
Edit 2020-Dec-11, Dec-13:
I have not observed a crash after stopping Plex Media Server.
Now thinking to start PMS again this weekend. Will leave it as it is for some time.
There is still an increase of about (average) 1.5% a day over the last (nearly) 7 days.
Compared the Used Memory (calculated from details obtained from 'free -k') and memory used by kodi.bin, python, tvheadend (obtained from the memory column of 'top') every 30min (after stopping PMS).
For the crash on 1-Dec 22:15 yes, see below. For the crash on 2-Dec 7:42 I forgot to obtain the log file via SMB.
(at the time I took the logs one of my tuners was continuously generating errors in dmesg that took my attention. A power-cycle of the tuner solved that)
Dec 01 22:09:41 LibreELEC connmand[314]: ntp: adjust (slew): +0.000045 sec
Dec 01 22:14:51 LibreELEC kodi.sh[613]: terminate called after throwing an instance of 'std::length_error'
Dec 01 22:14:51 LibreELEC kodi.sh[613]: what(): basic_string::_S_create
Dec 01 22:14:55 LibreELEC tvheadend[276]: htsp: 127.0.0.1 [ admin | Kodi Media Center ]: Disconnected
Dec 01 22:14:55 LibreELEC kernel: vchiq: 0: ignoring ERROR from callback to service 5004
Dec 01 22:15:00 LibreELEC kodi.sh[613]: Aborted (core dumped)
Dec 01 22:15:10 LibreELEC kodi.sh[613]: Crash report available at /storage/.kodi/temp/kodi_crashlog_20201201221502.log
I have not seen a OOM error so far.
Yesterday I stopped the Plex server (systemctl stop plex.service) to see if that makes a difference.
(Before I had MRTG running I did that, but still had a crash.)
MRTG with the new 'Available Memory' OID is now running a number of days.
The below graph shows the weekly graph of the Used memory in percentage.
There is constantly an increase of memory usage, but I was not able to identify a process (top -b -o +%MEM | head -n 20) that could be responsible for this increase.
Graph details:
- MRTG started last Sunday evening.
- The RPi3 was running mostly idle for two days. During this period memory usage increased about 3 percent per day.
- Kodi crashed on Tuesday (1-Dec-2020) evening at 2215. This decreased memory usage with about 6 to 7 percent. After this memory usage is flat for a long time.
- Wednesday evening I played a bit with the Plex server and started a scan of my library which was still busy when I went to sleep.
- Thursday morning at 7:42am there was another Kodi crash.
- On Thursday at about 11am started a download that lasted till about 5pm
- After the download memory increased about 8 percent a day.
- At 2pm memory usage decreased with about 6 percent, but have not seen a reason (see spoiler for details).
- 13:59:33 up 6 days, 11:42, 1 user, load average: 0.03, 0.08, 0.10
Tasks: 117 total, 1 running, 116 sleeping, 0 stopped, 0 zombie
%Cpu(s): 2.9 us, 2.9 sy, 1.4 ni, 92.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 747.9 total, 48.0 free, 486.5 used, 213.3 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 186.5 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
25482 root 20 0 673628 179296 21224 S 12.5 23.4 620:12.02 kodi.bin
608 root 30 10 340016 95884 1264 S 0.0 12.5 111:23.94 python
405 root 20 0 328660 54852 8544 S 0.0 7.2 41:43.79 Plex Media Serv
637 root 35 15 194612 51220 4180 S 6.2 6.7 36:04.24 Plex Script Hos
9545 root 20 0 161860 15648 2132 S 0.0 2.0 266:01.81 tvheadend
22220 root 20 0 5116 3968 3572 S 0.0 0.5 0:00.21 sshd
581 root 20 0 30396 3336 1796 S 0.0 0.4 0:16.77 smbd
916 root 20 0 125428 3128 448 S 0.0 0.4 8:26.13 Plex Tuner Serv
1924 root 20 0 7312 2696 880 S 0.0 0.4 11:24.85 snmpd
598 root 20 0 6084 2392 600 S 0.0 0.3 2:07.96 python
22424 root 20 0 6020 2128 1700 R 6.2 0.3 0:00.03 top
579 root 20 0 17560 2096 1060 S 0.0 0.3 1:39.76 nmbd
2031 root 20 0 22540 1968 1564 S 0.0 0.3 0:13.87 systemd-journal
Used memory %: 75.0576
- 14:29:34 up 6 days, 12:12, 1 user, load average: 0.38, 0.78, 0.75
Tasks: 124 total, 1 running, 123 sleeping, 0 stopped, 0 zombie
%Cpu(s): 4.3 us, 2.9 sy, 1.4 ni, 90.0 id, 1.4 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 747.9 total, 32.2 free, 441.1 used, 274.6 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 230.3 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
25482 root 20 0 673884 167368 9260 S 6.2 21.9 624:34.58 kodi.bin
608 root 30 10 340016 95884 1264 S 0.0 12.5 111:33.71 python
405 root 20 0 328660 57636 11328 S 6.2 7.5 41:50.92 Plex Media Serv
637 root 35 15 194612 48596 1556 S 0.0 6.3 36:11.31 Plex Script Hos
9545 root 20 0 162884 15980 2060 S 6.2 2.1 274:32.91 tvheadend
581 root 20 0 30396 3328 1788 S 0.0 0.4 0:16.78 smbd
916 root 20 0 125428 3128 448 S 0.0 0.4 8:27.78 Plex Tuner Serv
1924 root 20 0 7312 2684 868 S 0.0 0.4 11:27.06 snmpd
2031 root 20 0 23056 2576 2172 S 0.0 0.3 0:14.25 systemd-journal
22220 root 20 0 5116 2408 2012 S 0.0 0.3 0:00.23 sshd
598 root 20 0 6084 2392 600 S 0.0 0.3 2:08.32 python
579 root 20 0 17560 2016 980 S 0.0 0.3 1:39.95 nmbd
23006 root 20 0 6028 2008 1580 R 6.2 0.3 0:00.03 top
Used memory % 69.1941
Enabling debug with TVH didn't additional information at the time of the crash:
2020-12-02 02:18:10.225 [ DEBUG]:mpegts: 514MHz in Ziggo DVB-C Nijmegen - close PID 1FFB (8187) [20/0x7603b250]
2020-12-02 02:50:46.164 [ INFO]:epgdb: snapshot start
2020-12-02 02:50:46.695 [ INFO]:epgdb: queued to save (size 3093481)
2020-12-02 02:50:46.695 [ INFO]:epgdb: brands 0
2020-12-02 02:50:46.695 [ INFO]:epgdb: seasons 463
2020-12-02 02:50:46.695 [ INFO]:epgdb: episodes 6181
2020-12-02 02:50:46.695 [ INFO]:epgdb: broadcasts 6182
2020-12-02 02:50:46.695 [ INFO]:epgdb: save start
2020-12-02 02:50:46.952 [ INFO]:epgdb: stored (size 441369)
2020-12-02 03:50:46.010 [ INFO]:epgdb: snapshot start
2020-12-02 03:50:46.189 [ INFO]:epgdb: queued to save (size 3093481)
2020-12-02 03:50:46.189 [ INFO]:epgdb: brands 0
2020-12-02 03:50:46.189 [ INFO]:epgdb: seasons 463
2020-12-02 03:50:46.189 [ INFO]:epgdb: episodes 6181
2020-12-02 03:50:46.189 [ INFO]:epgdb: broadcasts 6182
2020-12-02 03:50:46.189 [ INFO]:epgdb: save start
2020-12-02 03:50:46.425 [ INFO]:epgdb: stored (size 441369)
2020-12-02 04:50:46.012 [ INFO]:epgdb: snapshot start
2020-12-02 04:50:46.190 [ INFO]:epgdb: queued to save (size 3093481)
2020-12-02 04:50:46.190 [ INFO]:epgdb: brands 0
2020-12-02 04:50:46.190 [ INFO]:epgdb: seasons 463
2020-12-02 04:50:46.190 [ INFO]:epgdb: episodes 6181
2020-12-02 04:50:46.190 [ INFO]:epgdb: broadcasts 6182
2020-12-02 04:50:46.190 [ INFO]:epgdb: save start
2020-12-02 04:50:46.402 [ INFO]:epgdb: stored (size 441369)
2020-12-02 05:50:46.014 [ INFO]:epgdb: snapshot start
2020-12-02 05:50:46.209 [ INFO]:epgdb: queued to save (size 3093481)
2020-12-02 05:50:46.209 [ INFO]:epgdb: brands 0
2020-12-02 05:50:46.209 [ INFO]:epgdb: seasons 463
2020-12-02 05:50:46.209 [ INFO]:epgdb: episodes 6181
2020-12-02 05:50:46.209 [ INFO]:epgdb: save start
2020-12-02 05:50:46.209 [ INFO]:epgdb: broadcasts 6182
2020-12-02 05:50:46.394 [ INFO]:epgdb: stored (size 441369)
2020-12-02 06:50:46.000 [ INFO]:epgdb: snapshot start
2020-12-02 06:50:46.211 [ INFO]:epgdb: queued to save (size 3093481)
2020-12-02 06:50:46.211 [ INFO]:epgdb: brands 0
2020-12-02 06:50:46.211 [ INFO]:epgdb: seasons 463
2020-12-02 06:50:46.211 [ INFO]:epgdb: episodes 6181
2020-12-02 06:50:46.211 [ INFO]:epgdb: save start
2020-12-02 06:50:46.212 [ INFO]:epgdb: broadcasts 6182
2020-12-02 06:50:46.380 [ INFO]:epgdb: stored (size 441369)
2020-12-02 07:42:28.506 [ INFO]:htsp: 127.0.0.1 [ admin | Kodi Media Center ]: Disconnected
2020-12-02 07:42:45.399 [ INFO]:htsp: Got connection from 127.0.0.1
2020-12-02 07:42:45.401 [ INFO]:htsp: 127.0.0.1: Welcomed client software: Kodi Media Center (HTSPv34)
Display More
Edit,
Finished setting up MRTG with the new OID.
(I kept the 'total memory - free memory' graph also.)
I did find a config issue in TVH causing recordings to fail due to higher than configured assigned directory size used after an 'on demand' recording.
But don't see a direct relation with the crashed of kodi.
(adding a graph from the last ~day, and patches used toward the end of this post)
/Edit
Yes, you found the issue! Indeed version 2c is required.
Now I need to adjust the MRTG config to make use of the new OID to display the actual used memory (memTotalRealX - memSysAvail).
Here the output all with version 2c without the additional patch (current latest official package revision 106)
$ snmpwalk -v 2c -c libreelec -m "/home/pi/.snmp/mibs/UCD-SNMP-MIB.txt" -Oaf 192.168.178.22 .1.3.6.1.4.1.2021.4
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memIndex.0 = INTEGER: 0
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memErrorName.0 = STRING: swap
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memTotalSwap.0 = INTEGER: 0 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memAvailSwap.0 = INTEGER: 0 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memTotalReal.0 = INTEGER: 765828 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memAvailReal.0 = INTEGER: 27020 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memTotalFree.0 = INTEGER: 27020 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memMinimumSwap.0 = INTEGER: 16000 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memShared.0 = INTEGER: 11936 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memBuffer.0 = INTEGER: 29256 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memCached.0 = INTEGER: 372176 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memTotalSwapX.0 = Counter64: 0 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memAvailSwapX.0 = Counter64: 0 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memTotalRealX.0 = Counter64: 765828 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memAvailRealX.0 = Counter64: 27020 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memTotalFreeX.0 = Counter64: 27020 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memMinimumSwapX.0 = Counter64: 16000 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memSharedX.0 = Counter64: 11936 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memBufferX.0 = Counter64: 29256 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memCachedX.0 = Counter64: 372176 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memSwapError.0 = INTEGER: error(1)
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memSwapErrorMsg.0 = STRING: Running out of swap space (0)
Display More
$ snmpwalk -v 2c -c libreelec -m "/home/pi/.snmp/mibs/UCD-SNMP-MIB.txt" -Oan 192.168.178.22 .1.3.6.1.4.1.2021.4
.1.3.6.1.4.1.2021.4.1.0 = INTEGER: 0
.1.3.6.1.4.1.2021.4.2.0 = STRING: swap
.1.3.6.1.4.1.2021.4.3.0 = INTEGER: 0 kB
.1.3.6.1.4.1.2021.4.4.0 = INTEGER: 0 kB
.1.3.6.1.4.1.2021.4.5.0 = INTEGER: 765828 kB
.1.3.6.1.4.1.2021.4.6.0 = INTEGER: 28020 kB
.1.3.6.1.4.1.2021.4.11.0 = INTEGER: 28020 kB
.1.3.6.1.4.1.2021.4.12.0 = INTEGER: 16000 kB
.1.3.6.1.4.1.2021.4.13.0 = INTEGER: 11936 kB
.1.3.6.1.4.1.2021.4.14.0 = INTEGER: 28572 kB
.1.3.6.1.4.1.2021.4.15.0 = INTEGER: 370064 kB
.1.3.6.1.4.1.2021.4.18.0 = Counter64: 0 kB
.1.3.6.1.4.1.2021.4.19.0 = Counter64: 0 kB
.1.3.6.1.4.1.2021.4.20.0 = Counter64: 765828 kB
.1.3.6.1.4.1.2021.4.21.0 = Counter64: 28020 kB
.1.3.6.1.4.1.2021.4.22.0 = Counter64: 28020 kB
.1.3.6.1.4.1.2021.4.23.0 = Counter64: 16000 kB
.1.3.6.1.4.1.2021.4.24.0 = Counter64: 11936 kB
.1.3.6.1.4.1.2021.4.25.0 = Counter64: 28572 kB
.1.3.6.1.4.1.2021.4.26.0 = Counter64: 370064 kB
.1.3.6.1.4.1.2021.4.100.0 = INTEGER: error(1)
.1.3.6.1.4.1.2021.4.101.0 = STRING: Running out of swap space (0)
Display More
And with the patches for memSysAvail (custom package revision 109):
$ snmpwalk -v 2c -c libreelec -m "/home/pi/.snmp/mibs/UCD-SNMP-MIB.txt" -Oaf 192.168.178.22 .1.3.6.1.4.1.2021.4
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memIndex.0 = INTEGER: 0
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memErrorName.0 = STRING: swap
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memTotalSwap.0 = INTEGER: 0 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memAvailSwap.0 = INTEGER: 0 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memTotalReal.0 = INTEGER: 765828 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memAvailReal.0 = INTEGER: 209580 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memTotalFree.0 = INTEGER: 209580 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memMinimumSwap.0 = INTEGER: 16000 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memShared.0 = INTEGER: 12712 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memBuffer.0 = INTEGER: 24188 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memCached.0 = INTEGER: 185008 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memTotalSwapX.0 = Counter64: 0 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memAvailSwapX.0 = Counter64: 0 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memTotalRealX.0 = Counter64: 765828 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memAvailRealX.0 = Counter64: 209580 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memTotalFreeX.0 = Counter64: 209580 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memMinimumSwapX.0 = Counter64: 16000 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memSharedX.0 = Counter64: 12712 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memBufferX.0 = Counter64: 24188 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memCachedX.0 = Counter64: 185008 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memSysAvail.0 = Counter64: 345716 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memSwapError.0 = INTEGER: error(1)
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memSwapErrorMsg.0 = STRING: Running out of swap space (0)
Display More
$ snmpwalk -v 2c -c libreelec -m "/home/pi/.snmp/mibs/UCD-SNMP-MIB.txt" -Oan 192.168.178.22 .1.3.6.1.4.1.2021.4
.1.3.6.1.4.1.2021.4.1.0 = INTEGER: 0
.1.3.6.1.4.1.2021.4.2.0 = STRING: swap
.1.3.6.1.4.1.2021.4.3.0 = INTEGER: 0 kB
.1.3.6.1.4.1.2021.4.4.0 = INTEGER: 0 kB
.1.3.6.1.4.1.2021.4.5.0 = INTEGER: 765828 kB
.1.3.6.1.4.1.2021.4.6.0 = INTEGER: 34300 kB
.1.3.6.1.4.1.2021.4.11.0 = INTEGER: 34300 kB
.1.3.6.1.4.1.2021.4.12.0 = INTEGER: 16000 kB
.1.3.6.1.4.1.2021.4.13.0 = INTEGER: 12712 kB
.1.3.6.1.4.1.2021.4.14.0 = INTEGER: 4672 kB
.1.3.6.1.4.1.2021.4.15.0 = INTEGER: 379288 kB
.1.3.6.1.4.1.2021.4.18.0 = Counter64: 0 kB
.1.3.6.1.4.1.2021.4.19.0 = Counter64: 0 kB
.1.3.6.1.4.1.2021.4.20.0 = Counter64: 765828 kB
.1.3.6.1.4.1.2021.4.21.0 = Counter64: 34300 kB
.1.3.6.1.4.1.2021.4.22.0 = Counter64: 34300 kB
.1.3.6.1.4.1.2021.4.23.0 = Counter64: 16000 kB
.1.3.6.1.4.1.2021.4.24.0 = Counter64: 12712 kB
.1.3.6.1.4.1.2021.4.25.0 = Counter64: 4672 kB
.1.3.6.1.4.1.2021.4.26.0 = Counter64: 379288 kB
.1.3.6.1.4.1.2021.4.27.0 = Counter64: 343228 kB
.1.3.6.1.4.1.2021.4.100.0 = INTEGER: error(1)
.1.3.6.1.4.1.2021.4.101.0 = STRING: Running out of swap space (0)
Display More
# free
total used free shared buff/cache available
Mem: 765828 347828 32876 12076 385124 344704
Swap: 0 0 0
Edit
Here a graph including 'Used Memory' obtained by substracting the new 'memSysAvail' OID from the total memory.
And the patches used for 5.9 are in '5.9 patches.zip'.
Changes to 'packages/addons/service/net-snmp/package.mk':
sed -i 's/PKG_VERSION="5.8"/PKG_VERSION="5.9"/g' ~/LibreELEC.tv/packages/addons/service/net-snmp/package.mk
sed -i 's/PKG_SHA256="b2fc.*"/PKG_SHA256="04303a66f85d6d8b16d3cc53bde50428877c82ab524e17591dfceaeb94df6071"/g' ~/LibreELEC.tv/packages/addons/service/net-snmp/package.mk
sed -i 's/PKG_REV="106"/PKG_REV="107"/g' ~/LibreELEC.tv/packages/addons/service/net-snmp/package.mk
/Edit
Yes I created a new .zip file with all the add-on files.
I re-created the patches, now they get applied without issues.
CLEAN net-snmp
UNPACK net-snmp
APPLY PATCH (common) packages/addons/service/net-snmp/patches/net-snmp-0001-read_config.c.patch
patching file snmplib/read_config.c
APPLY PATCH (common) packages/addons/service/net-snmp/patches/net-snmp-0002-net-snmp-create-v3-user.in.patch
patching file net-snmp-create-v3-user.in
APPLY PATCH (common) packages/addons/service/net-snmp/patches/net-snmp-0003-config.sub.patch
patching file config.sub
APPLY PATCH (common) packages/addons/service/net-snmp/patches/net-snmp-0004-memavailable.patch
patching file agent/mibgroup/hardware/memory/memory_linux.c
patching file agent/mibgroup/ucd-snmp/memory.c
patching file agent/mibgroup/ucd-snmp/memory.h
patching file include/net-snmp/agent/hardware/memory.h
patching file mibs/UCD-SNMP-MIB.txt
FIXCONFIG /home/rhermsen/LibreELEC.tv/build.LibreELEC-RPi2.arm-9.2-devel/net-snmp-5.9/
BUILD net-snmp (target)
Display More
I added again the additional failure logging mentioned here. I don't see error messages if I run the following:
./snmpd -f -Lf /storage/.kodi/temp/snmpd.log -C -c /storage/.kodi/userdata/addon_data/service.net-snmp/share/snmp/snmpd.conf -M /storage/.kodi/addons/service.net-snmp/share/snmp/mibs -p /var/run/snmpd.pid -V
or
./snmpd -f -Leo -C -c /storage/.kodi/userdata/addon_data/service.net-snmp/share/snmp/snmpd.conf -M /storage/.kodi/addons/service.net-snmp/share/snmp/mibs -p /var/run/snmpd.pid -V
(not any error message...)
The logging I get (due to the -V option):
Received SNMP packet(s) from UDP: [192.168.178.59]:58582->[192.168.178.22]:161
GETNEXT message
-- UCD-SNMP-MIB::memory
Received SNMP packet(s) from UDP: [192.168.178.59]:58582->[192.168.178.22]:161
GETNEXT message
-- UCD-SNMP-MIB::memIndex.0
Received SNMP packet(s) from UDP: [192.168.178.59]:58582->[192.168.178.22]:161
GETNEXT message
-- UCD-SNMP-MIB::memErrorName.0
Received SNMP packet(s) from UDP: [192.168.178.59]:58582->[192.168.178.22]:161
GETNEXT message
-- UCD-SNMP-MIB::memTotalSwap.0
Received SNMP packet(s) from UDP: [192.168.178.59]:58582->[192.168.178.22]:161
GETNEXT message
-- UCD-SNMP-MIB::memAvailSwap.0
Received SNMP packet(s) from UDP: [192.168.178.59]:58582->[192.168.178.22]:161
GETNEXT message
-- UCD-SNMP-MIB::memTotalReal.0
Received SNMP packet(s) from UDP: [192.168.178.59]:58582->[192.168.178.22]:161
GETNEXT message
-- UCD-SNMP-MIB::memAvailReal.0
Received SNMP packet(s) from UDP: [192.168.178.59]:58582->[192.168.178.22]:161
GETNEXT message
-- UCD-SNMP-MIB::memTotalFree.0
Received SNMP packet(s) from UDP: [192.168.178.59]:58582->[192.168.178.22]:161
GETNEXT message
-- UCD-SNMP-MIB::memMinimumSwap.0
Received SNMP packet(s) from UDP: [192.168.178.59]:58582->[192.168.178.22]:161
GETNEXT message
-- UCD-SNMP-MIB::memShared.0
Received SNMP packet(s) from UDP: [192.168.178.59]:58582->[192.168.178.22]:161
GETNEXT message
-- UCD-SNMP-MIB::memBuffer.0
Received SNMP packet(s) from UDP: [192.168.178.59]:58582->[192.168.178.22]:161
GETNEXT message
-- UCD-SNMP-MIB::memCached.0
Received SNMP packet(s) from UDP: [192.168.178.59]:58582->[192.168.178.22]:161
GETNEXT message
-- UCD-SNMP-MIB::memSwapError.0
Received SNMP packet(s) from UDP: [192.168.178.59]:58582->[192.168.178.22]:161
GETNEXT message
-- UCD-SNMP-MIB::memSwapErrorMsg.0
Display More
I created a patch file and compiled net-snmp again but don't see a change in behavior.
cd ~/LibreELEC.tv/build.LibreELEC-RPi2.arm-9.2-devel/.stamps
rm -r net-snmp
cd ~/LibreELEC.tv/packages/addons/service/net-snmp/patches
vi net-snmp-0004-memavailable.patch
cp ~/LibreELEC.tv/packages/addons/service/net-snmp/package.mk ~/LibreELEC.tv/packages/addons/service/net-snmp/package.mk.orig
sed -i 's/PKG_VERSION="5.8"/PKG_VERSION="5.9"/g' ~/LibreELEC.tv/packages/addons/service/net-snmp/package.mk
sed -i 's/PKG_SHA256="b2fc.*"/PKG_SHA256="04303a66f85d6d8b16d3cc53bde50428877c82ab524e17591dfceaeb94df6071"/g' ~/LibreELEC.tv/packages/addons/service/net-snmp/package.mk
sed -i 's/PKG_REV="106"/PKG_REV="107"/g' ~/LibreELEC.tv/packages/addons/service/net-snmp/package.mk
cd ~/LibreELEC.tv/
PROJECT=RPi ARCH=arm DEVICE=RPi2 scripts/create_addon net-snmp
CLEAN net-snmp
* Removing /home/<user>/LibreELEC.tv/build.LibreELEC-RPi2.arm-9.2-devel/net-snmp-5.9 ...
UNPACK net-snmp
APPLY PATCH (common) packages/addons/service/net-snmp/patches/net-snmp-0001-read_config.c.patch
patching file snmplib/read_config.c
Hunk #1 succeeded at 1642 (offset 24 lines).
APPLY PATCH (common) packages/addons/service/net-snmp/patches/net-snmp-0002-net-snmp-create-v3-user.in.patch
patching file net-snmp-create-v3-user.in
Hunk #1 succeeded at 5 with fuzz 2 (offset -23 lines).
APPLY PATCH (common) packages/addons/service/net-snmp/patches/net-snmp-0003-config.sub.patch
(Stripping trailing CRs from patch; use --binary to disable.)
patching file config.sub
patch unexpectedly ends in middle of line
Hunk #3 succeeded at 1173 with fuzz 1.
APPLY PATCH (common) packages/addons/service/net-snmp/patches/net-snmp-0004-memavailable.patch
patching file agent/mibgroup/hardware/memory/memory_linux.c
patching file agent/mibgroup/ucd-snmp/memory.c
patching file agent/mibgroup/ucd-snmp/memory.h
patching file include/net-snmp/agent/hardware/memory.h
patching file mibs/UCD-SNMP-MIB.txt
Display More
$ snmpwalk -v 1 -c libreelec -m "/home/pi/.snmp/mibs/UCD-SNMP-MIB.txt" -Oaf 192.168.178.22 .1.3.6.1.4.1.2021.4
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memIndex.0 = INTEGER: 0
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memErrorName.0 = STRING: swap
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memTotalSwap.0 = INTEGER: 0 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memAvailSwap.0 = INTEGER: 0 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memTotalReal.0 = INTEGER: 765828 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memAvailReal.0 = INTEGER: 33872 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memTotalFree.0 = INTEGER: 33872 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memMinimumSwap.0 = INTEGER: 16000 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memShared.0 = INTEGER: 12620 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memBuffer.0 = INTEGER: 42468 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memCached.0 = INTEGER: 385780 kB
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memSwapError.0 = INTEGER: error(1)
.iso.org.dod.internet.private.enterprises.ucdavis.memory.memSwapErrorMsg.0 = STRING: Running out of swap space (0)
Display More
$ snmpwalk -v 1 -c libreelec -m "/home/pi/.snmp/mibs/UCD-SNMP-MIB.txt" -Oan 192.168.178.22 .1.3.6.1.4.1.2021.4
.1.3.6.1.4.1.2021.4.1.0 = INTEGER: 0
.1.3.6.1.4.1.2021.4.2.0 = STRING: swap
.1.3.6.1.4.1.2021.4.3.0 = INTEGER: 0 kB
.1.3.6.1.4.1.2021.4.4.0 = INTEGER: 0 kB
.1.3.6.1.4.1.2021.4.5.0 = INTEGER: 765828 kB
.1.3.6.1.4.1.2021.4.6.0 = INTEGER: 33304 kB
.1.3.6.1.4.1.2021.4.11.0 = INTEGER: 33304 kB
.1.3.6.1.4.1.2021.4.12.0 = INTEGER: 16000 kB
.1.3.6.1.4.1.2021.4.13.0 = INTEGER: 12620 kB
.1.3.6.1.4.1.2021.4.14.0 = INTEGER: 42476 kB
.1.3.6.1.4.1.2021.4.15.0 = INTEGER: 385812 kB
.1.3.6.1.4.1.2021.4.100.0 = INTEGER: error(1)
.1.3.6.1.4.1.2021.4.101.0 = STRING: Running out of swap space (0)
Display More