Fehlermeldung unter Linux

[huaba]

Hallo Leute,

ich wollte nach dem ich FE auf Windows fehlerfrei getestet hab, das ganze auf Linux umstellen.
OS ist Ubuntu Server 12.04 mit Oracle Java und als graphische Oberfläche momentan KDE.
Den Server kann ich problemlos starten, aber dann scheitert es, egal ob Server-GUI oder Client.

Fehlermeldung wie folgt:
user@ubuntu-test:~/firEmergency$ sh start.sh server-gui
24.09.2013 - 16:35:05.912 INFO Starter - Starte...
24.09.2013 - 16:35:05.928 INFO Starter - ---------------------------------
24.09.2013 - 16:35:05.933 INFO Starter - |Version: 1.5.4 |
24.09.2013 - 16:35:05.934 INFO Starter - |Status: release |
24.09.2013 - 16:35:05.936 INFO Starter - |Starte: Server-GUI |
24.09.2013 - 16:35:05.936 INFO Starter - ---------------------------------
24.09.2013 - 16:35:05.938 INFO GUIStartRMI - ServerGUI wird gestarten...
24.09.2013 - 16:35:05.941 INFO GUIStartRMI - Starte LoginScreen...
24.09.2013 - 16:35:14.026 INFO LoginController - Baue Verbindung auf: EMNOSServer
24.09.2013 - 16:35:14.027 INFO LoginController - Starte SSL Verbindung
24.09.2013 - 16:35:14.399 INFO LoginController - Verbindung erfolgreich hergestellt
24.09.2013 - 16:35:14.653 INFO LoginController - Login erfolgreich
24.09.2013 - 16:35:15.147 ERROR LoginController - Fehler beim Verbindungaufbau
java.lang.UnsupportedOperationException: Desktop API is not supported on the current platform
at org.jdesktop.swingx.hyperlink.HyperlinkAction.<init>(HyperlinkAction.java:131) ~[firEmergency.jar:na]
at org.jdesktop.swingx.hyperlink.HyperlinkAction.crea teHyperlinkAction(HyperlinkAction.java:78) ~[firEmergency.jar:na]
at org.jdesktop.swingx.hyperlink.HyperlinkAction.crea teHyperlinkAction(HyperlinkAction.java:62) ~[firEmergency.jar:na]
at org.jdesktop.swingx.JXHyperlink.setURI(JXHyperlink .java:147) ~[firEmergency.jar:na]
at server.gui.user.GUser.createImportPanel(GUser.java :273) ~[firEmergency.jar:na]
at server.gui.user.GUser.<init>(GUser.java:137) ~[firEmergency.jar:na]
at server.gui.MainFrame.<init>(MainFrame.java:98) ~[firEmergency.jar:na]
at server.gui.login.LoginController$LoginWorker.doInB ackground(LoginController.java:238) [firEmergency.jar:na]
at server.gui.login.LoginController$LoginWorker.doInB ackground(LoginController.java:1) [firEmergency.jar:na]
at javax.swing.SwingWorker$1.call(SwingWorker.java:29 6) [na:1.7.0_40]
at java.util.concurrent.FutureTask.run(FutureTask.jav a:262) [na:1.7.0_40]
at javax.swing.SwingWorker.run(SwingWorker.java:335) [na:1.7.0_40]
at java.util.concurrent.ThreadPoolExecutor.runWorker( ThreadPoolExecutor.java:1145) [na:1.7.0_40]
at java.util.concurrent.ThreadPoolExecutor$Worker.run (ThreadPoolExecutor.java:615) [na:1.7.0_40]
at java.lang.Thread.run(Thread.java:724) [na:1.7.0_40]

Woran liegt das?
Egal welche GUI ic installiere, kommt der Fehler.
Hängt das mit der Server-Version von Ubuntu zusammen?

huaba

[firEmergency]

Wir verwenden eine API von Java, welche folgendes benötigt:
On the Solaris Operating System and the Linux platform, this API is dependent on Gnome libraries.

Kannst du auf Gnome umsteigen? Wir hatten es mit der Unity Shell von Ubuntu damals getestet, welche ja glaube ich auf Gnome aufbaut (?).

[Jockel91]

