# Eigenes Java-Server-Programm unter Linux steuern?



## McFraggle (10. Aug 2007)

Hallo!
Ich habe ein Java-TCP/IP-Server.
Der soll unter Linux laufen.

Jetzt möchte ich ihn beim Starten in den Hintergrund gabeln und die Möglichkeit haben, ihn jederzeit stoppen oder neustarten zu können.
Im Grunde möchte ich sowas wie die Deamon-Steuerung unter Linux mit den init.d-Skripten.

Wie kann ich das möglichst elegant bewerkstelligen?

Danke für jede Anregung!


----------



## Kim Stebel (10. Aug 2007)

"startserver &" ruft startserver im hintergrund auf.
Dann mit "ps ax" die PID rausfinden und schließlich "kill PID"..


----------



## HoaX (11. Aug 2007)

oder da es ein server ist auf diesen  verbinden und ihm das kommande "beenden dich" schicken


----------



## NTB (11. Aug 2007)

oder einen zusätzlichen Steuerport implementieren, über den Du ihn stoppen kannst.


----------



## McFraggle (11. Aug 2007)

@HoaX, @NTB:
Hm, ja die Ansätze hatte ich auch, ich dachte nur, es gäbe vielleicht etwas Vorgedachtes in den Bibliotheken...

@Kim Stebel:
Wenn ich _startserver &_ in einer Shell aufrufe und dann die Shell beende, stirbt doch auch der startserver-prozess, oder nicht? Mit dem "&" forke ich einen Prozess doch nicht richtig in den Hintergrund (als vollwertigen deamon), oder liege ich da falsch?

Mit _kill PID_ wiederum töte ich einen Prozess doch unerbittlich, ohne ihm die Möglichkeit zu geben, sich sauber zu beenden, oder? Das wäre für einen Server-Prozess auch nicht unbedingt schön, der laufende Requests erst noch abhandeln soll und eventuell Semaphoren zurücksetzen muss und Ähnliches; oder liege ich da auch falsch? Kann ich das "kill" in einem Java-Programm quasi als Event abfangen und behandeln?


Danke schon mal an Euch drei!!!


----------



## Kim Stebel (11. Aug 2007)

> Wenn ich startserver & in einer Shell aufrufe und dann die Shell beende, stirbt doch auch der startserver-prozess, oder nicht? Mit dem "&" forke ich einen Prozess doch nicht richtig in den Hintergrund (als vollwertigen deamon), oder liege ich da falsch?


Da liegst du falsch. Probier es halt aus...wenn du die shell zumachst geht dann nur Standard-output ins nirvana, sofern nicht umgeleitet.



> Mit kill PID wiederum töte ich einen Prozess doch unerbittlich, ohne ihm die Möglichkeit zu geben, sich sauber zu beenden, oder? Das wäre für einen Server-Prozess auch nicht unbedingt schön, der laufende Requests erst noch abhandeln soll und eventuell Semaphoren zurücksetzen muss und Ähnliches; oder liege ich da auch falsch? Kann ich das "kill" in einem Java-Programm quasi als Event abfangen und behandeln?


Ja kannst du:

```
Runtime.getRuntime().addShutdownHook(new Thread() {
    public void run() { //aufräumen.... }
});
```

"Unerbittlich" tötest du nur mit kill -9


----------



## Kim Stebel (11. Aug 2007)

siehe auch:
http://java.sun.com/j2se/1.5.0/docs/guide/lang/hook-design.html
http://www.onjava.com/pub/a/onjava/2003/03/26/shutdownhook.html


----------



## Hilefoks (11. Aug 2007)

Kim Stebel hat gesagt.:
			
		

> > Wenn ich startserver & in einer Shell aufrufe und dann die Shell beende, stirbt doch auch der startserver-prozess, oder nicht? Mit dem "&" forke ich einen Prozess doch nicht richtig in den Hintergrund (als vollwertigen deamon), oder liege ich da falsch?
> 
> 
> Da liegst du falsch. Probier es halt aus...wenn du die shell zumachst geht dann nur Standard-output ins nirvana, sofern nicht umgeleitet.


Nein - er hat recht... "Probier es halt aus..." ;-)

Durch das & wird die Shell angewiesen den Prozess in einer Subshell zu starten... wird die Shell beendet, werden auch alle Kinder getötet. Um das zu verhindern kann man ein Programm aber mit nohup starten:
	
	
	
	





```
nohup programm &
```
Aber auch das ist nur ein Hack und kein echter Unix-Daemon. Es gibt aber den JSR 96 der sich um dieses Problem kümmert. Daneben gibt es noch andere Projekte, wie z.B. http://wrapper.tanukisoftware.org/doc/english/introduction.html, die ebenfalls eine Lösung anbieten.

MfG,
Hilefoks


----------



## Kim Stebel (11. Aug 2007)

komisch, & funktioniert bei mir mal so und mal so..je nach Programm....dann eben anders...


----------



## HoaX (11. Aug 2007)

wenn du dein xterm einfach mit "alt+f4" oder wie auch immer einfach beendest wird meist die shell nicht korrekt beendet und daher auch die darin gestarteten jobs beendet - ist für die shell im xterm quasi wie ein SIGKILL. wenn du die shell mit logout oder exit beendest, dann laufen die auf jedenfall weiter (zumindest bei der bash, abweichung bei anderen shells sind gut möglich, wenn auch unwahrscheinlich)


----------



## McFraggle (11. Aug 2007)

Hm, scheint ja ein diskussionswürdiges Thema zu sein, wenn ich Euren Links mal so folge...
Bin mal gespannt wo unsere (meines Kollegen und meine) Entscheiung hinfällt.... Im Moment tendiere ich zu dem extra Service-Port für diverse Befhle (die ich dann beispielsweise aus einem Shell-Skript via netcat aufrufen könnte) und der Implementierung eines ShutdownHooks für den Notfall....
Vorerst mal wieder ein Danke an Euch!


----------



## HoaX (11. Aug 2007)

Hilefoks hat gesagt.:
			
		

> Durch das & wird die Shell angewiesen den Prozess in einer Subshell zu starten... wird die Shell beendet, werden auch alle Kinder getötet. Um das zu verhindern kann man ein Programm aber mit nohup starten:
> 
> 
> 
> ...



& startet keine subshell sondern das programm als hintergund process der shell, eine subshell wird idR mit backticks bzw $( ... ) gestartet. im gegensatz zu subshells kannst du jobs kontrollieren, siehe fg, bg, jobs, disown, ...

btw lässt sich das verhalten beim beenden bei einigen shells mittels entsprechender shopts anpassen

ich würde den shutdownhook auf jeden fall implementieren, dann kann man den server auch mal getrost mit strg+c abbrechen und er wird vernünftig beendet


----------



## Hilefoks (15. Aug 2007)

HoaX hat gesagt.:
			
		

> & startet keine subshell sondern...


Du hast natürlich völlig recht... sorry!

MfG,
Hilefoks


----------



## Guest (15. Aug 2007)

Wie wär's mit OSGi? Die Declarative Services und die Console von z.B. Equinox scheinen genau das zu sein, 
was du suchst. In diesem Bereich ist auch eine interessante Entwicklung zu erwarten.


----------

