ericvaandering
commented
11 years ago Comment by belforte on Wed Apr 10 16:58:55 2013
I can't reproduce this even in Triest-S.Diego connection with one gsiscp and one gsissh running at same time from multiple shells using same socket. gsiscp slows down, but does not stall and goes back to normal speed once the other commnd exits. There may be something even more subtle going on, but likely a rare occasion. In any case crab2 for remote glidein should be Ctl-C safe and user can simply stop crab -status and try again. So I am not doing any change.
Original Savannah ticket 101105 reported by belforte on Fri Apr 5 03:31:10 2013.
pasting a thread in italian, will summarize once I have some understanding
ciao Stefano,
a TS abbiamo solo due UI, farmui01 e farmui02, quindi la probabilita' di ritrovarsi a girare su piu' terminali dei comandi crab che finiscono per andare in conflitto l'uno con l'altro perche' usano lo stesso ControPath contemporaneamente non e' piccola ... me ne sono accorto di persona ...
localmente ho provato a metterci una pezza in questo modo:
perche' il tty e' unico
mi sarebbe piaciuto usare qualcosa di piu' generale (che non richiedesse di essere arrivati sulla UI con ssh) ma in 5 minuti non ho trovato altro
SSH_TTY ha un formato tipo "/dev/pts/11" per cui sarebbe bastato prendere la parte numerica, ma non mi sono messo a studiare come fare ...
se puo' servire ... altrimenti Ctrl-H ...
ciao, Giuseppe.
dipende dal numero di UI nel senso che se sono poche (a differenza di LXPLUS) e' piu' probabile che uno finisca ad aprire piu' sessioni/terminali sulla stessa UI, e puo' succedere che la scelta (casuale?) del submit-X a cui collegarsi non sia sufficiente ad evitare di usare lo stesso socket (contemporaneamente)
non sono sicuro che il problema fosse la creazione del socket, ma il suo utilizzo: esempio
terminale 1): c'e' un crab -getOutput che gira da un po' e tira giu' roba
terminale 2): dopo un po' lancio crab -status
quello che mi e' successo e' che quando 2) iniziava la connessione, si bloccassero entrambi, e che uccidendo il crab in 2) quello in 1) ricominciasse a "scorrere", come se il ControlPath non ce la facesse a gestire due flussi contemporanei
boh ?
capisco le ragioni di evitare gli sprechi, in caso posso benissimo gestire il "fix" in locale
ciao, Giuseppe.
On Apr 5, 2013, at 24:53, Stefano Belforte <stefano.belforte@cern.ch> wrote:
> p.s. il fatto che piu' shells sulla stessa macchina > riusino lo stesso socket era nella mia testa una feature. > ora c'e' questa race condition nella crezaione del > socket iniziale... che in linea di principio dovrebbe > essere trattata da openssh... ma siccome non lo e', > ci penso. Ma avere un socket (e quindi un processo in > sleep che lo tiene aperto) diverso per ogni sessione > ssh e' anche uno spreco inutile di risorse e una > potenziale causa di casino lato nodo remoto che si > trova a tenere aperte molte piu' sessioni ssh > di quelle di cui avrebbe bisogno. > > cosa succedeva ? si piantava uno dei due crab o tutti > e due ? > > stefano > > On 04/05/2013 12:41 AM, Stefano Belforte wrote: >> cazzo.. sei proprio riuscito a mandare uno prima che l'altro >> avesse finito di aprire la prima sessione ssh !!!! >> sei troppo svelto >> >> non dipende dal numero di UI machines.. >> >> cio' detto l'use case e' un po' tirato ma non insensato >> e quindi dovro' vedere se incorporare il tuo >> workaroundn... OK. >> >> grazie >> Stefano >> >> >> On 04/04/2013 10:12 PM, Giuseppe Della Ricca wrote: >>> se due comandi 'crab' su due terminali diversi, lanciati in contemporanea o quasi, per caso usano >>> lo stesso ControlPath, finisce che si pestano i piedi e si impallano >>> >>> o almeno questo e' quello che ho osservato io ...