Hi Adi,
ja, werde ich mal testen. Problem machte ja nicht der SvxReflektor (den habe ich gar nicht konfiguriert/gestartet) sondern bereits das nackte SvxLink. Ohne Reflektor-Anbindung.
Ich würde dann direkt die aktuelle Version nehmen (git clone https://github.com/sm0svx/svxlink/) und anschließend kompilieren/installieren ...
Wäre das so der richtige Weg?
Schönen Gruß
Frank, DL3DCW
Ja, Du hast Recht, der Reflector ist nicht das Problem.
Das o.g. ist auch das richtige Vorgehen, ABER: die Version ist wieder um eine Minor-Nummer nach oben gerutscht und damit mußt Du sowohl den Reflector als auch die Clients auf einem Stand haben.
Falls Du eine Station mit Internet-Zugriff hast und aus verständlichen Gründen nicht alles gleichzeitig umbauen möchtest, kann ich Dir auch Zugangsdaten für einen unserer Server geben.
vy 73s de Adi / DL1HRC
Es reicht ja wenn erst mal die aktuelle SvxLink-Version sauber läuft. Denn das hat bisher bei mir immer zu Problemen geführt. Ich werde berichten ... 
Hmm, irgendetwas mache ich falsch. Immer nach dem zweiten EchoLink-Durchgang der entfernten Station bekomme ich die bekannte Fehlermeldung mit anschließendem Komplettabsturz von SvxLink (absolut reproduzierbar):
svxlink: /home/sysop/svxlink/src/async/core/AsyncTimer.cpp:150: void Async::Timer::setEnable(bool): Assertion `(m_timeout_ms >= 0) 
!do_enable' failed.
Ich habe die aktuelle Version so installiert:
git clone https://github.com/sm0svx/svxlink/
cd svxlink/src
mkdir build
cd build
sudo cmake -DUSE_QT=OFF -DCMAKE_INSTALL_PREFIX=/usr -DSYSCONF_INSTALL_DIR=/etc -DLOCAL_STATE_DIR=/var -DCMAKE_BUILD_TYPE=Release ..
sudo make install
Dann nur noch die Prozedur "is_receiving" in der lokalen EchoLink.tcl um den zusätzlichen Parameter (call) ergänzt. Ich stehe auf dem Schlauch ...
....kann ich da mal drauf?
vy 73s de Adi / DL1HRC
Gerne. Via Internet aber leider erst heute Abend. Im Moment ist das System nur via HAMNET per SSH von außen erreichbar ...
Ist bisher bei allen unserer Systeme so gewesen die ich getestet habe. Überall das gleiche Problem. Und das sind eigentlich keine aufwändigen Konfigurationen. Lediglich Simplex- und Repeater-Systeme mit SvxServer-Anbindung. Letztere habe ich zum Test auch mal herausgenommen. Aber immer noch das gleiche Problem ...
Ist auch unabhängig vom EchoLink-Client: Passiert sowohl mit dem Windows-Programm als auch via Smartphone (iOS).
Ahhh, bin dem auf der Spur: Das scheint etwas mit den Rechten zu tun zu haben!!!
Starte ich svxlink mit "sudo svxlink" bekomme ich die Abstürze. Starte ich mit "svxlink" läuft es bisher stabil ...
Vermutlich ist irgendwo etwas verbogen. Hast Du eine Idee?
ok, wie gesagt, ich konnte das hier jetzt nicht mehr forcieren. Machen wir so, bin heute Abend noch bei den blauen Würmchen, wird wohl erst so gegen 22Uhr werden. Wenn Du mir einfach die Zugangsdaten zusendest?
vy 73s de Adi / DL1HRC
Ok, es scheint nun endlich behoben zu sein! Problem war wohl, dass SvxLink durch das Startscript (/etc/init.d/svxlink) automatisch als "root" ausgeführt wurde. Das hat bisher auch nie Probleme gemacht. Nur bei den neueren SvxLink-Versionen (ab 1.5.) trat dann immer wieder und völlig verlässlich der oben beschriebene Fehler auf. Immer nach dem zweiten EchoLink-Durchgang.
Ich habe die entsprechende Zeile im Startscript von
svxlink --daemon
jetzt auf
sudo -u sysop svxlink --daemon
abgeändert. Nun läuft SvxLink als user "sysop", also dem Standarduser des HAMServerPi. Damit scheint es keine Abstürze mehr zu geben.
Wie soll man darauf auch kommen. SvxLink ist wirklich nur was für Profis. Ich hole nun besser wieder meine alte WX-Steuerung 'raus (duck-und-wech)
Danke!!!
Nachtrag: Der Absturz nach dem zweiten EchoLink-Durchgang tritt auf jeden Fall immer bei den Simplex-Stationen auf (wenn svxlink als root läuft) ...