Danke für die Rückmeldung.
Das ist wohl der Knackpunkt, weswegen es nur per sudo funktioniert.
Ich werde mal einen Test mit einer reinen Ubuntu-Distro testen.
Ein erneuter Test mit Ubuntu 14.04 LTS hat auch keinen Verbesserung mit der Autostart-Funktion des symcon-Dienstes ergeben.
Nach dem Neustart des Systems läuft symcon nicht wieder an!!
Das Ausführen des Startbefehls als root (nach Eingabe von sudo -i) hat auch keine Verbesserung ergeben.
siehe unten
ips@NENsIPS:~$ sudo ps x | grep symcon
[sudo] password for ips:
ips@NENsIPS:~$ sudo -i
root@NENsIPS:~# ps x | grep symcon
2174 pts/9 S+ 0:00 grep --color=auto symcon
root@NENsIPS:~# /etc/init.d/symcon start
IP-Symcon started with PID 2187
root@NENsIPS:~# ps x | grep symcon
2187 ? Ssl 0:00 /usr/bin/symcon service
2220 pts/9 S+ 0:00 grep --color=auto symcon
Hat noch jemand eine Idee??
Das ist echt merkwürdig…Hast du die Server oder Desktop Version?
Die rc scripts hast du geprüft, wie oben beschrieben? Bitte mal rebooten und die logs anschauen. Steht was im IPS log?
Gruß
Hallo,
ich habe das mal nachgestellt (mit Ubuntu 14.04 LTS Server).
der Autostart nach einem Reboot funktioniert, jedoch stürzt der Dienst direkt wieder ab. Die letzte Meldung im Log ist
14:28:25 | 20315 | MESSAGE | Module Control | Creating...
Apport meldet einen Crash:
Scheint also ein Bug in der Ubuntu bzw. x86 Version zu sein?
Gruß
Ist bei mit Identisch, auch der Absturz beim Laden des Modul Control nachdem das System gestartet ist.
Anschließend kann IPS jedoch per Hand starten und es läuft.
Das Apport einen Crash meldet, hatte ich hier schon mal gepostet… aber das ist ja schon ein ‚paar‘ Versionen her.
IP-Symcon Community Forum
Michael
Hallo,
ich habe das mit der Desktop-Version festgestellt.
Mit der Server-Version wollte ich das auch noch testen.
Unter LinuxMint 17.2 bekomme ich eine Fehlermeldung.
Ich kann damit noch nicht viel anfangen, ich muss mich mit den Meldungen erst noch auseinander setzen.
Sobald ich näheres weis, melde ich mich.
Vielen Dank auch für Deine Bemühungen.
Ich frage mich nur, was machen die anderen Ubuntu-User??
Bei denen müsste das doch auch aufgefallen sein. :rolleyes:
Hi,
ich habe bei meinem 6 Raspis das gleiche Problem festgestellt.
Vermutlich bedingt dadurch, dass ich auf die aktuelle Beta nicht mittels „sudo apt-get upgrade“ sondern nur mittels „sudo apt-get install symcon“ kam, sind die Verzeichnisrechte alle von PI auf ROOT geändert worden.
Folgende zwei Befehle beheben das Problem:
cd /usr/share
sudo chown pi:pi symcon -R
Beste Grüße
herbertf
Auch wenn nun SYMCON bei den Reboots startet, hat die aktuellste BETA doch solche Probleme, sie stürzt ja ständig ab. :(:(
Gehe jetzt wieder mit einigen Installs auf den 23.06. zurück (symcon_0.1-200_armhf.deb)
Hast du da mehr Infos für mich? Da wir einiges geändert haben (=ändern mussten) kann es gut sein, dass die Stabilität zur Zeit noch schlechter ist als in den Vorversionen. Ich würde aber gerne die Verursacher finden und eliminieren 
paresy
Hi Paresy,
würde ich auch gern.
Habe derzeit noch ein System auf der aktuellen Beta - stürzt nach ca. 5 - 30 Minuten ab (nur der SYMCON Dienst). Ich kann Dir gern Logs senden, im SYMCON Log steht aber nix.
Debugging für Experten habe ich auch schon gemacht, da erscheint:
(gdb) run
Starting program: /usr/bin/symcon
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
Program received signal SIGILL, Illegal instruction.
0x76e3b608 in ?? () from /usr/lib/arm-linux-gnueabihf/libcrypto.so.1.0.0
(gdb)
Hilft Dir dies?
Hi Paresy,
anbei die Anzahl Abstürze anhand der Log-Files. Ich starte remote den IPS-Dienst neu, bei Ausfall größer 5 Minuten. Die aktuelle Version ist faktisch nicht einsetzbar:
Soll ich einen extra Thread aufmachen, thematisch sind wir ja hier eher falsch?
herbert
Hm. Hast du eine Möglichkeit ein „frisches“ oder kleines System bei dir aufzusetzen, damit wir eingrenzen können woran es liegt?
paresy
Mache ich jetzt für Dich …
Danke! Bisher scheint es nämlich nur bei dir so oft abzustürzen.
Wobei evtl. dieses Problem hier passend sein könnte: IP-Symcon Community Forum
paresy
Hi Paresy,
ich bin an dem Thema noch dran, der erste TEST-Raspberry läuft, die I/O-Schnittstellen (GPIO/I2C) kann ich aber nicht wirklich nachbilden …
Ich werde jetzt noch einen meiner AKTIVEN wieder auf die aktuelle Beta nehmen.
Melde mich auf alle Fälle.
herbertf
Hi Paresy,
ich konnte den Fehler jetzt mehrfach (nicht immer!) reproduzieren !!!
Auf meinem Hauptsystem (Win) starte ich zyklisch ein Script,welches ein Script auf dem Remotesystem (Raspi) startet:
<?
$Par_ID=IPS_GetParent($_IPS['SELF']);
$Name=IPS_GetName($Par_ID);
IPS_LogMessage("$Name", "Generalabfrage durchführen");
$rpc=new JSONRPC("http://xxx@yyyyy:zzzzz@192.168.4.56:3777/api/");
$rpc->IPS_RunScript(36875);
?>
Dies führt bei den Versionen mit dem geänderten PHP fast immer zum Absturz des IPS-Dienstes!
Ob dies am Inhalt des Scriptes (Generalabfrage aller Werte welche uebertragen werden sollen) auf dem PI liegt habe ich noch nicht untersucht, dieser ist:
<?
// GA ausfuehren fuer alle Variablen im Ordner
$Par_ID=IPS_GetParent($_IPS['SELF']);
$variablen_array=IPS_GetChildrenIDs($Par_ID);
$var_ids = array();
foreach ($variablen_array as $value) //durchsucht alle Objekte unter PAR_ID
{
$var_object_type=IPS_GetObject($value);
$ObjTyp=$var_object_type['ObjectType'];
$Name=IPS_GetName($value);
// Ermittlung Variable
If ($ObjTyp==2) { //Prüfung ob Objekt Variable
//echo $Name;
$Variable=IPS_GetVariable ($value);
$ObjInfo=$var_object_type['ObjectInfo'];
$Nummer= (int) substr($ObjInfo, -2);
//echo " $ObjInfo $Nummer ";
$wert=(int) shell_exec("/usr/local/bin/gpio read $Nummer");
if ($wert==0) $wert=false;
else $wert=true;
//echo " $value - $wert
";
If (GetValueBoolean($value)!=$wert) SetValueBoolean($value,$wert);
}
}
IPS_Sleep(1000);
//Variablen übertragen
$variablen_array=IPS_GetChildrenIDs($Par_ID);
$var_ids = array();
foreach ($variablen_array as $value) //durchsucht alle Objekte unter PAR_ID
{
$var_object_type=IPS_GetObject($value);
$ObjTyp=$var_object_type['ObjectType'];
$Name=IPS_GetName($value);
// Ermittlung Variable
If ($ObjTyp==2) { //Prüfung ob Objekt Variable
$Variable=IPS_GetVariable ($value);
$ObjID=$var_object_type['ObjectID'];
//echo "Object $ObjID
";
$ScriptID=@IPS_GetScriptIDByName("uebertragen",$ObjID);
if (@IPS_ScriptExists($ScriptID)) {
IPS_RunScript($ScriptID);
//echo "Script=$ScriptID gestartet
";
}
}
}
?>
Bitte beheb diesen Fehler - geht in den alten Versionen tadellos.
herbertf
Ich kann dies leider bisher hier nicht nachstellen. Kannst du den Absturz auch provozieren, wenn du das Skript direkt auf dem Pi ausführst?
paresy
auf einem Testsystem ja - auf einem nein
Bin jetzt gerade dabei SYMCON neu zu installieren und auch ein Raspi FW-Update zu machen - melde mich nochmals
Hallo Paresy,
ich hatte mir ja bereits vorgestern einen jungfräulichen PI1 neu aufgesetzt, auf diesen habe ich gestern die „am häufigsten abstürzende SYMCON-Installation“ aufgespielt - und keinen Absturz gehabt seit gestern Abend (ca. 24h).
Auf meinen aktiven PI2 konnte ich den Fehler ja relativ sicher auslösen (vorhergehende Beiträge). Ich habe mir nun jetzt die Mühe gemacht ein Produktivsystem ebenfalls ganz jungfräulich aufzusetzen. Diesmal habe ich die seit 24h funktionierende Symcon Installation des 1.Testsystems aufgespielt.
Hier ist der Fehler da.
Ich habe nun folgendes Script auf dem „jungfräulichen PI1“ und dem „jungfräulichen PI2“ gestestet und bin überzeugt, der FEHLER TRITT NUR AM PI2 auf!
Ich habe „quick and dirty“ relativ weit unten im folgenden Script ein „Goto“ kommentiert, damit kann man den IPS-Absturz zu- und abschalten ;-))) (Spätestens beim 5.Versuch)
Wenn Du das nicht bei euch nachstellen kannst - spring ich aus dem Fenster …
<?
// GA ausfuehren fuer alle Variablen im Ordner
//
//
//
$Par_ID=IPS_GetParent($_IPS['SELF']);
//
//Auslesen I2C Bus und Umrechnung
$dezzahl= 123; //hexdec( shell_exec("i2cget -y 1 $I2C_Adresse"));
//echo "
Dezzahl $dezzahl";
$i2c_arr=array();
if ($dezzahl>=128) $i2c_arr[7] =1; else $i2c_arr[7] =0;
if ($dezzahl%128>=64) $i2c_arr[6] =1; else $i2c_arr[6] =0;
if ($dezzahl%64>=32) $i2c_arr[5] =1; else $i2c_arr[5] =0;
if ($dezzahl%32>=16) $i2c_arr[4] =1; else $i2c_arr[4] =0;
if ($dezzahl%16>=8) $i2c_arr[3] =1; else $i2c_arr[3] =0;
if ($dezzahl%8>=4) $i2c_arr[2] =1; else $i2c_arr[2] =0;
if ($dezzahl%4>=2) $i2c_arr[1] =1; else $i2c_arr[1] =0;
if ($dezzahl%2>=1) $i2c_arr[0] =1; else $i2c_arr[0] =0;
//
//
$variablen_array=IPS_GetChildrenIDs($Par_ID);
$var_ids = array();
foreach ($variablen_array as $value) //durchsucht alle Objekte unter PAR_ID
{
$var_object_type=IPS_GetObject($value);
$ObjTyp=$var_object_type['ObjectType'];
$Name=IPS_GetName($value);
// Ermittlung Variable
If ($ObjTyp==2) { //Pruefung ob Objekt Variable
//echo $Name;
$Variable=IPS_GetVariable ($value);
$ObjInfo=$var_object_type['ObjectInfo'];
$Nummer= (int) substr($ObjInfo, -2);
$wert=$i2c_arr[$Nummer];
if ($wert==0) $wert=false;
else $wert=true;
//echo "
$ObjInfo $Nummer $wert";
If (GetValueBoolean($value)==$wert) SetValueBoolean($value,!$wert);
}
}
//IPS_Sleep(1000);
//Variablen übertragen
$variablen_array=IPS_GetChildrenIDs($Par_ID);
$var_ids = array();
foreach ($variablen_array as $value) //durchsucht alle Objekte unter PAR_ID
{
$var_object_type=IPS_GetObject($value);
$ObjTyp=$var_object_type['ObjectType'];
$Name=IPS_GetName($value);
// Ermittlung Variable
If ($ObjTyp==2) { //Prüfung ob Objekt Variable
$Variable=IPS_GetVariable ($value);
$ObjID=$var_object_type['ObjectID'];
//echo "Object $ObjID
";
$ScriptID=IPS_GetScriptIDByName("uebertragen",$ObjID);
//Goto Ende_Script; //folgende Zeilen führen auf einem RASPI PI2 zum Absturz von IPS, auf dem PI1 nicht
//eindeutig reproduzierbar - spätestens beim 5. Ausführen des Scripts
if (IPS_ScriptExists($ScriptID)) {
IPS_RunScript($ScriptID);
//echo "Script=$ScriptID gestartet
";
}
}
}
Ende_Script:
?>
[b]Hi Paresy,
vielen DANK - scheinbar war es dies in 350c1269.[/b]
Es scheint noch einen anderen Fehler zu geben - der mit dem Script ist bei mir scheinbar weg …
Schönen SONNTAG
herbertf