Hallo zusammen,

als Linux Neuling habe ich folgendes Problem:

Ich möchte auf einem Debian Server ein Java Programm als Dienst laufen lassen - also rund-um-die-uhr.

Könntetn Ihr mir bitte helfen, wie ich das per SSH regel?

Vielen Dank im Voraus!

Marcel

Generell unterscheidet Linux ersteinmal nicht zwischen Deamon- und anderen Prozessen, von daher kannst Du Dein Programm über die rc-Scripte beim Start laden lassen. Wichtig ist nur, daß /keine/ direkte Userinteraktion über das Terminal notwendig ist.

Fraglich ist in meinen Augen ob ein Daemon bzw. Dienst in Java geschrieben werden sollte, nicht jede Maschine hat Java installiert und Java an sich ist im Vergleich zu C auch sehr viel träger, langsamer und ressourcenhungriger.

Danke für deine Antwort!
Ja - zugegebener maßen - Java ist nicht gerade Ressourcenfreundlich.

Was ich aber genau suche ist ein Befehl, mit dem eine via SSH gestartetes Kommando auch nach dem die Shel geschlossen ist, weiterläuft.

Gruß Marcel

Hallo,

Zitat von marcel_m

Was ich aber genau suche ist ein Befehl, mit dem eine via SSH gestartetes Kommando auch nach dem die Shel geschlossen ist, weiterläuft.

Gruß Marcel

versuchs doch mal mit nohup. Siehe

Code :

1

man nohup

Gruß,
RedWing

Zitat von Navy

Java an sich ist im Vergleich zu C auch sehr viel träger, langsamer

Da muss ich dich leider korregieren.
Das war mal so. Das hat sich aber schon lange geändert. Das was halt auch mehr an Speicherverbrauch da ist, ist die VM. Die braucht halt Speicher.

MFG

Sascha

> Da muss ich dich leider korregieren.

Ich Dich auch. Es heißt "korrigieren". [SCNR]

> Das war mal so. Das hat sich aber schon lange geändert. Das was halt auch mehr an
> Speicherverbrauch da ist, ist die VM. Die braucht halt Speicher.

Java ist im Vergleich zu [C|C++] bis zu 10 mal langsamer, da Java meistens nur im Bytecode vorliegt und noch von der VM interpretiert werden muß während äquivalente Programme "direkt" auf der Maschine laufen.

Es ist auch egal warum Java mehr Ressourcen verbraucht, Fakt ist allein der Umstand, dass es das tut. Das ist auch der Grund, warum unter Linux nur sehr wenige (ich kenne im Grunde überhaupt keines) Systemprogramme in Java geschrieben werden. Macht ja auch keinen Sinn, da Java nicht hardwarenah läuft und für ganz andere Zwecke konzeptioniert worden ist. Das heißt aber nicht, daß sowas nicht möglich wäre...

Hi,

Da muss ich dich leider korregieren

ich schließe mich an:

da Java meistens nur im Bytecode vorliegt und noch von der VM interpretiert werden muß

Das ist nicht nur meistens so, sondern immer.

Von einer interpretierten Programmiersprache ist Java allerdings auch ziemlich weit entfernt. Der Sourcecode wird ja durchaus in eine Art von Maschinencode kompiliert, der lediglich auf einer virtuellen CPU (in Form der VM) ausgeführt wird.

Und weil Java bis zu 10 Mal langsamer ist als C oder C++ und nicht als Daemon laufen sollte, wird es auch überhaupt nicht im Webserver-Bereich eingesetzt.

*scnr*, D.

Da irrst du dich leider. Auch wenn es ByteCode ist. Schon mal was vom Just in Time-Compiler gehört?

Hier mal die allgemeine Definition
http://de.wikipedia.org/wiki/JIT-Compiler

Java ist in den meisten Operationen schneller als C/C++. Es gibt kaum was bei dem Java noch langsamer ist.

Kannst du mir glauben. Bin nicht umsonst seit 3 Jahren Java-Entwickler. Tom wird die das auch bestätigen.

Auch, wenn die VM läuft, in größeren Anwendungen ist das nebensächlich. Wenn man natürlich eine sehr kleine Anwendung schreiben möchte, die kaum Speicher verbraucht, dann ist das natürlich schlecht. Da gebe ich dir recht.

