• Café

  • Windowmanager testen, dwm und so

Diskussionsstart in etwa hier. Nur für den Fall, dass das hier noch länger wird.

Stimmt, Xephyr hatte ich nicht mehr bedacht. Bin's von awesome noch so gewohnt, dass ich einfach einen Restart mache, wenn was grandios schiefgeht, fällt er sowieso auf die Standardkonfiguration zurück, da braucht's kein Xephyr.

Zum Thema kill: Wenn ich den Firefox per "kill $pidDesFirefox" beende, behauptet er beim nächsten Start, meine Sitzung sei abgestürzt. Das veranlasste mich zu der Annahme, dass kill zumindest nicht für alle Programme die sauberste Variante zu sein scheint. Normalerweise hast du Recht, ein Programm sollte (wenn ich das richtig im Kopf habe) bei eingehendem SIGTERM-Signal aufräumen und sich dann beenden, in der Realität scheint das aber nicht so ganz bei allen Programmierern angekommen zu sein (was dann kein Problem von kill ist, das ist de facto in so einem Fall dann allerdings relativ egal). Oder lässt sich das Verhalten von Programmen dahingehend ohne Quellcodeänderung ändern?

Ctrl+Alt+Backspace muss ich heute Abend gleich mal ausprobieren.^^
Ich weiss nicht was die beste Option ist um den Xserver zu beenden, ich verwende diese while-Schleife auch nicht da ich dwm eigentlich nur neu baue wenn es eine neue Version gibt. Eine Idee wäre nicht den Xserver zu beenden sondern mit einem signal die Schleife zu beeden, beispielsweise so: 
running=1
trap "running=0" USR1 
echo $$ > ~/.pid_xinitrc

while [ "$running" -eq 1 ]; do  
    dwm
done
Dann lässt sich nach einem 
kill -SIGUSR1 $(< ~/.pid_xinitrc)
dwm ganz normal beenden.
@portix
Auch eine sehr interessante Möglichkeit. Das kann ich prinzipiell in jedem Skript bringen, solange ich sicherstelle, dass das Skript zum Zeitpunkt des Signalgebens noch läuft, richtig? Oder funktionert ein trap-Befehl auch noch, nachdem das Skript durchgelaufen ist?

Anders formulert: Wenn ich ein Skript 
#!/bin/bash

trap "rm -r ~" USR1
ausgeführt habe, wohin muss ich das Signal SIGUSR1 schicken, damit's mir richtig wehtut? 😉

@Vain
Sehe ich das richtig, dass bei deiner Implementierung dwm kurz vor seinem eigenen Exit einfach einen weiteren dwm-Prozess startet?
Ovion schrieb@Vain
Sehe ich das richtig, dass bei deiner Implementierung dwm kurz vor seinem eigenen Exit einfach einen weiteren dwm-Prozess startet?
Nein, keinen weiteren Prozess im Sinne eines zusätzlichen Prozesses, der kurz parallel läuft. „exec*“ ersetzt den aktuellen Prozess mit dem angegebenen Programm und aus dem Funktionsaufruf kehrt man auch nicht mehr zurück. dwm führt also die normalen Aufräum-Routinen aus, aber anstatt dann ganz am Ende die „main“-Funktion zu verlassen, wird das alte dwm-Programm durch das neu kompilierte ersetzt und fängt wieder von vorne an.
Ach so. Ist auch sinnvoller so, zwei parallel laufende WMs dürften zu *leichten* Problemen führen und wenn ein zusätzlicher Prozess gestartet würde, dann würde die .xinitrc ja durchlaufen und X sich verabschieden.

Find's aber interessant, dass man einen Prozess wirklich ersetzen kann, ich hätte vermutet, dass der neue dwm als Unterprozess des startenden dwm läuft.
Ovion schrieb@portix
Auch eine sehr interessante Möglichkeit. Das kann ich prinzipiell in jedem Skript bringen, solange ich sicherstelle, dass das Skript zum Zeitpunkt des Signalgebens noch läuft, richtig? Oder funktionert ein trap-Befehl auch noch, nachdem das Skript durchgelaufen ist?
Das Skript muss noch laufen. Wenn das Skript nicht mehr läuft und ein anderer Prozess hat inzwischen dieselbe Prozess id dann kann es passieren dass man mit kill -SIGUSR1 das andere Programm abschießt. Wenn SIGUSR1 nicht von einem Programm abgefangen wird dann wird das Programm beendet, und viele Programme fangen SIGUSR1 nicht ab, das signal ist normalerweise sinnvoll für irgendwelche daemons.
Alles klar, wieder was gelernt, thx!

Deswegen ist USR1 in der manpage auch mit Action: term katalogisiert, I see.