|
|||||||
|
|
|
 |
|
|
Strumenti |
26-01-2008, 14:59
|
#1 | |
|
Member
Iscritto dal: Dec 2004
Messaggi: 53
|
problema nel lanciare processi in background (&)
ho un problema singolare....
devo lanciare in un dato ordine 5 processi in background.... uno di loro (il 3° per la precisione) controlla lo stdin e alla pressione di un tasto avvia determinate funzioni. Il problema è che quando lancio in backgraund un processo, con il comando ./processoX & a volte mi ritorna immediatamente la shell, altre volte invece non ritorna immediatamente la shell, ma occorre dare un invio... è come se il processo non fosse ancora in bg, ma lo diventasse alla pressione di un tasto. solitamente questo comportamento non mi crea problemi, ma al lancio del 3° processo si!! xchè se ritorna immediatamente la shell tutto fila liscio come l'olio, ma se sono costretto a premere il tasto invio, il processo recepisce quell'invio come un tasto premuto e fa cose che non dovrebbe fare... mi spete spiegare perchè accade??? e soprattutto come impedire che accada?? Nel caso non fossi stato sufficientemente chiaro allego un esempio: -Caso ERRATO: Codice:
mercedes:~/privato/test> ./processo3.exe & [4] 17443 mercedes:~/privato/test> avvio processo caricamento in corso caricamento eseguito correttamente <---- qui rimango bloccato e se premo invio succede questo... Codice:
[4] + Suspended (tty input) ./processo3.exe mercedes:~/privato/test> -Caso CORRETTO: Quote:
l'unica differenza che ho notato io è che nel primo caso dopo il lancio del processo viene restituito: - il PID, - poi la Shell, - poi le frasi di debug e rimane in sospeso.... nel secondo caso viene restituito - il PID, - poi le frasi di debug - poi la Shell, grazie MILLE!!! |
|
|
|
|
26-01-2008, 19:25
|
#2 | |
|
Senior Member
Iscritto dal: Jul 2006
Messaggi: 466
|
Quote:
|
|
|
|
|
|
26-01-2008, 19:57
|
#3 |
|
Member
Iscritto dal: Dec 2004
Messaggi: 53
|
ciao grillosoft,
ho provato a lanciare i processi con sh, ma in questo modo TUTTI i processi mi restituiscono un errore.. sh processo3.exe ----> processo3.exe: 1: Syntax error: "(" unexpected poi ho provato a lanciare solo sh, e lanciare i comando da $ ma nulla di fatto 
|
|
|
|
|
26-01-2008, 21:17
|
#4 |
|
Senior Member
Iscritto dal: Jun 2000
Città: S.Giuliano (MI)
Messaggi: 1047
|
ciao!
se il programma non è concepito per andare in background (ad esempio gli script di shell non lo sono), faresti megli a mandarlo in background con "nohup" Codice:
gurutech@gurutech.it:~$ man nohup
NOHUP(1) User Commands NOHUP(1)
NAME
nohup - run a command immune to hangups, with output to a non-tty
SYNOPSIS
nohup COMMAND [ARG]...
nohup OPTION
DESCRIPTION
Run COMMAND, ignoring hangup signals.
[...]
nohup /home/test/mioscript.sh &
__________________
“No te tomes tan en serio la vida, al fin y al cabo no saldrás vivo de ella” |
|
|
|
|
26-01-2008, 21:19
|
#5 | |
|
Senior Member
Iscritto dal: Jun 2000
Città: S.Giuliano (MI)
Messaggi: 1047
|
Quote:
 )meglio allora fare bash processo3.exe
