aufgrund meiner zeitenweisen (über)last-probleme von perl hab ich mir einen workaraound ausgedacht - ich jetzt einfach perl killen und fhem restarten.
der erste teil is mir schon mal klar, aber wie könnte man mit totem perl fhem automatisch anwerfen?
( [ratOhaus_SM:cpu_temp] >= 80 and [ratOhaus_SM:userCpu] >= 20 )
(
set ratOtab_AMAD ttsMSG achtung übertemeperatur im ratOhaus mit [ratOhaus_SM:cpu_temp] grad - fhem wird neu gestartet;
)
(
{system "at now +15 seconds -f ~/fhemstartscript.sh"};
{system "at now +5 seconds -f ~/fhemstopscript.sh"};
)
------------------
wait 600,10
fhemstopscript.shsudo /etc/init.d/fhem stop
sudo killall perlkönnte man hier zw. den befehlen im script ne pause einfügen? nur zur sicherheit.
fhemstartscript.shsudo /etc/init.d/fhem start
Ich verstehe nicht, was du machen willst aber wenn Du all perl kills, hast Du nix mehr, und kannst nix mehr ansteuern...
Du könnest vielleicht ZUERST ein system atd/at einrichten, und ERST DANN killen.
man atd
ATD(8) System Manager's Manual ATD(8)
NAME
atd - run jobs queued for later execution
SYNOPSIS
atd [-l load_avg] [-b batch_interval] [-d] [-f] [-s]
at now +10 seconds -f ~/fhemstartscript.sh
at lässt sich über "sudo apt-get install at" isntallieren. Atd ist nw. schon installiert.
Ich halte aber das ganze für gefährlich...
oh, thx für deine idee
nun - ich erklärs mal genauer ... nicht, dass mich wieder jeder missversteht *g*
ich hab bei zeiten probleme mit der auslastung von perl. immer mal wieder rennt perl auf vollast und somit steigt die temp. bei meinem raspi mal gerne recht schnell an.
da mir bis jetzt niemand wirklich beim eigentlichen problem helfen konnte ( https://forum.fhem.de/index.php/topic,72628.0.html ), such ich eben nach möglichkeiten ruhig schlafen zu können, ohne am nächsten tag einen rauchenden plastikhaufen als server zu haben (<-- dramatisation).
das einzige, das bisher (bis jetzt 1 mal) gefunzt hat (ich muß ja leider immer warten, bis perl wieder mal zu spinnen geruht), war eben perl ganz abzuschießen und dann fhem zu starten. nicht mal ein stromlos machen des raspi hatte geholfen (nur, falls die frage aufkommen sollte)
drum dachte ich eben in meiner naivität: die 2 befehle funzen, wenn ich die also automatisieren kann, dann hab ich weniger angstschweiß auf der stirn und fhem rennt (fast) durch.
d.h.:
ich brauche eine möglichkeit, die mir fhem flexibel restarten kann, da ich ja nicht weiß, wann wieder mal perl (oder was auch immer) spinnt.
der vorgang wäre ja wie folgt:
1) fhem oder das system stellt fest, dass die prozi-last mehrere minuten über 20% und die temp. über 80° liegt.
2) es wird ein temporärer cronjob angelegt, der mir fhem wieder startet - sagen wir --> derzeitige uhrzeit + 10 sek. vom feststellen des problems weg.
3) vor den 10 sek. wird natürlich noch perl gekilled.
4) fhem rennt wieder und die last is weg (zumindest hoffe ich, dass das nicht nur 1 mal gefunzt hat *g*).
nachdem ich von linux keine bis gar keine ahnung habe, allerdings wenigstens langsam bei fhem den total-dau-satus verlasse und zum forgeschrittenen dau aufsteige, dachte ich halt, das sollte sich mit fhem lösen lassen, weil ich das ganze dann wenigstens ansatzweise im griff hab, ohne euch alle 5 min hier im forum auf die nerven zu gehen.
in meinem doif würde dein at also wie folgt aussehen?
{system "at now +10 seconds -f sudo /etc/init.d/fhem start"};
oder muss ich mir da unbedingt ein script für basteln und wie müsste das dann aussehen?
nachtrag:
ich hab jetzt mal at installiert
was meinst den eig. mit gefährlich?
Gefährlich, falls Du andere Prozessen hast, die Perl nutzen.
Auch "killen" führt zu Instabilität des Systems. Irgendwann wird dein fhem nicht mehr starten können, da ein state nicht gespeichert worden ist o.ä.
Also... du kümmerst dich um die Symptomen aber nicht um die Krankheit... Na gut, ich hätte andere Alternativen: was mit eine Wasserlöschanlage mit Sprinkler über den Raspi? ;)
Blöde Frage: wenn perl spinnt, kannst Du trotzdem fhem runterfahren (stop, nicht kill)? Das wäre schon besser.
-f sudo /etc/init.d/fhem start
kann nicht funktionieren.
-f option => Skript Datei. Du musst ein fhemstartscript.sh haben, mit beliebigem Inhalt (z.B. sudo /etc/init.d/fhem start).
ZitatBlöde Frage: wenn perl spinnt, kannst Du trotzdem fhem runterfahren (stop, nicht kill)? Das wäre schon besser.
ja.
fhem rennt ja sogar, nur die weboberfläche wird sau langsam. alles andere rennt überhaupt wie wenn nix wäre.
dann müsste man ja nur noch den befehl zum stoppen von fhem vor den kill legen. dann sollte man da auch sicher sein. fhem selber nur zu stoppen und zu starten reicht leider nicht.
sprich: erst mal dein at, dann fhem stop und hintenan noch perl kill. paar sekunden zw. stop und kill sollten, denke ich reichen, oder?
ZitatDu musst ein fhemstartscript.sh haben, mit beliebigem Inhalt (z.B. sudo /etc/init.d/fhem start).
na das schaff sogar ich *g*
das .sh leg ich einfahc in fhem rein, denk ich?
ZitatAlso... du kümmerst dich um die Symptomen aber nicht um die Krankheit...
ich weiß und das tut sogar mir weh.
aber wenn mir hier schon keiner helfen kann, werd ichs selber auch nicht schaffen. da nehm ich dann lieber wenigstens ne notlösung.
ZitatNa gut, ich hätte andere Alternativen: was mit eine Wasserlöschanlage mit Sprinkler über den Raspi? ;)
DAS is DIEEEEEE idee, mein großer meister *g*
nur eines dazu: DU kommst vorbei und erklärst das meiner holden, nachdem ich definitiv in einen bunker mit mind. 3 atombomensicheren türen sitze. zur info: die frau hat ein nudelholz aus edelstahl mit dornen dran.
basteln wir mal - in der hoffnung, dass damian das sieht und nicht gleich lachen muß:
in den 1. beitrag kopiert, damits nicht unüberischtlich wird
Kannst Du mal versuchen
attr Fembotter disable 1
attr Fembotter channelGuide 0?
Und gucken, ob deine CPU immer noch spinnt.
hat ich auch schon mal probiert und hat auch nix gebracht. vor allem - die channel-guide ist bei mir aus, weil die mir zu langsam is.
wenns das nächste mal spinnt (kann also mal ne woche dauern), werd ichs aber nochmal probieren.
hatte das letzte mal so gut wie alle multimedia-dinger aus - der dlna-renderer steht ja auch hoch auf meiner verdachtsliste.
btw - channelguide 0 ist bei dem modul nicht vorgesehen. der autor meint in solchen fällen, das es ja das selbe wäre, wie das attribut zu löschen.
Wenn das spinnt ist es schon zu spät. Ich meinte jetzt deaktivieren, und gucken, ob das Problem immer noch passiert.
is schon klar - nur kann ich (besser miene schlechtere hälfte) dann meinen tv ned steuern und mit "pech" muß ich tage bis wochen warten, bis das ding wieder spinnt.
anhand des laufenden tv's werden auch andere dinge geregelt - das krieg ich ohne dem modul nie auf die reihe
Keine Fernbedienung?
*g* jo, braucht nur batterien. hab sogar die über-drüber-fb mit schütteln und zeigen *g*.
das problem sind div. aktionen, - wie z.b. gute-nacht-schaltungen - die den tv als trigger nehmen.
aber mal ganz dumm gefragt: nehmen ma mal an, das problem tritt wieder auf.
ich mach das fembotter-device aus stop/starte fhem. dann müsste ja der tv aussen vor sein.
nachdem ein stop/start bis jetzt nie was gebracht hat, sollte ich also dann sehen, obs der tv is. geht fhem dann wieder, wars der tv, gehts immer noch nicht, war ers nicht.
stimmt die milchmädchenrechnung?
Ja, ok, kannst so probieren. Nicht vergessen: "save" nachdem du die Attributes gesetzt hast, sonst sind die nach dem shutdown restart wieder da...
Habe das jetzt mehrfach geschaut, finde aber das
DOIF-Problem nicht. :-X
Zitat von: the ratman am 24 Juni 2017, 21:21:45nicht mal ein stromlos machen des raspi hatte geholfen
Wenn das nicht reicht, wie soll dann kill, welches ja viel weniger macht, erfolgreich sein?!
Evtl. wäre ja ein zweiter Server was für dich. Dann kannst du schauen, ob Fhem oder jemand anderes der Übeltäter ist. Dann müsstest du evtl. auch Perl nicht killen.
Noch eine kleine Bitte: streu doch ab und an ein paar Großbuchstaben an der richtigen Stelle ein, das ist kein Chat und es liest sich echt leichter. Und je leichter du es uns machst, umso besser können wir dir helfen ;).
@per
das doif hat auch kein problem - das hab ich eigentlich hier nur rein gestellt, dass damian oder einer der anderen doif-künstler mir die funktionalität bestätigt. bei solcherlei automatisierten eingriffen "ins system" frag ich dann doch lieber, bevor ich n nicht funzendes doif hab und mich trotzdem sicher fühl.
dass wir hier jetzt wegen meines eigentlichen problems weiter quasseln, hat sich halt so ergeben. eig. sollt das alles in einen anderen fred stehen.
Wenn das nicht reicht, wie soll dann kill, welches ja viel weniger macht, erfolgreich sein?!fragst das mich?
ich hab keinen schimmer. ich weiß nur folgendes:
x mal fhem mit stop/start versucht --> kein erfolg
x mal den raspi rebootet --> kein erfolg
x mal den raspi ausgesteckt --> kein erfolg
1 mal bis jetzt perl gekilled --> hat gefunzt (hoffentlich wars nicht wieder ein zufall - hatte ich schon mal)
btw - weißt du eig. was großbuchstaben kosten? sowas kann ich mir ned leisten.
@amenomade
jo, das "save" wird wieder lustig, wenn das ding unter volllast rennt *g* da kannst du schon mal alt werden beim warten drauf. aber ich kenn das jetzt ja schon ...
Zitat von: the ratman am 25 Juni 2017, 11:07:43
1 mal bis jetzt perl gekilled --> hat gefunzt (hoffentlich wars nicht wieder ein zufall - hatte ich schon mal)
Na viel Spass beim Fehler suchen!
Zitat von: the ratman am 25 Juni 2017, 11:07:43btw - weißt du eig. was großbuchstaben kosten? sowas kann ich mir ned leisten.
OK, meine Zeit ist auch nicht umsonst.
@amenomade
ich befürchte, du hast recht.
hatte wieder den anfang eines tempereaturanstiegs, meinen tv disabled, fhem per weboberfläche restartet und dann keine "überlast" mehr gehabt.
jetzt werd ich mal cooltux fragen, ob ihm was einfallt ...
btw - der tv war aus ... seit gestern abend
und sicherheitshalber noch ein list von meinem "Fembotter" (seht ihr das GOSSE F?)Internals:
DEF 192.168.178.29
HOST 192.168.178.29
NAME Fembotter
NR 170
PARTIAL
STATE disabled
TYPE LGTV_WebOS
VERSION 0.6.0
Readings:
2017-06-25 00:44:18 3D off
2017-06-25 00:44:18 3DMode 2d
2017-06-25 11:45:10 channel -
2017-06-25 11:45:10 channelCurrentEndTime -
2017-06-25 11:45:10 channelCurrentStartTime -
2017-06-25 11:45:10 channelCurrentTitle -
2017-06-25 11:45:10 channelMedia -
2017-06-25 11:45:10 channelName -
2017-06-25 11:45:10 channelNextEndTime -
2017-06-25 11:45:10 channelNextStartTime -
2017-06-25 11:45:10 channelNextTitle -
2017-06-25 00:44:20 extInput_AV-1 connect_false
2017-06-25 00:44:20 extInput_AV-2 connect_false
2017-06-25 00:44:20 extInput_HDMI-1 connect_false
2017-06-25 00:44:20 extInput_HDMI-2 connect_false
2017-06-25 00:44:20 extInput_HDMI-3 connect_false
2017-06-25 00:44:20 extInput_HDMI-4 connect_false
2017-06-25 00:44:20 extInput_Komponente connect_false
2017-06-25 00:44:16 input -
2017-06-25 00:44:26 lastResponse ok
2017-06-25 00:44:16 launchApp TV
2017-06-24 18:33:39 lgKey 20bfc93ff6574d66bc70712d548d4e2d
2017-06-25 00:44:22 mute off
2017-06-25 00:44:26 pairing paired
2017-06-25 11:45:12 presence absent
2017-06-25 12:06:54 state disabled
2017-06-25 00:44:22 volume -1
Helper:
Device:
registered 0
runsetcmd 0
Channelguide:
counter 128
Attributes:
DbLogExclude .*
channelGuide 0
cmdIcon channelUp:control_arrow_up channelDown:control_arrow_down
devStateIcon on:it_television@green:off off:it_television@red:on
disable 1
group TV
icon it_television
pingPresence 1
room MultiMedia
webCmd channelUp:launchApp:channelDown
nachtrag:
cooltux - flott wie immer - meinte: ich soll mal nur pingpresence abdrehen.
das mach ich nu mal. wenns nur das wäre, würd ich party machen *g*
pingpresence alleine scheints nicht zu sein.
sobald ich das modul wieder aktiviere (ohne presence), geht die last sofort wieder hoch
hau ich disabled 1 rein, gehts wieder runter
wir scheinen also den übeltäter gefunden zu haben ... fragt sich nur, warum.
der ist ewigkeiten problemlos gerannt.
immer noch hab ich das dlna-render modul im verdacht, weil das ja total den spinner (warnings ohne ende im log) kriegt, wenn ich den fembotter einschalte.
ich krieg da nur leider keine antwort drauf: https://forum.fhem.de/index.php/topic,72423.msg645104.html#msg645104
das wird wohl ne lustige entscheidung werden, worauf ich verzichten muß ...
die steuerung meines tv oder die ansteuerung aller wlan-ls im haus, die ich dann ja eig. in den müll kicken kann.
Kannst du das dlna Render Modul Mal abschalten und das LG Modul wieder an?
ja, wenn mir der dlna nicht wieder rein pfuscht mit irgendwelchen unsichtbaren modulen - da is ja ned nur 1 ding abzustellen.
ich mach mal und berichte hier.
nachtrag:
jetzt steh ich schön blöd da ...
das dämliche ding hat nicht mal ein disable attribut.
hab dïe dinger nu total gelöscht - mal gucken
steigt zumindest ned sofort an, die temp.
cool, willst ned n funzendes dlna-render-device bauen? *g*
jetzt bin ich ganz frech und schalt die pingpresence wieder ein
Teste einfach mal paar Stunden oder auch einen Tag.
jo, so wies ausschaut wird sich mir die nächste frage wie folgt stellen:
"braucht irgendwer billige wlan boxen die nix können?"
und ich ruf folgende aus cool:
sollte wirklich der dlna-renderer schuld sein und du da irgendwas zaubern können, kriegst dazu meine test-box geschenkt
--> http://amzn.to/2tIQl4U
Meinst das liegt an den Boxen?
nö, sind halt "billige" dinger fürs bad und mit sonos oder so nicht mal ansatzweise zu vergleichen. und wenn du einen (erweiterten) beitrag vorher liest, wirst du sehen, dass ich meine testbox an dich abschieben will *g*
ich sag dir aber gleich: die dinger bauen ein eigenes wlan-netz auf, auch wenn dus in deines einbindest. nervt gewaltig ...
Oh je die sind ja hässlich wie die Nacht ;D
Konntest Du die Teile mit FHEM und dlna den steuern? Kenne ich damit so gar nicht aus.
ja, funzt wunderbar eigentlich.
die boxen hab ich gekauft, weils halt auch bluetooth können und n micro haben. so nach dem motto: wirds mit dlna nix, kann mans wenigstens noch mit den handys betreiben. gedacht war die box auch für gartenarbeiten meiner holden, weils ja auch nen akku hat und die tasten gut geschützt vor dreck sind.
die dinger sind klein und somit ned auffällig, der sound bringt nen audiophilen sicher nicht hinterm sofa vor, aber der bass passt und der rest is annehmbar. die dinger sind für ihre größe auch verdammt laut.
fazit: sie funzen, auch mit dem dlna-renderer und mit der muzo-app sowieso.
was ich halt ned versteh is, dass ich für jede box ein eigenes wlan-netz auf dem kanal meines eigentlichen wlans bekomme, obwohl die boxen zur selben zeit auch in eben meinem wlan eingebunden sind.
und ja - bt und wlan geht nicht gleichzeitig.
wegen hässlich: drum hab ich auch als weitere geräte folgendes gekauft: http://amzn.to/2tIT12E
sind der selbe hersteller haben aber anstelle bt noch zusätzlich lan und man kann somit seine eigenen boxen verwursten, was mir schon soundmäßig viel besser gfallt *g*
die kriegst aber nicht ... *ätsch*
btw - betreiben tu ich das wie folgt:
auf meiner nas rennt ein mpd-server, der als "soundkarte" nen icecast2 füttert.
und der icecast gibt den dlna-stream, den der dlna-renderer dann an die boxen verteilt. mit ls einstellen und blaaa, blubbb, blaa (allerdings kriegt er keine rückmeldung zur ls von den boxen)
aussehen tut das dann so http://ratman.at/images/stories/711/lichtfurz/media.png
oben die 2 einsteller für 2 der boxen, drunter im iframe ein webclient zum steuern des mpd
das dumme dabei: der dlna-renderer findet iMMER meinen lg-tv, der aber mit dem stream gar nix anfangen kann. und da liegt dann wohl das problem begraben. eure module scheinen sich irgendwo im weg zu stehen.
soviel zu meiner extrem professionellen annahme *g*
so,
abschließend noch: scheinbar vertragen sich der dlna-renderer und das tv-modul wirklich nicht.
seit ich den renderer ganz gekilled hab, rennt alles butterweich. ich hab weder fehlermeldungen des im log, noch auch nur noch 1 mal eine dieser "überlasten" ghabt.
für mich stellt sich halt somit die frage: welches der beiden module ist den daran "schuld" und was könnte man machen, um beide gemeinsam ins leben zu rufen? brauchen würd ich sie nämlich tatsächlich beide dringend.