Desktop starter soll bash skript starten

[tests]

Hallo,

ich habe folgendes Problem:
Mein Desktop starter

Code: Alles auswählen

#!/usr/bin/env xdg-open
[Desktop Entry]
Exec=[absoluter Pfad]helfer.sh
Name=Start
Terminal=true 
Type=Application
Categories=Application;

soll ein kleines helferskript

Code: Alles auswählen

#!/bin/sh
[absoluter Pfad]start.sh start
read p

starten, welches wiederum einen Server startet.
Durch das read kann ich die Ausgabe des Befehls sehen und mit einem Enter das Terminal schließen.

Leider crasht durch das Schließen des Terminals der Server.
Ich habe schon folgendes versucht und alle Kombinationen:

Code: Alles auswählen

[absoluter Pfad]start.sh start &
read p

[absoluter Pfad]start.sh start
disown
read p


nohup [absoluter Pfad]start.sh start
read p

Weiß jemand, was ich falsch mache?

[MSfree]

...
soll ein kleines helferskript
... starten, welches wiederum einen Server startet.

Server startet man per init bzw. seit Debian 8 mit systemd und nicht im Terminal.

[DeletedUserReAsG]

Nicht ausführbar? Auf ’nem noexec-gemounteten FS? Shebang fehlt/kaputt? Script kaputt? Ich würde die Bash (oder die gewünschte Shell) mit dem Script aufrufen.

Was „man“ macht, ist btw. egal. Es ist üblich, sowas über’s Initsystem zu machen, einen Zwang dazu gibt es allerdings nicht. Über ’nen Desktopstarter würde ich das allerdings auch nicht tun, und ‘n Helferscript um ein Script zu starten, ist redundant.

[tests]

Naja es handelt sich hier nicht um einen Server im Hardware Sinn sondern nur um einen Teamspeak Server den ich nur bei Bedarf starte.
Dass das mit dem Helferskript redundant ist, ist mir bewusst, ich will nur nicht den Code im mitgelieferten Skript ändern, bevor es nicht funktioniert.
Den Server brauche ich nur selten und ich würde ihn deshalb gerne per Klick auf den Desktop starten können, ohne ständig das Terminal bemühen zu müssen.

Wenn ich mein Helferskript über das Terminal ausführe kann ich das Terminal auch wieder schließen, ohne dass mir der Server crasht.
Es funktioniert nur mit dem Desktop starter nicht.

[tests]

Weiß keiner Rat, oder ist das Problem so absurd?

[Patsche]

Zeig doch mal deine Skripte. Warum soll das Skript ein Skript starten? Warum startest du den Server nicht direkt mit dem Starter? Was macht das "Hauptskript"? Was macht das "Hilfsskript"?

[tests]

Na klar:

TS skript (mitgeliefert):
http://nopaste.debianforum.de/39513
Helferskript: (im TS Verzeichnis damit man auch ohne den Desktopstarter starten kann)
http://nopaste.debianforum.de/39514
Desktopstarter:
http://nopaste.debianforum.de/39515

Danke!

[Patsche]

Ok. Über das Terminal funktioniert das, richtig? Nur über den Starter nicht. Richtig? Wofür ist jetzt Hilfsskript? Das ist ja eigentlich unnötig. Kannst du mit dem Starter das "Hauptskript" starten?

[tests]

Richtig. Mit dem Terminal klappt alles, nur mit dem Starter nicht.

Das Helferskript ist überflüssig. Das habe ich nur gemacht,
damit ich auch ohne Starter mit einem Befehl den Server starten kann.
Es hilft auch etwas bei der Fehlersuche, weil nachdem es ja übers Terminal klappt,
kann der Code im Helferskript schonmal nicht das Problem sein (denke ich zumindest).