Hi,
ich habe den Fehler auch auf meinem PI.

@firEmergency weches OS und welche Software hatte ihr den sonst noch auf dem PI aus dem was im Blog steht?

@huaba versuchst du es lokal auf dem Server zu starten oder via X-Server?


Gruß Jockel

[Jockel91]

aptitude install gnome (debian) hat bei mir das Problem gelöst.

Jedoch geht die Anmeldung immer noch nicht.
Von meinem Windows Server bekomme ich direkt nach der Anmeldemaske den Fehler (
2013-10-01 14_11_55.jpg) falsche Anmeldedaten.

Via X-Server bekomme ich die Anmeldung aber der Client bleibt bei loading hängen.
Log Einträge via X-Server connect:
Server:
01.10.2013 - 14:11:14.193 INFO Launcher - ################################
01.10.2013 - 14:11:14.208 INFO Launcher - firEmergency einsatzbereit
01.10.2013 - 14:11:14.234 INFO Launcher - ################################
01.10.2013 - 14:13:41.048 INFO RemoteGUIServer - Benutzer 'Admin' wurde gelockt, um Mehrfachzugriff zu vermeiden
01.10.2013 - 14:13:41.057 INFO RemoteGUIServer - Benutzer 'Admin' hat sich mit vollen Rechten angemeldet
01.10.2013 - 14:15:01.329 INFO FeedbackController - Lade Feedback-Zuweisungen...
01.10.2013 - 14:15:09.318 INFO TextReplacer - 1 globale Ersetzungsregeln geladen



Client
root@raspberrypi:/var/firEmergency# ./start.sh server-gui
01.10.2013 - 14:11:18.304 INFO Starter - Starte...
01.10.2013 - 14:11:18.435 INFO Starter - ---------------------------------
01.10.2013 - 14:11:18.475 INFO Starter - |Version: 1.5.4 |
01.10.2013 - 14:11:18.487 INFO Starter - |Status: release |
01.10.2013 - 14:11:18.496 INFO Starter - |Starte: Server-GUI |
01.10.2013 - 14:11:18.504 INFO Starter - ---------------------------------
01.10.2013 - 14:11:18.516 INFO GUIStartRMI - ServerGUI wird gestarten...
01.10.2013 - 14:11:18.599 INFO GUIStartRMI - Starte LoginScreen...
01.10.2013 - 14:13:35.465 INFO LoginController - Baue Verbindung auf: EMNOSServer
01.10.2013 - 14:13:35.481 INFO LoginController - Starte SSL Verbindung
01.10.2013 - 14:13:38.968 INFO LoginController - Verbindung erfolgreich hergestellt
01.10.2013 - 14:13:41.078 INFO LoginController - Login erfolgreich

und jetzt ?! ;)
Danke Gruß
Jockel

[firEmergency]

Also ich hatte Raspian mit Oracle Java installiert. Ich hatte aber glaub damals nur den Server gestartet. GUI weiß ich nicht mehr.
Bei Raspian gibt's aber verschiedene Versionen, wovon nur eine ging.

Gesendet via Mobile App

[Jockel91]

Also Server läuft jetzt ...


Die GUI kann ich via X11 starten dauert nur etwa 10 min bis die gelanden ist.
Login vom Windows ist nicht möglich. (schreibt der Client logs? Dann könnte wir man zusammen schauen was da nicht geht)

Desweitern habe ich festgestellt, dass in dem firEmergency Folder
logs\log.txt und logs\log.html gibt. Scheint noch ein Fehler aus der Windows Portierung zu sein?!


Gruß Jockel

[limberu]

Also Server läuft jetzt ...


Die GUI kann ich via X11 starten dauert nur etwa 10 min bis die gelanden ist.
Login vom Windows ist nicht möglich. (schreibt der Client logs? Dann könnte wir man zusammen schauen was da nicht geht)

Desweitern habe ich festgestellt, dass in dem firEmergency Folder
logs\log.txt und logs\log.html gibt. Scheint noch ein Fehler aus der Windows Portierung zu sein?!


Gruß Jockel
File.pathSeparator :-p

[firEmergency]

Also Server läuft jetzt ...