__________________
“No te tomes tan en serio la vida, al fin y al cabo no saldrás vivo de ella” |
|
|
|
|
|
26-01-2008, 21:59
|
#6 |
|
Member
Iscritto dal: Dec 2004
Messaggi: 53
|
maledizione... nulla da fare....
queste cose mi fanno uscir fuori di matto!!! ma sai perchè?? perchè dopo aver perso ore e ore a preparare le mie applicazioni in c, mi ritrovo bloccato in questa maledetta cosa incredibile!!! anche perchè se io lancio tutto da Makefile, tipo così pippo: ./processo1.exe & ./processo2.exe & ... ... ./processo5.exe & e da shell lancio make pippo funziona!!! in realtà non funziona perchè in tal modo il processo 3 che appunto deve gestire il filedescriptor 0(cioè lo stdin) impazzisce, e ad ogni cilco mi entra nella parte di codice che gestisce l'input da tastiera e quindi mi da risultati non voluti, ma pero' a parte questo tutto va bene... invece se lancio GLI STESSI comandi da shell... 1 volta mi va e 10 no per via del problema che ho riportato sopra... ma vi sembra normale?? |
|
|
|
|
27-01-2008, 10:17
|
#7 | |
|
Senior Member
Iscritto dal: Jun 2000
Città: S.Giuliano (MI)
Messaggi: 1047
|
Quote:
può darsi che così troviamo una soluzione
__________________
“No te tomes tan en serio la vida, al fin y al cabo no saldrás vivo de ella” |
|
|
|
|
|
27-01-2008, 10:44
|
#8 |
|
Senior Member
Iscritto dal: Nov 2002
Città: Morbegno (SO)
Messaggi: 1410
|
Codice:
#!/bin/bash sleep 3 echo metti pippo read pippo echo $pippo Codice:
#!/bin/bash ./test.sh <<EOF & ciao EOF Comunque non e chiaro se tutta la catena di processi deve sospendersi per l'input, oppure l'input sara' sempre costante
__________________
e' difficile cio' che non si conosce Tic Tac Andrew Morton, 15/02/2008 LKML:"`tmp' is an awful identifier, and renaming it to `temp' hardly improves it." |
|
|
|
|
27-01-2008, 10:49
|
#9 |
|
Member
Iscritto dal: Nov 2007
Città: Ginevra
Messaggi: 256
|
E se lanci mandando tutti gli output in /dev/null?
comando 2>&1>/dev/null & come ti hanno gia' chiesto, i programmi sono fatti per andare in bg? |
|
|
|
|
27-01-2008, 11:46
|
#10 | |
|
Senior Member
Iscritto dal: Jun 2000
Città: S.Giuliano (MI)
Messaggi: 1047
|
Quote:
__________________
“No te tomes tan en serio la vida, al fin y al cabo no saldrás vivo de ella” |
|
|
|
|
|
27-01-2008, 13:51
|
#11 |
|
Member
Iscritto dal: Dec 2004
Messaggi: 53
|
Grazie a tutti per i vostri aiuti,
li ho provati ma non hanno portato a nessun miglioramento (devo ancora leggere l'ultimo link, lo faro' appena finito di scrivere questo post) Provo a rispondere alle vostre domande: come detto precedentemente, uso 5 processi. tali processi, riassumendo, non fanno altro che passarsi dati su canali TCP/IP per mezzo dei socket. Il 3° processo, oltre a far transitare i dati dal processo 2 al 4, gestisce anche lo stdin, al fine di poter simulare alcune casisteche nel caso vengano premuti dei tasti... quindi mi sentirei di rispondere SI, i processi possono andare in background. per farvi capire ancor meglio vi posto un po' di codice, cercherò di inserirne il minimo possibile, in modo da evitare di farvi perdere troppo tempo... CODICE PROCESSO 2: DOPO ESSER STATO CONTATTATO DA PROCESSO 1 SI COLLEGA A PROCESSO 3 Codice:
ris= TCP_setup_connection(&socketfd[j], string_remote_ip_address[j], remote_port_number[j], 10000000, 10000000,1 );
if (!ris) {
printf ("impossibile connettersi al server %s %d\nTERMINO!!\n", string_remote_ip_address[j], remote_port_number[j] );
fflush(stdout);
return(0);
} else {
printf ("Collegamento effettuato");
}
CODICE PROCESSO 3: DOPO ESSER STATO CONTATTATO DA PROCESSO 2 SI COLLEGA A PROCESSO 4 ( o meglio dovrebbe!!!) lo fa solamente ognitanto Codice:
rdset=all;
do {
ris=select(maxfd+1,&rdset,NULL,NULL,NULL);
} while( (ris<0) && (errno==EINTR) );
if(ris<0) {
perror("select failed: ");
exit(1);
}
else
{
for(i=0;i<numconndausare;i++)
{
if( (usalistenfd[i]) && (FD_ISSET(listenfd[i],&rdset )) )
{
/* accetto connessione e creo il thread */
OMISSIS
qui c'e' il codice che gestisce i canali in entrata uscita.
}
}
if( FD_ISSET(0,&rdset) )
{
char str[100];
fgets(str,100,stdin);
pthread_mutex_lock( &mutex_blocca );
BloccaConnessione=1; <------------
pthread_mutex_unlock( &mutex_blocca );
}
}
}
è quella che mi gestisce l'input da tastiera... dovrebbe funzionare solo quando premo un tasto una volta che tutti e 5 processi sono partiti.... ma se per caso dopo aver lanciato ./processo3 & non mi viene data immediatamente la shell, lui cattura i tasti che premo per lanciare gli altri processi e io non vado + avanti.... Poi casomai il problema sta altrove, ma in tal caso non mi spiegherei come mai a volte va e a volte no.... per tagliare la testa al toro, ho inserito una frase di debug sotto la linea evidenziata dalla freccia <------ stampavo PIPPO, bene ogni volta che stampava PIPPO il programma non andava, altrimenti funzionava benissimo, o se prferite ogni volta che la pressione di un tasto attivava if( FD_ISSET(0,&rdset) ) il programma non funzionava. ma per curiosità, voi, che immagino usiate spessissimo linux, e non solo per studio, quando lanciate un programma in background, cosa accade? dentro quale delle 2 casistiche ricadete? grazie ancora... vado a leggere la guida dell'ultimo link, e nel caso aggiorno la situazione. Ciao ciao |
|
|
|
|
27-01-2008, 14:06
|
#12 |
|
Senior Member
Iscritto dal: Jan 2002
Città: Napoli
Messaggi: 1727
|
ma al posto di usare la pressione di un tasto per bloccare la procedura.. non puoi usare qalcosa di diverso?
tipo un file.. che se esiste blocca la procedura mi sembra un po' un controsenso usar la pressioen di un tasto epr bloccare l'esecuzione di qualcosa che poi fai girare in background
__________________
Se buttassimo in un cestino tutto ciò che in Italia non funziona cosa rimarrebbe? Il cestino. |
|
|
|
|
27-01-2008, 14:20
|
#13 |
|
Senior Member
Iscritto dal: Nov 2002
Città: Morbegno (SO)
Messaggi: 1410
|
sembra l'esame di sistemi 2
poi perche vuoi farli andare in bg sulla stessa shell? se comunicano cosi potrebbero girare in 5 shell separate, tanto comunicano tramite socket, ed inoltre la situazione sarebbe piu' realisica visto che devi simulare 4/5 macchine, non una con 4 processi(senno non utilizzare socket ma pipe) un processo in bg e solo un processo su cui la shell da un fork invece di un exec, condivide stderr e stdout con la shell, lo stdin e' gestito da un singolo processo alla volte (portandolo in fg o in bg, comandi shell tipo bg 1(nome job)) se ho capito bene, sulle 4 shell aperte un'ordine giusto sarebbe, processo 2, processo 3, processo 4 processo 1 (che da come ho capito e' quello che innesca il tutto)
__________________
e' difficile cio' che non si conosce Tic Tac Andrew Morton, 15/02/2008 LKML:"`tmp' is an awful identifier, and renaming it to `temp' hardly improves it." Ultima modifica di Mason : 27-01-2008 alle 14:23. |
|
|
|
|
27-01-2008, 14:21
|
#14 |
|
Member
Iscritto dal: Dec 2004
Messaggi: 53
|
siete troppo veloci a rspondere non vi sto dietro
 [Per dupa] se devo essere sincero, io sarei molto felice di poter attuare il tuo consiglio, purtroppo pero' processo3 non posso toccarlo, così mi è stato dato e così me lo devotenere, pero' in questi giorni approfondendo un po' queste cose sulla rete, mi è parso di capire che un processo iterativo com'e' processo3 non dovrebbe girare in BG, ma se non lo faccio girare in BG non vedo come potrei finire di lanciare processo4 e processo5.... [Per Mason] adesso provo immediatamente a lanciarlo da + shell... lo facevo dalla stassa perchè pensavo fosse una cosa intelligente ... al fine di farli funzionare non ho un ordine prefissato da seguire... l'importante e che processo5 sia l'ultimo ad essere avviato. E' lui che mette in modo, a cascata, tutti gli altri... ok forse avrei duvuto chiamarli in un altro modo... comunque p5 manda i dati a p4, il quale li manda a p3 e così via fino a p1.... si... era decisamente meglio numerarli al contrario... comunque semanticamente parlando non cambi nulla... Ultima modifica di luppolo : 27-01-2008 alle 14:26. |