Es deutet bis jetzt alles auf den Desktopstarter...
Ich kann natürlich auch über [Pfad]/...startscript.sh start den Server direkt aus dem Desktopstarter starten,
aber es funktioniert damit auch nicht.
Ich habe ja im Helferskript einen read Befehl. Solange ich nicht Enter drücke crasht der Server nicht.
Erst danach, wenn sich das Terminal (im Desktopstarter mit Terminal=true) schliesst.
Mit Terminal=false crasht nix, aber das ist ja klar, weil da kann ja keiner das read zum terminieren bringen...

Das Seltsame ist nur wenn ich alles mit dem Terminal mache, kann ich das Terminal schließen, wie ich will, da crasht nix.

[MartinV]

Hallo tests,

laß mal das 'Terminal=true ' im Starter weg, oder setz es auf

Code: Alles auswählen

Terminal=false

Das Terminalfenster brauchst Du ja anscheinend nicht.
Ich habe mal testweise mit xfce einen Desktop-Starter für ein Skript erstellt, funktioniert problemlos:

Code: Alles auswählen

[Desktop Entry]
Version=1.0
Type=Application
Name=x11docker-gui
Comment=
Exec=x11docker-gui
Icon=docky
Path=
Terminal=false
StartupNotify=false

[tests]

Danke schonmal,

mit Terminal=false funktioniert es tatsächlich, allerdings würde ich gerne die Ausgabe des Befehls lesen.
Es können ja z.B. Fehler beim Starten auftreten, das würde ich doch ganz gerne mitbekommen.

Geht das einfach nicht? Oder vielleicht irgendwie, indem ich bash manuell aufrufe mit irgendwelchen Parametern und den Pfad des Skript übergebe?
Damit es nicht mehr an das Terminal gekoppelt ist.
Bzw. kann ich ein Terminal auch ohne Terminal=true bekommen?

[tests]

So, jetzt hat sich erstmals eine neue Dimension des Problems eröffnet.

Wenn ich ein Programm (Matlab) mit dem Desktopstarter ohne Terminal starte, startet das Programm, bis es zum Programmlogo kommt und beendet sich dann.
Wenn ich es mit Terminal starte (also mit terminal=true oder direkt aus dem Terminal) klappt alles.

Gleiches Problem mit wine.
Wenn ich ein Windows-Programm aus dem Terminal starte, klappt alles. (übrigens auch wenn ich 'Ausgabe in Konsole umleiten' auswähle)
Wenn ich es über den Starter starte, crasht mir das Programm mit einer Windows Ausnahme.


Das kann ja nun nicht mehr ein zufälliges Problem mit Teamspeak sein, oder?

Irgendeine Idee, wie ich den Fehler eingrenzen kann?

[Swirlich]

ändere mal

Code: Alles auswählen

Exec=[absol. Pfad]/tss_start.sh

zu

Code: Alles auswählen

Exec=bash [absol. Pfad]/tss_start.sh

[TomL]

Du solltest vielleicht doch noch einmal über die Bedeutung des ersten Antwortpostings nachdenken.... denn ganz offensichtlich ist das Teamspeak-Script ein Init-Script, um ein bestimmtes Progamm als Daemon zu starten. Init-Script heisst bei Systemstart und eine der Eigenschaften eines Daemons ist es, seinen Job weitestgehend unbemerkt und ohne Meldungen auf dem Bildschirm und völlig im Hintergrund zu verrichten. Im Hintergrund heisst, er benötigt keinen Bildschirm für Bildschirmausgaben (GUI oder Terminal) um trotzdem fehlerfrei zu arbeiten.
Der Daemon wird im Script gestartet:

Code: Alles auswählen

"./${BINARYNAME}" ${COMMANDLINE_PARAMETERS} > /dev/null

