Nach einem System-Neustart ergibt „sudo ps x < grep symcon“ keine Rückmeldung.
Spricht der symcon Dienst läuft nicht.
Nach Eingabe von „sudo /etc/init.d/symcon start“ kommt die Rückmeldung " IP-Symcon started with PID 2720"
Danach kann ich bis zum nächsten Systemstart per Konsole und Browser auf symcon zugreifen.
Wie bekomme ich einen automatischen Start des symcon Dienstes hin?
Das „sudo update-rc.d symcon defaults“ hatte ich schon versucht.
Ein erneuter Stop des Autostarts und erneutes Aktivieren nach Deinen Vorgaben hat auch nichts bewirkt.
Nach dem Neustart des Rechners ergab „sudo ps x | grep symcon“ keine Rückmeldung.
Erst nach „sudo /etc/init.d/symcon start“ läuft der Dienst wieder.
Was gibt es noch für Möglichkeiten?
Sorry für die Fragen, ich bin erst seit einiger Zeit bei LinuxMint als Betriebssystem angekommen.
Selbst wenn ich die Scripte in rc0.d - rc6.d manuell starte funktioniert das nicht.
Ich habe das Gefühl es liegt an den Rechten.
Ich habe einen Autologon als user. Bei Eingabe von sudo wird auch mein Passwort akzeptiert.
Bin aber wohl doch nicht berechtigt die Startbefehle auszuführen.
Was nun?
Funktioniert es nur mit einer Ubuntu-Serverversion?
Normal ist ja der User Root nicht zum einloggen freigegeben.
Oder ist das etwa eine Eigenheit von LinuxMint?
Starte mal neu und schau die die Systemlogs an (syslog, boot.log, etc.). Vielleicht findest du dort einen Hinweis auf dein Problem. Ein Rechteproblem könnte es schon sein. Ich kenne mich allerdings nicht mit den Spezifikas von Linux Mint aus.
Fakt ist, der init script erfordert, dass der script mit dem root Benutzer (UID 0) gestartet wird.
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
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
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:
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.
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
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.
(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)
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?