Die GUI kann ich via X11 starten dauert nur etwa 10 min bis die gelanden ist.
Login vom Windows ist nicht möglich. (schreibt der Client logs? Dann könnte wir man zusammen schauen was da nicht geht)

Desweitern habe ich festgestellt, dass in dem firEmergency Folder
logs\log.txt und logs\log.html gibt. Scheint noch ein Fehler aus der Windows Portierung zu sein?!


Gruß Jockel

Also beide schreiben logs. Sowohl server, als auch Client.
Welches OS nutzt du nun?
Den Pfad der Logs kannst du in der files/Logback.xml ändern. Müsste ja reichen den Backslash hinzuzufügen.

Gesendet via Mobile App

[Jockel91]

ahh cool - also das mit den Logs habe ich geändert bekommen... (macht das nicht evtl Sinn das im Linux code anzupassen?)


raspberrypi:
PRETTY_NAME="Raspbian GNU/Linux 7 (wheezy)"
NAME="Raspbian GNU/Linux"
VERSION_ID="7"
VERSION="7 (wheezy)"

[firEmergency]

ahh cool - also das mit den Logs habe ich geändert bekommen... (macht das nicht evtl Sinn das im Linux code anzupassen?)


Hast natürlich Recht. Wird angepasst.

[Jockel91]

cool ich habe mit optimiert ;)

bleibt als das Problem, dass ich mich nicht vom Windows Client anmelden kann und das die Anmeldung via x11 sehr lange dauert...

Gruß Jockel

[Jockel91]

und noch ein kritisches Problem gefunden !!!

ich starte den Server via ssh per


nohup ./start.sh server &


dadurch wird die Ausgabe umgeleitet und der prozess im hintergrund gestartet.

Nun musste ich Grade feststellen, dass wenn ich die ssh-session schließe die den Prozess gestartet hat - wird der Server auch beendend!
DAS IST UNCOOL!

Update: Problem ist auch das wenn die .jar file starte


nohup java -jar bin/firEmergency.jar server&

[firEmergency]

Dafür gibt es ja "screen".
http://www.tutorials.de/content/1189-unix-einfuehrung-screen.html

[Jockel91]

mhh - aber mit "screen" habe ich das gleiche Problem ...

ich wähle mit per ssh auf meiner server - start "screen" - Wechsel nach /var/firEmergency/ - starte den Server - und verlasse mit strg+a +d die session - wenn den die ssh session zu machen und mich wieder am server anmelde ist der Dienst weg ...

[firEmergency]

Das kann ich so nicht bestätigen.
Wir lassen FE auf einem V-Server schon so seit Monaten laufen.
Das ist dann ein Linux-Problem und hat so mit FE erstmal nichts zu tun.

[Jockel91]

mhh, habe das jetzt auf dem PI getestet und auf meinem Debian System gleich phänomen.
meldet ich euch dirkt auf dem Server an oder per ssh?

und wie starte ihr den Server?

Gruß
Jockel

[firEmergency]

- Putty SSH
- screen starten
- fe in screen session starten
- detachen
- exit

Wenn jetzt ssh nochmal startest, solltest du die screen session in htop sehen. Mit dieser solltest du dich auch wieder verbinden können

Gesendet via Mobile App

[Jockel91]

soo - ich habe gefunden warum die den service aus macht ...

er startet ein für mich nicht sichbares Fenster per X11 - wenn ich nur die SSH connections zumachen ist auch X11 weg und der Server auch. Wenn ich auf dem Client von dem ich aus starte Xming nicht aktiv habe bekomme ich folgenden Fehler:



root@srv-10-deb:/var/firEmergency# ./start.sh server
Exception in thread "main" java.lang.InternalError: Can't connect to X11 window server using 'localhost:11.0' as the value of the DISPLAY variable.
at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
at sun.awt.X11GraphicsEnvironment.access$200(X11Graph icsEnvironment.java:65)
at sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEn vironment.java:110)
at java.security.AccessController.doPrivileged(Native Method)
at sun.awt.X11GraphicsEnvironment.<clinit>(X11GraphicsEnvironment.java:74)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:190)
at java.awt.GraphicsEnvironment.createGE(GraphicsEnvi ronment.java:102)
at java.awt.GraphicsEnvironment.getLocalGraphicsEnvir onment(GraphicsEnvironment.java:81)
at sun.awt.X11.XToolkit.<clinit>(XToolkit.java:119)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:190)
at java.awt.Toolkit$2.run(Toolkit.java:868)
at java.security.AccessController.doPrivileged(Native Method)
at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:86 0)
at javax.swing.UIManager.getSystemLookAndFeelClassNam e(UIManager.java:608)
at starter.Starter.main(Starter.java:49)
root@srv-10-deb:/var/firEmergency#