|
|
|
|
27-01-2008, 14:32
|
#15 |
|
Senior Member
Iscritto dal: Nov 2002
Città: Morbegno (SO)
Messaggi: 1410
|
Scusa, non avevo visto che avevi risposto, igonra pure e segui quello di piu shell, e piu' naturale
forse non ci siamo inesi, non devi modificarlo quel processo, basta che apri 4 shell e su ognuna lanci un processo singolo tutto dovrebbe funzionare quello che vuoi tu, cioe che processo3 mantenga il canale stdin deve essere lanciato per ultimo senza &, ma questo e' contro il requisto, se ho ben capito, che il processo 1 sia quello che fa partire la catena di attivazione, quindi deve partire per ultimo quando tutto e su'. Codice:
pr1->pr2->pr3->pr4
/\
|
stdin
__________________
e' difficile cio' che non si conosce Tic Tac Andrew Morton, 15/02/2008 LKML:"`tmp' is an awful identifier, and renaming it to `temp' hardly improves it." |
|
|
|
|
27-01-2008, 14:36
|
#16 |
|
Member
Iscritto dal: Dec 2004
Messaggi: 53
|
Santo cielo...
avevi ragione... ma non ci credo... cioè se quel maledetto processo3 lo lancio in foreground da una seconda shell non ho problemi di sorta.... lui sta li' bello e buono finche nella prima shell non ho finito di lanciare tutti i miei processi.... l'unico neo è che l'output di p3 e quello di p1,p2,p4,p5 sono distinti... ovviamente... ma non penso sia un problema importante.. ma prima di cantar vittoria corro immediatamente a fare altri test... comunqua vada grazie!! ho imparato qualcosa di utile
|
|
|
|
|
27-01-2008, 14:41
|
#17 |
|
Senior Member
Iscritto dal: Jan 2002
Città: Napoli
Messaggi: 1727
|
mi pare di capire che la situazione sia:
--background-- proc1 parte, apre server1 proc2 parte, si collega a server1, apre server2 proc3 parte, si collega a server2, apre server3 (e gestisce comandi da stdin) proc4 parte, si collega a server3, apre server4 proc5 parte, si collega a server4 --/background-- Io farei: --background-- proc1 parte, apre server1 proc2 parte, si collega a server1, apre server2 proc4 parte, (ciclo di tentativi di connessione a server3), apre server4 proc5 parte, (ciclo di tentativi di connessione a server4) --/background-- --foreground-- proc3 parte, si collega a server2, apre server3 (e gestisce comandi da stdin) --/foreground--
__________________
Se buttassimo in un cestino tutto ciò che in Italia non funziona cosa rimarrebbe? Il cestino. |
|
|
|
|
27-01-2008, 14:49
|
#18 |
|
Member
Iscritto dal: Dec 2004
Messaggi: 53
|
Esatto dupa.. anch'io idealmente avrei voluto seguire quel modello, pero' non potevo lanciare per ultimo in FG p3, perchè appena partito p5 si collegava a p4 e se p4 non trovava dei socket in ascolto sull'indirizzo TCP/IP di p3 chiudeva baracca e burattini, e a quel punto anche p5 vistosi chiudere in faccia letteralemnte la porta smetteva di generare ed inviare messaggi...
aprendo p3 in un'altra shell invece risolvo il problema alla radice... perche' non puo' intercettare le pressioni dei miei tasti nella shell n.1 ma al contempo rimane raggiungibile via TCP perchè risiedono sulla stassa macchina... sono così felice che potrei anche smettere di lavorarci per oggi
|
|
|
|
|
27-01-2008, 14:53
|
#19 | |
|
Senior Member
Iscritto dal: Nov 2002
Città: Morbegno (SO)
Messaggi: 1410
|
se non hai il requisito che processo 1 sia l'utlimo a partire, puoi anche lanciarli da singola shell
#!/bin/sh pr1& pr2& pr4& pr5& pr3 edit: letto ora che hai un vincolo di sequenza, ma chiarimo questo punto: Quote:
cmq chiarimenti a parte, son contento hai risolto, son 5 euro
__________________
e' difficile cio' che non si conosce Tic Tac Andrew Morton, 15/02/2008 LKML:"`tmp' is an awful identifier, and renaming it to `temp' hardly improves it." Ultima modifica di Mason : 27-01-2008 alle 14:58. |
|
|
|
|
|
27-01-2008, 14:57
|
#20 | |
|
Member
Iscritto dal: Dec 2004
Messaggi: 53
|
probabilemnte mi sono spiegato male sopra, ma ribadisco che ho l'esigenza di far partire per ultimo Processo5...
quindi la tua idea di usare shell differenti è una soluzione fantastica. edito anch'io per risponderti Quote:
amo le pipe... ma l'idea del progetto è vedere se uno sa usare i socket... peccato (o fortuna) che serva anche conoscere unix meglio di quanto lo conosca io... per i 5 €... visto che non lavoro ti accontenti di un sacco di riconoscenza????
Ultima modifica di luppolo : 27-01-2008 alle 15:09. |
|
|
|
|
|
|
| Strumenti | |
|
|
Tutti gli orari sono GMT +1. Ora sono le: 21:22.
