Hallo Leute,
sobald der hoodselector einmal nicht terminiert hat, kann er nicht wieder ausgeführt werden, weil er seine eigene pid-file (/var/run/hoodselector.pid) nicht gelöscht hat. Folgender Einzeiler löscht diese Datei, falls sie älter als 300 sekunden = (5 minuten) ist.
if [ $(($(date +%s) - $(date +%s -r "/var/run/hoodselector.pid"))) -gt 300 ];then rm /var/run/hoodselector.pid;fi
könnte das vielleicht als watchdog/cronjob in die nächste firmware mit rein? wäre schon sehr praktisch.
PS. ich teste das jetzt mal auf paar routern
LG lrnzo
so teste ich das jetzt mal:
# cat /usr/lib/micron.d/hoodselector */2 * * * * if [ $(($(date +%s) - $(date +%s -r "/var/run/hoodselector.pid"))) -gt 120 ];then rm /var/run/hoodselector.pid;fi; /usr/sbin/hoodselector 2>> /tmp/hoodselector_error
Am 07.07.2017 um 11:02 schrieb lrnzo via Dev:
Hallo Leute,
sobald der hoodselector einmal nicht terminiert hat, kann er nicht wieder ausgeführt werden, weil er seine eigene pid-file (/var/run/hoodselector.pid) nicht gelöscht hat. Folgender Einzeiler löscht diese Datei, falls sie älter als 300 sekunden = (5 minuten) ist.
if [ $(($(date +%s) - $(date +%s -r "/var/run/hoodselector.pid"))) -gt 300 ];then rm /var/run/hoodselector.pid;fi
könnte das vielleicht als watchdog/cronjob in die nächste firmware mit rein? wäre schon sehr praktisch.
PS. ich teste das jetzt mal auf paar routern
LG lrnzo
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
so, das läuft jetzt so in ganz bad-iburg
Am 07.07.2017 um 11:15 schrieb lrnzo via Dev:
so teste ich das jetzt mal:
# cat /usr/lib/micron.d/hoodselector */2 * * * * if [ $(($(date +%s) - $(date +%s -r "/var/run/hoodselector.pid"))) -gt 120 ];then rm /var/run/hoodselector.pid;fi; /usr/sbin/hoodselector 2>> /tmp/hoodselector_error
Am 07.07.2017 um 11:02 schrieb lrnzo via Dev:
Hallo Leute,
sobald der hoodselector einmal nicht terminiert hat, kann er nicht wieder ausgeführt werden, weil er seine eigene pid-file (/var/run/hoodselector.pid) nicht gelöscht hat. Folgender Einzeiler löscht diese Datei, falls sie älter als 300 sekunden = (5 minuten) ist.
if [ $(($(date +%s) - $(date +%s -r "/var/run/hoodselector.pid"))) -gt 300 ];then rm /var/run/hoodselector.pid;fi
könnte das vielleicht als watchdog/cronjob in die nächste firmware mit rein? wäre schon sehr praktisch.
PS. ich teste das jetzt mal auf paar routern
LG lrnzo
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi,
Am 07.07.2017 um 11:15 schrieb lrnzo via Dev:
so teste ich das jetzt mal:
# cat /usr/lib/micron.d/hoodselector */2 * * * * if [ $(($(date +%s) - $(date +%s -r "/var/run/hoodselector.pid"))) -gt 120 ];then rm /var/run/hoodselector.pid;fi; /usr/sbin/hoodselector 2>> /tmp/hoodselector_error
Am 07.07.2017 um 11:02 schrieb lrnzo via Dev:
Hallo Leute,
sobald der hoodselector einmal nicht terminiert hat, kann er nicht wieder ausgeführt werden, weil er seine eigene pid-file (/var/run/hoodselector.pid) nicht gelöscht hat. Folgender Einzeiler löscht diese Datei, falls sie älter als 300 sekunden = (5 minuten) ist.
if [ $(($(date +%s) - $(date +%s -r "/var/run/hoodselector.pid"))) -gt 300 ];then rm /var/run/hoodselector.pid;fi
könnte das vielleicht als watchdog/cronjob in die nächste firmware mit rein? wäre schon sehr praktisch.
PS. ich teste das jetzt mal auf paar routern
Ist es bei dir öfter vorgekommen das dieser hängen bleibt ?
Falls du so einen zustand hast. Magst du den Output von /tmp/hoodselector_error hier einmal Posten.
Ein einrichten des o.g. zeitweisen Löschens der pid ist nicht so eine optimale Lösung. Ein hängen bleiben des hoodselectors sollte nicht passieren. Daher würde ich vor so einem schritt gerne erst mal vorschlagen das wir den Problem Auslöser versuchen zu finden.
vg Tarek
Moin
Ich finde das gut.
Es stellt ja sicher, dass der Hoodselector nach einem Fehlschlag nach einer gewissen Zeit wieder läuft.
So einen Zustand zu finden ist sicherlich nicht einfach, es geht ja hier nur darum wenn das passiert das dann das pid file gelöscht wird und der hoodselector noch einmal von vorne anfängt. Und nicht für immer im Nirvana hängt.
So ein Fehlerfall kann ja verschiedenste Gründe haben und damit würden wir ja unser System haben was Fehler erkennt -> error log aber sich dann nicht festfrisst
Von mir ganz klar +1
Gruß
Johannes
Von meinem iPhone gesendet
Am 07.07.2017 um 13:56 schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
Hi,
Am 07.07.2017 um 11:15 schrieb lrnzo via Dev: so teste ich das jetzt mal:
# cat /usr/lib/micron.d/hoodselector */2 * * * * if [ $(($(date +%s) - $(date +%s -r "/var/run/hoodselector.pid"))) -gt 120 ];then rm /var/run/hoodselector.pid;fi; /usr/sbin/hoodselector 2>> /tmp/hoodselector_error
Am 07.07.2017 um 11:02 schrieb lrnzo via Dev: Hallo Leute,
sobald der hoodselector einmal nicht terminiert hat, kann er nicht wieder ausgeführt werden, weil er seine eigene pid-file (/var/run/hoodselector.pid) nicht gelöscht hat. Folgender Einzeiler löscht diese Datei, falls sie älter als 300 sekunden = (5 minuten) ist.
if [ $(($(date +%s) - $(date +%s -r "/var/run/hoodselector.pid"))) -gt 300 ];then rm /var/run/hoodselector.pid;fi
könnte das vielleicht als watchdog/cronjob in die nächste firmware mit rein? wäre schon sehr praktisch.
PS. ich teste das jetzt mal auf paar routern
Ist es bei dir öfter vorgekommen das dieser hängen bleibt ?
Falls du so einen zustand hast. Magst du den Output von /tmp/hoodselector_error hier einmal Posten.
Ein einrichten des o.g. zeitweisen Löschens der pid ist nicht so eine optimale Lösung. Ein hängen bleiben des hoodselectors sollte nicht passieren. Daher würde ich vor so einem schritt gerne erst mal vorschlagen das wir den Problem Auslöser versuchen zu finden.
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Ok, erstmal danke für das feedback. Ich habe jetzt gemacht, dass meine testrouter mir im Falle des festgefahrenen hoodselectors eine mail mit dem jüngsten error-log im Anhang schicken können.
opkg update opkg install mailsend-nossl
und in der /usr/lib/micron.d/hoodselector steht jetzt:
*/2 * * * * if [ $(($(date +%s) - $(date +%s -r "/var/run/hoodselector.pid"))) -gt 120 ];then mailsend -f alert@ffnw.de -t alert@ffnw.de -smtp mail.ffnw.de -sub "$(uci get system.@system[0].hostname)" -msg-body /tmp/hoodselector_error;rm /var/run/hoodselector.pid;fi; /usr/sbin/hoodselector 2>> /tmp/hoodselector_error
dann warten wir mal ab.
LG lorenz
Am 07.07.2017 um 14:20 schrieb Johannes Rudolph via Dev:
Moin
Ich finde das gut.
Es stellt ja sicher, dass der Hoodselector nach einem Fehlschlag nach einer gewissen Zeit wieder läuft.
So einen Zustand zu finden ist sicherlich nicht einfach, es geht ja hier nur darum wenn das passiert das dann das pid file gelöscht wird und der hoodselector noch einmal von vorne anfängt. Und nicht für immer im Nirvana hängt.
So ein Fehlerfall kann ja verschiedenste Gründe haben und damit würden wir ja unser System haben was Fehler erkennt -> error log aber sich dann nicht festfrisst
Von mir ganz klar +1
Gruß
Johannes
Von meinem iPhone gesendet
Am 07.07.2017 um 13:56 schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
Hi,
Am 07.07.2017 um 11:15 schrieb lrnzo via Dev: so teste ich das jetzt mal:
# cat /usr/lib/micron.d/hoodselector */2 * * * * if [ $(($(date +%s) - $(date +%s -r "/var/run/hoodselector.pid"))) -gt 120 ];then rm /var/run/hoodselector.pid;fi; /usr/sbin/hoodselector 2>> /tmp/hoodselector_error
Am 07.07.2017 um 11:02 schrieb lrnzo via Dev: Hallo Leute,
sobald der hoodselector einmal nicht terminiert hat, kann er nicht wieder ausgeführt werden, weil er seine eigene pid-file (/var/run/hoodselector.pid) nicht gelöscht hat. Folgender Einzeiler löscht diese Datei, falls sie älter als 300 sekunden = (5 minuten) ist.
if [ $(($(date +%s) - $(date +%s -r "/var/run/hoodselector.pid"))) -gt 300 ];then rm /var/run/hoodselector.pid;fi
könnte das vielleicht als watchdog/cronjob in die nächste firmware mit rein? wäre schon sehr praktisch.
PS. ich teste das jetzt mal auf paar routern
Ist es bei dir öfter vorgekommen das dieser hängen bleibt ?
Falls du so einen zustand hast. Magst du den Output von /tmp/hoodselector_error hier einmal Posten.
Ein einrichten des o.g. zeitweisen Löschens der pid ist nicht so eine optimale Lösung. Ein hängen bleiben des hoodselectors sollte nicht passieren. Daher würde ich vor so einem schritt gerne erst mal vorschlagen das wir den Problem Auslöser versuchen zu finden.
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
so wie ich das vorgeschlagen hatte funktioniert es nicht, da anscheinend der micrond in seiner shell (?) die if-Anweisung nicht ausführen kann. Was aber funktioniert ist, wenn man den watchdog in ein script auslagert, beispielsweise /tmp/hoodselector-watchdog.sh
---------------------------8<--------------------------- #!/bin/sh if [ $(($(date +%s) - $(date +%s -r "/var/run/hoodselector.pid"))) -gt 120 ]; then mailsend -f alert@ffnw.de -t alert@ffnw.de -smtp mail.ffnw.de -sub "$(uci get system.@system[0].hostname)" -msg-body /tmp/hoodselector_error rm /var/run/hoodselector.pid fi --------------------------->8---------------------------
(nicht vergessen: chmod +x tmp/hoodselector-watchdog.sh) und die /usr/lib/micron.d/hoodselector entsprechend modifiziert:
*/2 * * * * /tmp/hoodselector-watchdog.sh;/usr/sbin/hoodselector 2>> /tmp/hoodselector_error
das mit dem Mailversand an alert@ffnw.de klappt zwar, allerdings werden alle mails mit "*** SPAM ***" geflagt. lässt sich das noch irgendwie abstellen?
LG lorenz
Am 07.07.2017 um 17:03 schrieb lrnzo via Dev:
Ok, erstmal danke für das feedback. Ich habe jetzt gemacht, dass meine testrouter mir im Falle des festgefahrenen hoodselectors eine mail mit dem jüngsten error-log im Anhang schicken können.
opkg update opkg install mailsend-nossl
und in der /usr/lib/micron.d/hoodselector steht jetzt:
*/2 * * * * if [ $(($(date +%s) - $(date +%s -r "/var/run/hoodselector.pid"))) -gt 120 ];then mailsend -f alert@ffnw.de -t alert@ffnw.de -smtp mail.ffnw.de -sub "$(uci get system.@system[0].hostname)" -msg-body /tmp/hoodselector_error;rm /var/run/hoodselector.pid;fi; /usr/sbin/hoodselector 2>> /tmp/hoodselector_error
dann warten wir mal ab.
LG lorenz
Am 07.07.2017 um 14:20 schrieb Johannes Rudolph via Dev:
Moin
Ich finde das gut.
Es stellt ja sicher, dass der Hoodselector nach einem Fehlschlag nach einer gewissen Zeit wieder läuft.
So einen Zustand zu finden ist sicherlich nicht einfach, es geht ja hier nur darum wenn das passiert das dann das pid file gelöscht wird und der hoodselector noch einmal von vorne anfängt. Und nicht für immer im Nirvana hängt.
So ein Fehlerfall kann ja verschiedenste Gründe haben und damit würden wir ja unser System haben was Fehler erkennt -> error log aber sich dann nicht festfrisst
Von mir ganz klar +1
Gruß
Johannes
Von meinem iPhone gesendet
Am 07.07.2017 um 13:56 schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
Hi,
Am 07.07.2017 um 11:15 schrieb lrnzo via Dev: so teste ich das jetzt mal:
# cat /usr/lib/micron.d/hoodselector */2 * * * * if [ $(($(date +%s) - $(date +%s -r "/var/run/hoodselector.pid"))) -gt 120 ];then rm /var/run/hoodselector.pid;fi; /usr/sbin/hoodselector 2>> /tmp/hoodselector_error
Am 07.07.2017 um 11:02 schrieb lrnzo via Dev: Hallo Leute,
sobald der hoodselector einmal nicht terminiert hat, kann er nicht wieder ausgeführt werden, weil er seine eigene pid-file (/var/run/hoodselector.pid) nicht gelöscht hat. Folgender Einzeiler löscht diese Datei, falls sie älter als 300 sekunden = (5 minuten) ist.
if [ $(($(date +%s) - $(date +%s -r "/var/run/hoodselector.pid"))) -gt 300 ];then rm /var/run/hoodselector.pid;fi
könnte das vielleicht als watchdog/cronjob in die nächste firmware mit rein? wäre schon sehr praktisch.
PS. ich teste das jetzt mal auf paar routern
Ist es bei dir öfter vorgekommen das dieser hängen bleibt ?
Falls du so einen zustand hast. Magst du den Output von /tmp/hoodselector_error hier einmal Posten.
Ein einrichten des o.g. zeitweisen Löschens der pid ist nicht so eine optimale Lösung. Ein hängen bleiben des hoodselectors sollte nicht passieren. Daher würde ich vor so einem schritt gerne erst mal vorschlagen das wir den Problem Auslöser versuchen zu finden.
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
da sollte natürlich 300 statt 120 stehen
Am 18.08.2017 um 08:01 schrieb lrnzo via Dev:
so wie ich das vorgeschlagen hatte funktioniert es nicht, da anscheinend der micrond in seiner shell (?) die if-Anweisung nicht ausführen kann. Was aber funktioniert ist, wenn man den watchdog in ein script auslagert, beispielsweise /tmp/hoodselector-watchdog.sh
---------------------------8<--------------------------- #!/bin/sh if [ $(($(date +%s) - $(date +%s -r "/var/run/hoodselector.pid"))) -gt 120 ]; then mailsend -f alert@ffnw.de -t alert@ffnw.de -smtp mail.ffnw.de -sub "$(uci get system.@system[0].hostname)" -msg-body /tmp/hoodselector_error rm /var/run/hoodselector.pid fi --------------------------->8---------------------------
(nicht vergessen: chmod +x tmp/hoodselector-watchdog.sh) und die /usr/lib/micron.d/hoodselector entsprechend modifiziert:
*/2 * * * * /tmp/hoodselector-watchdog.sh;/usr/sbin/hoodselector 2>> /tmp/hoodselector_error
das mit dem Mailversand an alert@ffnw.de klappt zwar, allerdings werden alle mails mit "*** SPAM ***" geflagt. lässt sich das noch irgendwie abstellen?
LG lorenz
Am 07.07.2017 um 17:03 schrieb lrnzo via Dev:
Ok, erstmal danke für das feedback. Ich habe jetzt gemacht, dass meine testrouter mir im Falle des festgefahrenen hoodselectors eine mail mit dem jüngsten error-log im Anhang schicken können.
opkg update opkg install mailsend-nossl
und in der /usr/lib/micron.d/hoodselector steht jetzt:
*/2 * * * * if [ $(($(date +%s) - $(date +%s -r "/var/run/hoodselector.pid"))) -gt 120 ];then mailsend -f alert@ffnw.de -t alert@ffnw.de -smtp mail.ffnw.de -sub "$(uci get system.@system[0].hostname)" -msg-body /tmp/hoodselector_error;rm /var/run/hoodselector.pid;fi; /usr/sbin/hoodselector 2>> /tmp/hoodselector_error
dann warten wir mal ab.
LG lorenz
Am 07.07.2017 um 14:20 schrieb Johannes Rudolph via Dev:
Moin
Ich finde das gut.
Es stellt ja sicher, dass der Hoodselector nach einem Fehlschlag nach einer gewissen Zeit wieder läuft.
So einen Zustand zu finden ist sicherlich nicht einfach, es geht ja hier nur darum wenn das passiert das dann das pid file gelöscht wird und der hoodselector noch einmal von vorne anfängt. Und nicht für immer im Nirvana hängt.
So ein Fehlerfall kann ja verschiedenste Gründe haben und damit würden wir ja unser System haben was Fehler erkennt -> error log aber sich dann nicht festfrisst
Von mir ganz klar +1
Gruß
Johannes
Von meinem iPhone gesendet
Am 07.07.2017 um 13:56 schrieb Jan-Tarek Butt via Dev dev@lists.ffnw.de:
Hi,
Am 07.07.2017 um 11:15 schrieb lrnzo via Dev: so teste ich das jetzt mal:
# cat /usr/lib/micron.d/hoodselector */2 * * * * if [ $(($(date +%s) - $(date +%s -r "/var/run/hoodselector.pid"))) -gt 120 ];then rm /var/run/hoodselector.pid;fi; /usr/sbin/hoodselector 2>> /tmp/hoodselector_error
> Am 07.07.2017 um 11:02 schrieb lrnzo via Dev: > Hallo Leute, > > sobald der hoodselector einmal nicht terminiert hat, kann er nicht wieder ausgeführt werden, weil er seine eigene pid-file (/var/run/hoodselector.pid) nicht gelöscht hat. Folgender Einzeiler löscht diese Datei, falls sie älter als 300 sekunden = (5 minuten) ist. > > if [ $(($(date +%s) - $(date +%s -r "/var/run/hoodselector.pid"))) -gt 300 ];then rm /var/run/hoodselector.pid;fi > > könnte das vielleicht als watchdog/cronjob in die nächste firmware mit rein? wäre schon sehr praktisch. > > PS. ich teste das jetzt mal auf paar routern >
Ist es bei dir öfter vorgekommen das dieser hängen bleibt ?
Falls du so einen zustand hast. Magst du den Output von /tmp/hoodselector_error hier einmal Posten.
Ein einrichten des o.g. zeitweisen Löschens der pid ist nicht so eine optimale Lösung. Ein hängen bleiben des hoodselectors sollte nicht passieren. Daher würde ich vor so einem schritt gerne erst mal vorschlagen das wir den Problem Auslöser versuchen zu finden.
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
so ....
bei folgenden Routern steht überall exakt das hier
/usr/bin/lua: /usr/sbin/hoodselector:741: attempt to index field 'vpnrouter' (a nil value) stack traceback: /usr/sbin/hoodselector:741: in function 'b' /usr/sbin/hoodselector:859: in main chunk [C]: ?
in der /tmp/hoodselector_error
FF-IBB-STADT05 ff-os-ameos-Gertrudenring5-nds1496 ff-os-ameos-Knollstrasse31-nds2149 FF-OS-Johannistorwall-56-03 FF-IBB-STADT20 ff-os-ameos-Gertrudenring7-nds1262 ff-os-ameos-Knollstrasse31-P2-nds1284 FF-OS-Johannistorwall-56-04 FF-IBB-STADT21 ff-os-ameos-Gertrudenring7-nds1263 ff-os-ameos-Knollstrasse31-S2-4r-nds1281 FF-OS-Johannistorwall-56-05 FF-IBB-STADT64 ff-os-ameos-Gertrudenring9-nds1264 ff-os-ameos-Knollstrasse31-S4-3l-nds1282 FF-OS-Johannistorwall-56-06 FF-IBB-STADT68 ff-os-ameos-Gertrudenring9-nds1265 ff-os-ameos-Knollstrasse31-S5-nds1283 FF-OS-Johannistorwall-56-07 FF-IBB-STADT70 ff-os-ameos-info01-nds1390 ff-os-ameos-Knollstrasse31-VER-nds1286 FF-OS-Johannistorwall-56-08 FF-IBB-STADT-grRatssaal ff-os-ameos-Knollstrasse27-nds1274 ff-os-ameos-Knollstrasse31-WB-nds1288 FF-OS-Johannistorwall-56-09 FF-IBB-STADT-klRatssaal ff-os-ameos-Knollstrasse29-nds1276 ff-os-ameos-Knollstrasse86a-A4-nds1915 FF-OS-Johannistorwall-56-11 ff-os-ameos-Gertrudenring12-nds1266 ff-os-ameos-Knollstrasse31-A2-1r-nds1277 ff-os-ameos-Knollstrasse86a-nds1486 FF-OS-Johannistorwall-56-13 ff-os-ameos-Gertrudenring12-nds1267 ff-os-ameos-Knollstrasse31-A5-1l-nds1279 ff-os-ameos-Knollstrasse86a-P1-nds1914 FF-OS-Johannistorwall-56-14 ff-os-ameos-Gertrudenring12-nds1268 ff-os-ameos-Knollstrasse31-A6-2l-nds1280 ff-os-ameos-Knollstrasse86b-TS-nds1916 FF-OS-Johannistorwall-56-15 ff-os-ameos-Gertrudenring12-nds1269 ff-os-ameos-Knollstrasse31d-nds1491 ff-os-ameos-Knollstrasse86-G1-nds1909 FF-OS-Johannistorwall-56-17-NDS ff-os-ameos-Gertrudenring12-nds1495 ff-os-ameos-Knollstrasse31d-nds1492 ff-os-ameos-Knollstrasse86-G2-nds1910 FF-OS-Martinistr-84 ff-os-ameos-Gertrudenring13-nds1270 ff-os-ameos-Knollstrasse31d-nds1906 ff-os-ameos-Knollstrasse86-IAG-nds1908 FF-OS-Martinistr-84-CPE-West ff-os-ameos-Gertrudenring13-nds1494 ff-os-ameos-Knollstrasse31d-nds1907 ff-os-ameos-Knollstrasse86-PSM1-nds1912 FF-OS-Martinistr-88-Dachboden ff-os-ameos-Gertrudenring2-nds1253 ff-os-ameos-Knollstrasse31-Lecker-nds1905 ff-os-ameos-mobil-nds2144 FF-OS-Peiner5-1R ff-os-ameos-Gertrudenring3-nds1255 ff-os-ameos-Knollstrasse31-Lift-nds1917 ff-os-ameos-mobil-nds2145 FF-OS-Rheiner-Landstr-195-02 ff-os-ameos-Gertrudenring3-nds1256 ff-os-ameos-Knollstrasse31-nds1487 FF-OS-BB-Johannistorwall-CPE210-1-NDS FF-OS-Rheiner-Landstr-195-03 ff-os-ameos-Gertrudenring4-nds1257 ff-os-ameos-Knollstrasse31-nds1489 FF-OS-BB-Johannistorwall-CPE210-2-NDS ff-os-ameos-Gertrudenring4-nds1258 ff-os-ameos-Knollstrasse31-nds1490 FF-OS-Bramscher-Str-159-03 FF-OS-Wenner-OG2 ff-os-ameos-Gertrudenring5-nds1260 ff-os-ameos-Knollstrasse31-nds1493 FF-OS-Johannistorwall-56-01 FF-RUL-Wilhelm-Roentgen-Str-10-50 ff-os-ameos-Gertrudenring5-nds1261 ff-os-ameos-Knollstrasse31-nds2147 FF-OS-Johannistorwall-56-02
bei FF-OS-Wenner-EG steht hingegen:
/usr/bin/lua: /usr/sbin/hoodselector:741: attempt to index field 'vpnrouter' (a nil value) stack traceback: /usr/sbin/hoodselector:741: in function 'b' /usr/sbin/hoodselector:920: in main chunk [C]: ?
hilft das weiter?
LG lorenz
Am 07.07.2017 um 13:56 schrieb Jan-Tarek Butt via Dev:
Hi,
Am 07.07.2017 um 11:15 schrieb lrnzo via Dev:
so teste ich das jetzt mal:
# cat /usr/lib/micron.d/hoodselector */2 * * * * if [ $(($(date +%s) - $(date +%s -r "/var/run/hoodselector.pid"))) -gt 120 ];then rm /var/run/hoodselector.pid;fi; /usr/sbin/hoodselector 2>> /tmp/hoodselector_error
Am 07.07.2017 um 11:02 schrieb lrnzo via Dev:
Hallo Leute,
sobald der hoodselector einmal nicht terminiert hat, kann er nicht wieder ausgeführt werden, weil er seine eigene pid-file (/var/run/hoodselector.pid) nicht gelöscht hat. Folgender Einzeiler löscht diese Datei, falls sie älter als 300 sekunden = (5 minuten) ist.
if [ $(($(date +%s) - $(date +%s -r "/var/run/hoodselector.pid"))) -gt 300 ];then rm /var/run/hoodselector.pid;fi
könnte das vielleicht als watchdog/cronjob in die nächste firmware mit rein? wäre schon sehr praktisch.
PS. ich teste das jetzt mal auf paar routern
Ist es bei dir öfter vorgekommen das dieser hängen bleibt ?
Falls du so einen zustand hast. Magst du den Output von /tmp/hoodselector_error hier einmal Posten.
Ein einrichten des o.g. zeitweisen Löschens der pid ist nicht so eine optimale Lösung. Ein hängen bleiben des hoodselectors sollte nicht passieren. Daher würde ich vor so einem schritt gerne erst mal vorschlagen das wir den Problem Auslöser versuchen zu finden.
vg Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
Hi,
bei folgenden Routern steht überall exakt das hier
/usr/bin/lua: /usr/sbin/hoodselector:741: attempt to index field 'vpnrouter' (a nil value) stack traceback: /usr/sbin/hoodselector:741: in function 'b' /usr/sbin/hoodselector:859: in main chunk [C]: ?
in der /tmp/hoodselector_error
FF-IBB-STADT05 ff-os-ameos-Gertrudenring5-nds1496 ff-os-ameos-Knollstrasse31-nds2149 FF-OS-Johannistorwall-56-03 FF-IBB-STADT20 ff-os-ameos-Gertrudenring7-nds1262 ff-os-ameos-Knollstrasse31-P2-nds1284 FF-OS-Johannistorwall-56-04 FF-IBB-STADT21 ff-os-ameos-Gertrudenring7-nds1263 ff-os-ameos-Knollstrasse31-S2-4r-nds1281 FF-OS-Johannistorwall-56-05 FF-IBB-STADT64 ff-os-ameos-Gertrudenring9-nds1264 ff-os-ameos-Knollstrasse31-S4-3l-nds1282 FF-OS-Johannistorwall-56-06 FF-IBB-STADT68 ff-os-ameos-Gertrudenring9-nds1265 ff-os-ameos-Knollstrasse31-S5-nds1283 FF-OS-Johannistorwall-56-07 FF-IBB-STADT70 ff-os-ameos-info01-nds1390 ff-os-ameos-Knollstrasse31-VER-nds1286 FF-OS-Johannistorwall-56-08 FF-IBB-STADT-grRatssaal ff-os-ameos-Knollstrasse27-nds1274 ff-os-ameos-Knollstrasse31-WB-nds1288 FF-OS-Johannistorwall-56-09 FF-IBB-STADT-klRatssaal ff-os-ameos-Knollstrasse29-nds1276 ff-os-ameos-Knollstrasse86a-A4-nds1915 FF-OS-Johannistorwall-56-11 ff-os-ameos-Gertrudenring12-nds1266 ff-os-ameos-Knollstrasse31-A2-1r-nds1277 ff-os-ameos-Knollstrasse86a-nds1486 FF-OS-Johannistorwall-56-13 ff-os-ameos-Gertrudenring12-nds1267 ff-os-ameos-Knollstrasse31-A5-1l-nds1279 ff-os-ameos-Knollstrasse86a-P1-nds1914 FF-OS-Johannistorwall-56-14 ff-os-ameos-Gertrudenring12-nds1268 ff-os-ameos-Knollstrasse31-A6-2l-nds1280 ff-os-ameos-Knollstrasse86b-TS-nds1916 FF-OS-Johannistorwall-56-15 ff-os-ameos-Gertrudenring12-nds1269 ff-os-ameos-Knollstrasse31d-nds1491 ff-os-ameos-Knollstrasse86-G1-nds1909 FF-OS-Johannistorwall-56-17-NDS ff-os-ameos-Gertrudenring12-nds1495 ff-os-ameos-Knollstrasse31d-nds1492 ff-os-ameos-Knollstrasse86-G2-nds1910 FF-OS-Martinistr-84 ff-os-ameos-Gertrudenring13-nds1270 ff-os-ameos-Knollstrasse31d-nds1906 ff-os-ameos-Knollstrasse86-IAG-nds1908 FF-OS-Martinistr-84-CPE-West ff-os-ameos-Gertrudenring13-nds1494 ff-os-ameos-Knollstrasse31d-nds1907 ff-os-ameos-Knollstrasse86-PSM1-nds1912 FF-OS-Martinistr-88-Dachboden ff-os-ameos-Gertrudenring2-nds1253 ff-os-ameos-Knollstrasse31-Lecker-nds1905 ff-os-ameos-mobil-nds2144 FF-OS-Peiner5-1R ff-os-ameos-Gertrudenring3-nds1255 ff-os-ameos-Knollstrasse31-Lift-nds1917 ff-os-ameos-mobil-nds2145 FF-OS-Rheiner-Landstr-195-02 ff-os-ameos-Gertrudenring3-nds1256 ff-os-ameos-Knollstrasse31-nds1487 FF-OS-BB-Johannistorwall-CPE210-1-NDS FF-OS-Rheiner-Landstr-195-03 ff-os-ameos-Gertrudenring4-nds1257 ff-os-ameos-Knollstrasse31-nds1489 FF-OS-BB-Johannistorwall-CPE210-2-NDS ff-os-ameos-Gertrudenring4-nds1258 ff-os-ameos-Knollstrasse31-nds1490 FF-OS-Bramscher-Str-159-03 FF-OS-Wenner-OG2 ff-os-ameos-Gertrudenring5-nds1260 ff-os-ameos-Knollstrasse31-nds1493 FF-OS-Johannistorwall-56-01 FF-RUL-Wilhelm-Roentgen-Str-10-50 ff-os-ameos-Gertrudenring5-nds1261 ff-os-ameos-Knollstrasse31-nds2147 FF-OS-Johannistorwall-56-02
bei FF-OS-Wenner-EG steht hingegen:
/usr/bin/lua: /usr/sbin/hoodselector:741: attempt to index field 'vpnrouter' (a nil value) stack traceback: /usr/sbin/hoodselector:741: in function 'b' /usr/sbin/hoodselector:920: in main chunk [C]: ?
hilft das weiter?
Ja das ist sehr hilfreich :-)
Genau sowelche informationen sind vorbildlich *TOP*
schöne Grüße vom SHA2017 Tarek
On 08/04/17 13:15, Jan-Tarek Butt via Dev wrote:
Hi,
bei folgenden Routern steht überall exakt das hier
/usr/bin/lua: /usr/sbin/hoodselector:741: attempt to index field 'vpnrouter' (a nil value) stack traceback: /usr/sbin/hoodselector:741: in function 'b' /usr/sbin/hoodselector:859: in main chunk [C]: ?
in der /tmp/hoodselector_error
FF-IBB-STADT05 ff-os-ameos-Gertrudenring5-nds1496 ff-os-ameos-Knollstrasse31-nds2149 FF-OS-Johannistorwall-56-03 FF-IBB-STADT20 ff-os-ameos-Gertrudenring7-nds1262 ff-os-ameos-Knollstrasse31-P2-nds1284 FF-OS-Johannistorwall-56-04 FF-IBB-STADT21 ff-os-ameos-Gertrudenring7-nds1263 ff-os-ameos-Knollstrasse31-S2-4r-nds1281 FF-OS-Johannistorwall-56-05 FF-IBB-STADT64 ff-os-ameos-Gertrudenring9-nds1264 ff-os-ameos-Knollstrasse31-S4-3l-nds1282 FF-OS-Johannistorwall-56-06 FF-IBB-STADT68 ff-os-ameos-Gertrudenring9-nds1265 ff-os-ameos-Knollstrasse31-S5-nds1283 FF-OS-Johannistorwall-56-07 FF-IBB-STADT70 ff-os-ameos-info01-nds1390 ff-os-ameos-Knollstrasse31-VER-nds1286 FF-OS-Johannistorwall-56-08 FF-IBB-STADT-grRatssaal ff-os-ameos-Knollstrasse27-nds1274 ff-os-ameos-Knollstrasse31-WB-nds1288 FF-OS-Johannistorwall-56-09 FF-IBB-STADT-klRatssaal ff-os-ameos-Knollstrasse29-nds1276 ff-os-ameos-Knollstrasse86a-A4-nds1915 FF-OS-Johannistorwall-56-11 ff-os-ameos-Gertrudenring12-nds1266 ff-os-ameos-Knollstrasse31-A2-1r-nds1277 ff-os-ameos-Knollstrasse86a-nds1486 FF-OS-Johannistorwall-56-13 ff-os-ameos-Gertrudenring12-nds1267 ff-os-ameos-Knollstrasse31-A5-1l-nds1279 ff-os-ameos-Knollstrasse86a-P1-nds1914 FF-OS-Johannistorwall-56-14 ff-os-ameos-Gertrudenring12-nds1268 ff-os-ameos-Knollstrasse31-A6-2l-nds1280 ff-os-ameos-Knollstrasse86b-TS-nds1916 FF-OS-Johannistorwall-56-15 ff-os-ameos-Gertrudenring12-nds1269 ff-os-ameos-Knollstrasse31d-nds1491 ff-os-ameos-Knollstrasse86-G1-nds1909 FF-OS-Johannistorwall-56-17-NDS ff-os-ameos-Gertrudenring12-nds1495 ff-os-ameos-Knollstrasse31d-nds1492 ff-os-ameos-Knollstrasse86-G2-nds1910 FF-OS-Martinistr-84 ff-os-ameos-Gertrudenring13-nds1270 ff-os-ameos-Knollstrasse31d-nds1906 ff-os-ameos-Knollstrasse86-IAG-nds1908 FF-OS-Martinistr-84-CPE-West ff-os-ameos-Gertrudenring13-nds1494 ff-os-ameos-Knollstrasse31d-nds1907 ff-os-ameos-Knollstrasse86-PSM1-nds1912 FF-OS-Martinistr-88-Dachboden ff-os-ameos-Gertrudenring2-nds1253 ff-os-ameos-Knollstrasse31-Lecker-nds1905 ff-os-ameos-mobil-nds2144 FF-OS-Peiner5-1R ff-os-ameos-Gertrudenring3-nds1255 ff-os-ameos-Knollstrasse31-Lift-nds1917 ff-os-ameos-mobil-nds2145 FF-OS-Rheiner-Landstr-195-02 ff-os-ameos-Gertrudenring3-nds1256 ff-os-ameos-Knollstrasse31-nds1487 FF-OS-BB-Johannistorwall-CPE210-1-NDS FF-OS-Rheiner-Landstr-195-03 ff-os-ameos-Gertrudenring4-nds1257 ff-os-ameos-Knollstrasse31-nds1489 FF-OS-BB-Johannistorwall-CPE210-2-NDS ff-os-ameos-Gertrudenring4-nds1258 ff-os-ameos-Knollstrasse31-nds1490 FF-OS-Bramscher-Str-159-03 FF-OS-Wenner-OG2 ff-os-ameos-Gertrudenring5-nds1260 ff-os-ameos-Knollstrasse31-nds1493 FF-OS-Johannistorwall-56-01 FF-RUL-Wilhelm-Roentgen-Str-10-50 ff-os-ameos-Gertrudenring5-nds1261 ff-os-ameos-Knollstrasse31-nds2147 FF-OS-Johannistorwall-56-02
bei FF-OS-Wenner-EG steht hingegen:
/usr/bin/lua: /usr/sbin/hoodselector:741: attempt to index field 'vpnrouter' (a nil value) stack traceback: /usr/sbin/hoodselector:741: in function 'b' /usr/sbin/hoodselector:920: in main chunk [C]: ?
Der Fehler ist nun behoben.
Es war eine fehlende NULL Prüfung im MOLWM Protokoll.
@lorenz vielen dank für das super Feedback.
schöne Grüße von der SHA2017 Tarek
btw: wie lt ist bzw. war dieser bug eigentlich?
lg lrnzo
Am 07.08.2017 um 23:10 schrieb lrnzo via Dev:
immer gerne, schöne Grüße nach Holland
Der Fehler ist nun behoben.
Es war eine fehlende NULL Prüfung im MOLWM Protokoll.
@lorenz vielen dank für das super Feedback.
schöne Grüße von der SHA2017 Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
btw: wie alt ist bzw. war dieser bug eigentlich?
lg lrnzo
Am 07.08.2017 um 23:10 schrieb lrnzo via Dev:
immer gerne, schöne Grüße nach Holland
Der Fehler ist nun behoben.
Es war eine fehlende NULL Prüfung im MOLWM Protokoll.
@lorenz vielen dank für das super Feedback.
schöne Grüße von der SHA2017 Tarek
Dev mailing list Dev@lists.ffnw.de https://lists.ffnw.de/mailman/listinfo/dev
-
Jan-Tarek Butt -
Johannes Rudolph -
lrnzo