Was kann / muss ich jetzt machen?
Bzw was mache ich falsch?

Danke und Gruß
Jockel

[firEmergency]

Hmm, ich bin jetzt nicht der Linux-Profi um mich da genügend auszukennen.
Das Problem dass er screen abschießt würde ja auch passieren, wenn du in screen ein anderes Programm starten würdest.
Anscheinend gibt es in FE momentan ein paar Funktionen, die X11 benötigen (auch wenn der Server so gesehen keine GUI hat, greifen wir doch auf ein paar Funktionen momentan zu).
Das müssten wir dann erst noch in FE ändern und alle Stellen finden.

Aber prinzipiell ist das immer noch auch ein Linux Problem. Denn wie gesagt auf unserem Strato V-Server läuft das weiterhin optimal.

[Jockel91]

Das mit euer server ist spannend. Welches OS und welche Version von FE habt ihr da am laufen?

Das mit screen ist ja klar - der greift auch per X11 drauf zu. Und wenn ich den Tunnel zu mache - tja ist die Verbindung zu Xming weg ;)

Habe das Problem jetzt erstmal lösen können ... Ich gehe über VNC auf den Server und starte ihn dann so. Nicht schön aber es geht ...

Wann plant ihr den die Änderungen am FE zumachen und könnt Ihr mich dann informieren?

Danke und Gruß
Jockel

[firEmergency]

Der normale V-Server von Strato:

Debian GNU/Linux 6.0

Linux XXX 2.6.32-042stab078.27 #1 SMP Mon Jul 1 20:48:07 MSK 2013 i686 GNU/Linux

Wenn wir Änderungen an FE vollzogen haben, geben wir hier im Thread bescheid.

[Jockel91]

Mhh - ich habe überalle schon den Debian 7 drauf ... sollte ja aber auch keinen Unterschied machen.

Danke für eure Hilfe.

Gruß Jockel

[Jockel91]

ok, und was ist mit dem Problem von Windwos Client zum Server?


hier das Log vom Client


