ssh single-command 'hangs' after starting a chrooted program
Greetings, Using ssh I remotely call a service script in /etc/rc.d, say # ssh root@xy "/etc/rc.d/named start" where the named is started with the parameters -u named and -t <chroot-jail>. The command gets executed Starting name server BIND9 ..done and the service runs perfectly, BUT ssh does not return, waits indefinetedly for the called server to close the connection and has to be killed with an interrupt instead. Trying different variations showed, that this problem occurs only, when the service is started (or restarted) and the daemon is running chrooted. Hence I assume, Mrs. ssh-single-command + Mr. chroot are having relationship problems... .o) Thanks for your help. Please answer offlist, if you find that problem OT here, then I will post the solution, if one comes up. Michael -- Michael Zimmermann (http://vegaa.de)
On Sun, 6 Oct 2002, Michael Zimmermann wrote:
# ssh root@xy "/etc/rc.d/named start"
The command gets executed and the service runs perfectly, BUT ssh does not return, waits indefinetedly for the called server to close the connection and has to be killed with an interrupt instead.
try ssh -t root@xy "/etc/rc.d/named start"
Hi Achim, ich geh' mal auf Deutsch, das war vorhin ein Versehen mit Englisch in dieser Liste. Als Referenz für die nicht so gut Englisch sprechenden Leser: Es geht darum, dass das Kommando # ssh root@xy "/etc/rc.d/named start" nach dem Durchführen des Befehls "Hängen" bleibt, d.h. ssh beendet sich nach dem Kommando nicht, WENN (und nur wenn) der remote gestartete Daemon in chroot-Umgebung abläuft. Das ist übrigens unbhängig davon, ob der Start durch direkten Aufruf oder über die init.d-Prozedur erfolgt. Und jeder nicht-chroot Start funktioniert auf der anderen Seite einwandfrei. Du antwortetest darauf:
try ssh -t root@xy "/etc/rc.d/named start"
D.h. es wird auf jeden Fall ein Pseudo-TTY benützt. Dann wird's noch "schlimmer". Nun lässt sich ssh nicht mehr per BREAK beenden. Und mit -T (d.h. auf keinen Fall Pseudo-TTY) haben wir wieder den Hänger wie vorher - also anschließend kann per BREAK (Control-C) ssh wieder unterbrochen werden. Das ist es also nicht. Ich werd' mal in der openssh-Liste anfragen... Mittlerweile umgehe ich übrigens den Fehler durch ssh root@xy "echo '/etc/rc.d/named start'|at now" d.h. ich lasse den atd den Start ausführen (mit dem Nachteil, dass ich nun die stdout-Ausgabe des Starts nicht mehr bekomme). Danke und Gruss Michael -- Michael Zimmermann (http://vegaa.de)
On Sun, 6 Oct 2002, Michael Zimmermann wrote:
Hi Achim,
ich geh' mal auf Deutsch, das war vorhin ein Versehen mit Englisch in dieser Liste.
hakuna matada :-)
Du antwortetest darauf:
try ssh -t root@xy "/etc/rc.d/named start"
D.h. es wird auf jeden Fall ein Pseudo-TTY benützt. Dann wird's noch "schlimmer". Nun lässt sich ssh nicht mehr per BREAK beenden. Und mit -T (d.h. auf keinen Fall Pseudo-TTY) haben wir wieder den Hänger wie vorher - also anschließend kann per BREAK (Control-C) ssh wieder unterbrochen werden.
Das ist es also nicht.
hmm, doch das ist es. Nur eben umgekehrt wie ich dachte. Ich kann es bei mir nicht aus probieren, aber es scheint so zu sein dass das Script (vermutlich mit echo) auf das tty schreibt. In einer chroot-Umgebung ist das parent-tty nicht mehr da, oder darf nicht beschrieben werden (chroot !) Also ist der Trick das tty abzuklemmen, was du indirekt mit dem |at now ja auch machst. Wenn meine Theorie stimmt, muesste auch folgendes gehen: ssh root@xy '/etc/rc.d/named start 2>&1>/tmp/n.log' Achim In theorie, theorie and praxis are identical, in praxis they are not. -- unknown --
At Sonntag, 6. Oktober 2002 23:33 Achim Hoffmann wrote:
hakuna matada
Genau!
Wenn meine Theorie stimmt, muesste auch folgendes gehen: ssh root@xy '/etc/rc.d/named start 2>&1>/tmp/n.log'
Negativ k1:/software # ssh root@k2 "/etc/rc.d/named restart 2>&1>/tmp/n.log" Hängt >>> Control-C >>>Killed by signal 2. k1:/software # ssh root@k2 "/etc/rc.d/named stop 2>&1>/tmp/n.log" Geht k1:/software # ssh root@k2 "/etc/rc.d/named start 2>&1>/tmp/n.log" Hängt >>> Killed by signal 2. k1:/software # ssh root@k2 "/etc/rc.d/named start 2>&1>/tmp/n.log" Geht, weil der chroot-Daemon nicht gestartet wurde (er läuft ja schon) Es sind also nicht TTY oder Ein/Ausgabe, die da eine Rolle spielen, sondern ich denke mal in Richtung Kindprozesse, da macht chroot oder nicht natürlich(?) einen Unterschied.
In theorie, theorie and praxis are identical, in praxis they are not.
Sehr passend! Gruss -- Michael Zimmermann (http://vegaa.de)
Hallo, On Mon, 07 Oct 2002, Michael Zimmermann wrote:
At Sonntag, 6. Oktober 2002 23:33 Achim Hoffmann wrote:
Wenn meine Theorie stimmt, muesste auch folgendes gehen: ssh root@xy '/etc/rc.d/named start 2>&1>/tmp/n.log'
Negativ
k1:/software # ssh root@k2 "/etc/rc.d/named restart 2>&1>/tmp/n.log" Hängt >>> Control-C >>>Killed by signal 2.
Ist auch die falsche Reihenfolge bei der Umleitung, da wird stderr auf's Terminal umgeleitet... ... restart >/tmp/n.log 2>&1" Und dann teste noch ein ... restart > /tmp/n.log 2>&1 < /dev/null" Damit leitest du auch noch die Eingabe um. -dnh -- 187: ~ftp/pub/incoming/ -- Angeklagter, warum hatte der Briefkasten, in dem das rechtspornographische und kinderradikale Material (Beweisstück A) sichergestellt wurde, das Sie nicht bestellt zu haben behaupten, einen öffentlich zugänglichen Einwurfschlitz? (Anselm Lingnau)
At Montag, 7. Oktober 2002 12:53 David Haller wrote:
Ist auch die falsche Reihenfolge bei der Umleitung, da wird stderr auf's Terminal umgeleitet...
... restart >/tmp/n.log 2>&1"
Ja, das bringt's. Sowohl stdout als auch stderr umleiten. Das was ich will, nämlich den Daemon nachzustarten, wird also z.B. erreicht durch: ka@k1:~> ssh root@k2 "/etc/rc.d/named restart>/tmp/n.log 2>&1;\
sleep 5;cat /tmp/n.log" Shutting down name server BIND9 ..done Starting name server BIND9 ..done ka@k1:~>
Interessanterweise ist das beim Starten von named ohne chroot NICHT nötig, aber das scheint eine unsaubere Realisierung des chroot-Aufrufs innerhalb von named zu sein (bzw. hier bleibt wohl stderr "stehen", wenn der Prozess als chroot daemonisiert wird). Danke Allen für die Hilfe Gruss -- Michael Zimmermann (http://vegaa.de)
On Mon, 7 Oct 2002, Michael Zimmermann wrote:
k1:/software # ssh root@k2 "/etc/rc.d/named start 2>&1>/tmp/n.log" Hängt >>> Killed by signal 2.
k1:/software # ssh root@k2 "/etc/rc.d/named start 2>&1>/tmp/n.log" Geht, weil der chroot-Daemon nicht gestartet wurde (er läuft ja schon)
aehm, sollte die letzte Zeile vielleicht noch ein s/^k1:/k2:/ stattfinden? Dann verstehe ich den Kommentar.
Es sind also nicht TTY oder Ein/Ausgabe, die da eine Rolle spielen, sondern ich denke mal in Richtung Kindprozesse, da macht chroot oder nicht natürlich(?) einen Unterschied.
Gut, mangels eigener Testmoeglichkeit, probier doch mal bitte folgendes: sed -e 's/echo/: echo/g' named >named.tmp # oder mach es haendisch ... ssh root@k2 "/etc/rc.d/named.tmp start bin nicht sicher ob startproc und/oder killproc auch output produzieren, dann diese evtl. ins nirwana umleiten. Achim
participants (4)
-
Achim Hoffmann -
David Haller -
Michael Zimmermann -
Peter Wiersig