Ich habe ja nicht gesagt, dass es richtig wäre einen Dienst in Java zu schreiben. Wollte nur mal den allgemeinen Irrtum korrigieren.

MFG

Sascha

Zitat von Dario Linksy

Und weil Java bis zu 10 Mal langsamer ist als C oder C++ und nicht als Daemon laufen sollte, wird es auch überhaupt nicht im Webserver-Bereich eingesetzt.

Ich weiß ja nicht, ob das von dir ironisch gemeint ist, aber für den Fall das nicht, hier mal ein kleines Beispiel.
http://de.wikipedia.org/wiki/Apache_Tomcat


MFG

Sascha

Ich weiß ja nicht, ob das von dir ironisch gemeint ist

Ist es. Hätte ich vielleicht dazu schreiben sollen.

Grüße, D.

Ich wusste es jetzt nicht. Teilweise hat es ausgesehen als würdest du zustimmen, teilweise aber auch als wäre es ironisch gemeint.

MFG

Sascha

> Das ist nicht nur meistens so, sondern immer.

Nanana... ich kann das auch im Quelltext ausliefern und trotzdem laufen lassen.

> Von einer interpretierten Programmiersprache ist Java allerdings auch ziemlich weit
> entfernt. Der Sourcecode wird ja durchaus in eine Art von Maschinencode kompiliert, der
> lediglich auf einer virtuellen CPU (in Form der VM) ausgeführt wird.

Ich verwendete das Wort "interpretiert" mit Bedacht. Die VM ist keine echte Maschiene und läuft "nur" auf dem OS, muss also die Befehle des Bytecodes noch in Systembefehle bzw direkte Maschinenbefehle umsetzen. Von daher kann es nicht schneller als nativer Maschinencode sein -- sofern letzterer ebenso effizient programmiert ist.

> Und weil Java bis zu 10 Mal langsamer ist als C oder C++ und nicht als Daemon laufen
> sollte, wird es auch überhaupt nicht im Webserver-Bereich eingesetzt.

Java wird im Webserverbereich eingesetzt weil es ersteinmal eine relativ einfache Sprache ist und sie auch auf andere Systeme portierbar ist. Es ging nie um echte Effizienz, denn sonst würde Java nicht mit PHP oder anderen Sprachen in diesem Bereich konkurrieren.

> Da irrst du dich leider. Auch wenn es ByteCode ist. Schon mal was vom Just in
> Time-Compiler gehört?

s.o.

> Java ist in den meisten Operationen schneller als C/C++. Es gibt kaum was bei dem
> Java noch langsamer ist.

Dann zeig mir mal bitte einen objektiven Vergleich. Ich will jetzt keinen Streit anfangen, aber in allen bisherigen Artikeln die einen vermeintlichen Geschwindigkeitsvorteil von Java gegenüber C propagandiert haben wurde das entsprechende Programm in C nicht optimiert (so wurde auf Biegen und Brechen OOP verwendet um Datentypen zu schaffen anstatt sie mit schnellen und schlanken Zeigeroperationen zu implementieren)

> Kannst du mir glauben. Bin nicht umsonst seit 3 Jahren Java-Entwickler. Tom wird die
> das auch bestätigen.

Ich bin auch in der Entwicklung tätig und nutzte mehrere Sprachen. Ich mag Java ob seiner klaren Strukturen und der Übersichtlichkeit, bei Programmen die jedoch auf Performance ausgelegt sind, verwende ich lieber C.

> Auch, wenn die VM läuft, in größeren Anwendungen ist das nebensächlich. Wenn man
> natürlich eine sehr kleine Anwendung schreiben möchte, die kaum Speicher verbraucht,
> dann ist das natürlich schlecht. Da gebe ich dir recht.

Mhmm... ich habe noch kein großes Projekt gesehen welches performant laufen soll und in Java geschrieben ist. Keine Serveranwendungen, keine Datenbanken, keine Spiele und sontwas... und das wird wohl seinen Grund haben.

> Ich habe ja nicht gesagt, dass es richtig wäre einen Dienst in Java zu schreiben. Wollte > nur mal den allgemeinen Irrtum korrigieren.

Welchen meinst Du?

Hi,