05.10.2013 - 16:56:33.115 INFO Starter - Starte...
05.10.2013 - 16:56:33.131 INFO Starter - ---------------------------------
05.10.2013 - 16:56:33.135 INFO Starter - |Version: 1.5.1 |
05.10.2013 - 16:56:33.158 INFO Starter - |Status: release |
05.10.2013 - 16:56:33.159 INFO Starter - |Starte: Server-GUI |
05.10.2013 - 16:56:33.159 INFO Starter - ---------------------------------
05.10.2013 - 16:56:33.160 INFO GUIStartRMI - ServerGUI wird gestarten...
05.10.2013 - 16:56:33.169 INFO GUIStartRMI - Starte LoginScreen...
05.10.2013 - 16:56:46.672 INFO LoginController - Baue Verbindung auf: EMNOSServer
05.10.2013 - 16:56:46.672 INFO LoginController - Starte SSL Verbindung
05.10.2013 - 16:56:50.835 ERROR LoginController - Fehler beim Verbindungaufbau
java.rmi.ConnectException: Connection refused to host: 127.0.1.1; nested exception is:
java.net.ConnectException: Connection refused: connect
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(Unknow n Source) ~[na:1.7.0_40]
at sun.rmi.transport.tcp.TCPChannel.createConnection( Unknown Source) ~[na:1.7.0_40]
at sun.rmi.transport.tcp.TCPChannel.newConnection(Unk nown Source) ~[na:1.7.0_40]
at sun.rmi.server.UnicastRef.invoke(Unknown Source) ~[na:1.7.0_40]
at java.rmi.server.RemoteObjectInvocationHandler.invo keRemoteMethod(Unknown Source) ~[na:1.7.0_40]
at java.rmi.server.RemoteObjectInvocationHandler.invo ke(Unknown Source) ~[na:1.7.0_40]
at com.sun.proxy.$Proxy4.getLicenseTyp(Unknown Source) ~[na:na]
at server.gui.login.LoginController$LoginWorker.doInB ackground(LoginController.java:205) [firEmergency.jar:na]
at server.gui.login.LoginController$LoginWorker.doInB ackground(LoginController.java:1) [firEmergency.jar:na]
at javax.swing.SwingWorker$1.call(Unknown Source) [na:1.7.0_40]
at java.util.concurrent.FutureTask.run(Unknown Source) [na:1.7.0_40]
at javax.swing.SwingWorker.run(Unknown Source) [na:1.7.0_40]
at java.util.concurrent.ThreadPoolExecutor.runWorker( Unknown Source) [na:1.7.0_40]
at java.util.concurrent.ThreadPoolExecutor$Worker.run (Unknown Source) [na:1.7.0_40]
at java.lang.Thread.run(Unknown Source) [na:1.7.0_40]
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.DualStackPlainSocketImpl.connect0(Native Method) ~[na:1.7.0_40]
at java.net.DualStackPlainSocketImpl.socketConnect(Un known Source) ~[na:1.7.0_40]
at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source) ~[na:1.7.0_40]
at java.net.AbstractPlainSocketImpl.connectToAddress( Unknown Source) ~[na:1.7.0_40]
at java.net.AbstractPlainSocketImpl.connect(Unknown Source) ~[na:1.7.0_40]
at java.net.PlainSocketImpl.connect(Unknown Source) ~[na:1.7.0_40]
at java.net.SocksSocketImpl.connect(Unknown Source) ~[na:1.7.0_40]
at java.net.Socket.connect(Unknown Source) ~[na:1.7.0_40]
at sun.security.ssl.SSLSocketImpl.connect(Unknown Source) ~[na:1.7.0_40]
at sun.security.ssl.SSLSocketImpl.<init>(Unknown Source) ~[na:1.7.0_40]
at sun.security.ssl.SSLSocketFactoryImpl.createSocket (Unknown Source) ~[na:1.7.0_40]
at server.gui.rmi.ssl.RMISSLClientSocketFactory.creat eSocket(RMISSLClientSocketFactory.java:54) ~[firEmergency.jar:na]
... 15 common frames omitted




Im Serverlog kein Eintrag habe es auch von mehrern Clients versucht ...
Kein Firewall aktiv und Verbindung per Telnet geht durch

Idea?

Jockel

[limberu]

Connection refused to host: 127.0.1.1;

127.0.1.1 ist keine gültige ip, soweit ich mich richtig erinner

[firEmergency]

Nachtrag:

Nachdem nun mein neuer PI da ist (B Modell), hab ich alles nochmal getestet. Ich musste tatsächlich FE an der ein und anderen Stelle anpassen.

Nun läuft aber alles (siehe Screen).

Habe Raspian Soft Float installiert mit Java 7 von Oracle (war schon vorinstalliert). Angeblich läuft Debian + Hard-Float + Java 8 noch einiges besser. Habe ich aber nicht getestet.

Zur Performance:
Hatte per RDP Zugriff auf den PI. Die ganze Bedienung läuft schon sehr zäh. Kann aber auch an RDP liegen.

[Jockel91]

Moin, welche Probleme konntest du den alles nachstellen?
Dann kann ich dort aufhören den Fehler bei mir zu suchen.


Gruß Jockel

[firEmergency]

Den vom ersten Post. Mit der Desktop-API.
Als nativ auf dem PI läuft es wie gesagt. Obs via X11 Tunneling oder sonst welchen Techniken auch geht kann ich noch nicht sagen. Am besten dann mit der kommenden Beta ausprobieren.

[maddin11477]

Hi,
hast du die Anpassungen in der Beta vorgenommen?
Die Version 1.5.4 läuft auf dem PI leider nicht. Kommt immernoch der Fehler, dass die GUI nicht unterstützt wird.

[firEmergency]

Die aktuelle Beta (1.6.1) läuft.
Habs auf dem Pi getestet.

[maddin11477]

Hm okay dann muss ich wohl auf den Release warten, danke