Die Besonderheit ist hier die Umleitung /dev/null, die jegliche Ausgabe-Daten verwirft. Der Weg über einen Desktop-Starter ist also hier der falsche Weg, obwohl man das vielleicht irgendwie hinkriegen kann. Aber dann würde ich das ohne das TS-Script versuchen und nicht als Daemon, sondern das Binary direkt ohne & starten. Ob das allerdings erfolgreich ist, weiss ich im Moment nicht. Aber der richtige Weg ist, wie msfree schon angedeutet hat, eine spezielle Service-Unit zu erstellen. Dann kann der Dienst via systemctl start service.unit gestartet und via systemctl stop service.unit wieder gestoppt werden. Meldungen und Prozeßstatus sind mit systemctl status service.unit zu sehen. Zusätzliche Meldungen, die der Daemon vielleicht loggt, kann man via journalctl -b abrufen, ggf. auch über einen passenden Programm-Identifier ge'grep't.

Ich würde mir eine Polkit-Berechtigung erstellen, um nicht root für den Dienstestart werden zu müssen und es dann via systemd regeln. Der Desktop-Starter mit (überflüssigem) Wrapper ist imho ne Sackgasse.

[tests]

Danke für die ausführlichen Infos, werde das probieren!

Allerdings ist mein Hauptproblem jetzt garnicht mehr der TS Server, sondern andere Programme...
Kann doch nicht sein, dass ich weder Linux Programme, noch Wine Programme über einen Desktopstarter starten kann, oder?

Noch dazu weil ich dieses Problem noch nie hatte mit normalen Programmen. Das kann doch nicht normal sein, oder?

Manche Programme funktionieren hervorragend, andere führen zu richtigen Crashes mit Datenverlust im Programm.
Das kanns doch nicht sein?

Matlab ist das beste Beispiel.

[TomL]

Verwendest Du root um normale Anwender-Programme zu starten? Was ist Dein Standard-Arbeits-Acount? Verwendest Du sudo? Wenn ja, in welchem Rahmen bzw. Umfang?

[DeletedUserReAsG]

Wenn du wirklich Hilfe möchtest, dann rückst du mal mit den Ein- und Ausgaben, den Logs und sonstigem Kram (detaillierte Systeminformationen, das was TomL gefragt hat, etc.), der relevant sein könnte, raus, statt nur „kann doch nicht sein“, „kann doch nicht normal sein“, „das kann’s doch nicht sein“, … von dir zu geben.

[tests]

Ja das tut mir sehr Leid, aber ich bin noch nicht wirklich ein Experte und weiß deshalb garnicht, welche Infos euch weiterhelfen könnten.

Ich verwende nicht root, um normale Programme zu starten, benutze sudo für das gelegentliche apt-get oder mal auf ein Verzeichnis zuzugreifen, aber das wars dann auch schon.
Sonst normaler Benutzer.

Habe ein Upgrade auf Debian stretch gemacht, das könnte natürlich was kaputt gemacht haben, ich behaupte aber, dass ich das Problem schon vorher hatte.
Sonst gibt es auch keine Symptome.

Logs, sry hatte ich nicht dran gedacht, dass da was drin sein könnte, ich weiß nicht warum, hätte ich eigentlich als Erstes suchen müssen...

Hier mal ne journalctl:

Systemlog für Matlab:
http://nopaste.debianforum.de/39556

Systemlog für Matlab mit terminal=true (funktioniert):
http://nopaste.debianforum.de/39557

Ich sehe keinen Unterschied, außer

Code: Alles auswählen

Invalid WM_TRANSIENT_FOR

, Ihr?
Und der tritt wohlgemerkt bei der funktionierenden Version auf...
In der kern.log auch nur der Fehler von zeitgeist.

Systemlog für Wine Programm (nur der Vollständigkeit halber, man sieht leider auch nix):

Code: Alles auswählen

### ###:10 ### q4wine.desktop[18581]: [ii] Loading translation:  "q4wine_de_DE"
### ###:10 ### q4wine.desktop[18581]: "--prefix"
### ###:10 ### q4wine.desktop[18581]: "--nice"
### ###:10 ### q4wine.desktop[18581]: "--program-bin"
### ###:10 ### q4wine.desktop[18581]: "--wrkdir"

Bei Wine kommt das Windows-Ausnahme-Fenster, aber keine Details zum Fehler. (Hängt bei 'Lade Informationen...')