ich kann das auch im Quelltext ausliefern und trotzdem laufen lassen.

ist mir neu. Allerdings hab ich auch eine ganze Weile nichts größeres mehr mit Java gemacht.

Ich verwendete das Wort "interpretiert" mit Bedacht. Die VM ist keine echte Maschiene und läuft "nur" auf dem OS, muss also die Befehle des Bytecodes noch in Systembefehle bzw direkte Maschinenbefehle umsetzen.

Ich war früher auch mal der Meinung, dass Java "interpretiert" wird und weiß, was du meinst. Aber nach einer Diskussion hat mich Chris damals eines besseren belehrt.

Java wird im Webserverbereich eingesetzt weil es ersteinmal eine relativ einfache Sprache ist und sie auch auf andere Systeme portierbar ist.

Das war ironisch gemeint. Ich weiß, dass es Tomcat, Struts, Servlets, Web Services, usw. gibt.

Es ging nie um echte Effizienz, denn sonst würde Java nicht mit PHP oder anderen Sprachen in diesem Bereich konkurrieren.

Java ist aber um Längen schneller als PHP, weil ein Servlet oder ein JSP nur beim ersten Aufruf kompiliert werden muss und danach eben direkt von der VM verarbeitet werden kann - wohingegen PHP tatsächlich bei jedem Aufruf zeilenweise interpretiert wird.

Ich bin auch in der Entwicklung tätig und nutzte mehrere Sprachen. Ich mag Java ob seiner klaren Strukturen und der Übersichtlichkeit, bei Programmen die jedoch auf Performance ausgelegt sind, verwende ich lieber C.

Natürlich kann Java-Bytecode niemals schneller sein als nativer Maschinencode, das ist richtig. Aber es hat sich in puncto Performance in den letzten Jahren doch einiges auf der Java-Seite getan. Und wenn es wirklich um zeitkritische Dinge geht, ist selbst C noch zu lahmarschig, weil jeder Compiler und Linker unnützes Zeug mit in den Maschinencode rein "optimiert". Dann lieber Assembler.

Mhmm... ich habe noch kein großes Projekt gesehen welches performant laufen soll und in Java geschrieben ist. Keine Serveranwendungen, keine Datenbanken, keine Spiele und sontwas...

Ich weiß nicht, wie umfangreich diese Dinge sind, weil ich den Sourcecode nicht kenne, aber... spontan fallen mir Webseiten wie die vom DENIC, von SUN und von Siemens ein. Auf der Desktop-Seite Eclipse (ja, wirklich ) und wenn mich nicht alles täuscht, ist OpenOffice.org auch in Java geschrieben. Davon kriegt man als Anwender natürlich nicht so viel von mit.

Grüße, D.

Den Irrtum das Java langsamer ist.

C/C++ wird meistens genommen wenn es um Performance geht. Wenn man richtig programmiert, kann man das meiste auch in Java machen.

Schau mal hier
http://www.tutorials.de/forum/coders...ndungen-3.html

Da gab es schon mal eine ähnliche Diskussion. Da hab ich einfach mal ein kleines Beispiel geschrieben. In C und in Java.

Wenn man natürlich die fertigen Klassen von Java verwendet (z.b. Vector) und das mit etwas selbstgeschriebenen in C vergleicht. Ist Java natürlich langsamer. Der Verwaltungsaufwand bei VEctor ist enorm, wenn man es mit etwas selbstgeschriebenen in C vergleicht. Schreibt man aber beides selbst, dann sieht das ganze schon anders aus.


MFG

Sascha

Zitat von Dario Linsky

Java ist aber um Längen schneller als PHP, weil ein Servlet oder ein JSP nur beim ersten Aufruf kompiliert werden muss und danach eben direkt von der VM verarbeitet werden kann - wohingegen PHP tatsächlich bei jedem Aufruf zeilenweise interpretiert wird.

Ich mische mich nicht in Eure Diskussion ein, nur eine kleine Erinnerung/ein Hinweis:

eAccelerator/Zend Optimizer
Diese Anwendungen Cachen den erzeugten Bytecode, so das nicht zwangsläufig jedes mal das Script komplett abgearbeitet werden muss.
Ohne so eine Technologie - da stimme ich zu - wird PHP wirklich zweilenweise interpretiert.