Newsgroup: it.comp.os.linux.sys
Titolo: Verificare attività rete di un processo

Salve,
devo verificare che un processo (browser Chrome) stia correttamente 
funzionando, ovvero deve visualizzare una specifica pagina (si tratta di 
una sorta di totem).
 
Al momento l'unica idea che ho avuto è quella di verificare se il 
processo sta inviando e ricevendo bytes dalla rete, solo che non sono 
riuscito a trovare niente di scriptabile che possa fare al caso mio.
Vorrei evitare di montare ntop o wireshark.
Ho visto la /proc/pid/??? ma non ho trovato molta documentazione in 
proposito.
Qualcuno ha per caso qualche idea?
 
Grazie e felice pasquetta
-- 
Luca
http://www.civinini.net
 
 
"Unix is simple. It just takes a genius to understand its simplicity." - 
Dennis Ritchie

Vorrei evitare di montare ntop o wireshark.
 
Non c'è niente di pronto che faccia al caso tuo; quel che cerchi si chiama
traffic accounting, e siccome ognuno lo vuole fatto a modo proprio, esiste
un framework di API che puoi usare, ma il lavoro devi fartelo da te.
 
Personalmente io ti suggerisco di controllare dall'altro lato... richieste
al secondo per quella pagina da quell'IP. "Bytes dalla rete" non è granché
come garanzia; in teoria se ti dirotto il totem e navigo su Youporn, conto
pacchetti per conto pacchetti sembra che tutto stia andando benone, se uno
controlla vede che traffico ne sto facendo a iosa.
 
iptraf, iftop, tcpdump sono tutti scriptabili in qualche misura. Se no, ti
puoi scrivere una utility veloce che usi libpcap.
 
Altrimenti, se sul totem c'è solo Chrome, puoi chiedere le statistiche del
dispositivo eth0 (o quel che sarà). Non distingue nemmeno lui se navighi a
modino o su Youporn, ma nell'ipotesi che tutto vada a modino, ti fa.
 
Un altro modo possibile è installare un proxy per vedere il traffico fatto
di volta in volta dai suoi log o dall'eventuale hook di statistiche.
 
Leonardo
-- 
 
A terrible beauty is born.
                                     - W. B. Yeats, Easter 1916


Grazie per i suggerimenti
Lato server non posso fare niente in quanto è un mondo chiuso (Oracle APEX).
Ovvio che non ho certezze, diciamo che ho sufficientemente castrato il 
totem in modo da evitare (non sono certo) il problema, anche perchè 
comunque è dietro apposito firewall.
Butterò un occhio sulle utility citate (avevo dimenticato alla grande 
tcpdump), vediamo se una fa al caso mio
Grazie


tcpdump), vediamo se una fa al caso mio
 
Allora io farei due cose.
 
1. Proxy che monitora cosa fa Chrome
 
2. Script che a intervalli predeterminati si collega al server lui
   e verifica che tutto sia a posto (per es. Chrome sta girando et
   cetera).



Si può essere ma diciamo che inizia ad essere complicato.
Non è comunque un'idea da scartare, magari riesco a riciclare quello che 
già ho a giro nel datacenter


 una sorta di totem).
 
Beh, immagino sia possibile restringere gli host visitabili (e.g. firewall,
regole di routing…). Giustamente con tcpdump puoi facilmente tener
monitorato il traffico. Prova anche tshark: l'ho trovato molto comodo per
estrarre informazioni sul contenuto del traffico. Ovviamente questo funziona
se la tua pagina non gira in HTTPS.


Il problema è che la "pagina" di tanto in tanto spara fuori un errore e 
il browser smette di fare il refresh..
P.S.
La pagina non è roba mia pertanto devo supporre che una cosa simile 
possa capitare di tanto in tanto.
Grazie per l'info, vedo di mettere tutti i tool su un piatto e vedere 
cosa riesco a fare
Ciao


 in tanto spara fuori un errore e il browser smette di fare il refresh..
 
Per quello ti suggerirei un'estensione del browser che fa il refresh
periodico della pagina.
 
Abbiamo una simile situazione al lavoro con gli schermoni che ci fanno
vedere lo stato del Jenkins (ovvero spesso rosso, ovunque). Siccome Jenkins
è caciotta, abbiamo bisogno di un refresh forzato quando va in palla…
 
Magari ti è utile: 
http://surf.suckless.org/
 ha una modalità "chiosco", ed è
pacchettizzato per Fedora (probabilmente pure per altre distro).


Carino, grazie per la dritta.
Peccato che il fornitore "certifichi" il coso per Chrome :-( e quindi se 
poi non funziona sono mazzi miei.
Per ora la soluzione triviale che ho adocchiato è quella di usare 
xdotool per mandare un F5 al browser ogni 5 minuti.
Settimana nuova dovrei avere un po' di devices per fare le prove.


 Grazie e felice pasquetta
Salve a tutti,
questa sera ripensando al problema ho forse trovato una soluzione (da 
sperimentare a breve): catturo il display del processo ogni X secondi e 
controllo lo screen attuale con quello now-X (salvato da qualche parte 
su un tmpfs)
Se sono uguali, allora il processo è (presumibilmente) piantato e lo 
riavvio. Male che vada, si riavvia in pochi secondi quindi tutto sommato 
interruzione non apprezzabile per l'utente
Se sono diversi, si può sperare che stia funzionando.
 
Nel mio caso la pagina cambia almeno una volta al minuto (c'è un 
orologio dentro) quindi la soluzione potrebbe anche funzionare.
 
Sicuramente è una soluzione super-grezza, ma purtroppo spesso noi 
sysadmin dobbiamo usare soluzioni grezze per software non proprio 
perfetti....;-)
 
Saluti


 perfetti....;-)
 
Ancora piu` semplice (e grezzo):
 
indipendentemente da tutto, fai comunque
ripartire il browser ogni X secondi.
 
Dipende se e` accettabile per l'utente,
chiaramente.
 
Di certo e` una soluzione triviale, che
minimizza i rischi e garantisce sempre
il funzionamento del tutto (ammesso che
Chrome riparta sempre).
 
bye,
 
-- 
 
piergiorgio

Sicuramente è una soluzione super-grezza
 
Che per mille e un motivo equivarrà a riavviare Chrome ogni tot secondi
COMUNQUE.
 
Inoltre, così facendo tu hai implementato una soluzione.
 
Come sysadmin, saprai che, quando in un sistema c'è una soluzione, quel
sistema lo hai compromesso, non è più illibato, e ti tocca sposarlo.
 
Nella fattispecie, tutti quelli che si troveranno Chrome piantato e poi
riavviato ti daranno la colpa:
 
	a) del fatto che si è riavviato
	b) del fatto che si è piantato
	c) del fatto che è lento
	d) del fatto che il risultato non è quello atteso
	e) del fatto che si attendevano una cosa sbagliata
	f) del fatto che Chrome si pianta sul tablet del figlio
	g) sul quale Windows 10 non fa l'update correttamente
 
Fai una cosa diversa:
 
	man strace



OK, guardo..
Per gli altri punti mi hanno già fregato nel momento in cui ho proposto 
di usare delle soluzioni linux al posto del classico PC Windows. Ma 
cavolo per quella applicazione è 10000 volte meglio di qualunque Windows
Cmq non è proprio come riavviare Chrome dato che non lo riavvio se la 
pagina è cambiata. Eppoi il fatto che è su un sistema bloccato aiuta.
 
 
P.S.
Hai dimenticato:
h) il fornitore non sistemerà mai il problema e continuerà a fare 
software di cacca.. :-)



Si, l'avevo pensato o meglio mi è sufficiente mandare un F5 ogni 5 
minuti circa (xdotool) per garantire che il coso non si pianti.
Ma il cliente (interno) ha storto il naso.
 
In ogni caso, se anche il fornitore sistema il problema, la probabilità 
che qualcosa si pianti esiste sempre (es. chrome si avvia in un momento 
di indisponibilità del web server)
 
 
Con il mio "watchdog" dei poveri (o il strace che devo vedere) potrei 
risolvere queste situazioni


 Ma il cliente (interno) ha storto il naso.
 
Avrebbe senso aggiornare solo se l'utente non lo sta usando? In
effetti penso sia una brutta idea rompere le scatole
periodicamente all'utente piallandogli quello che sta facendo!
 
(Comunque la baseline è che l'architettura del caso è un po' una
porcheria. Software cacca, basato su browser, che si pianta
periodicamente? Brutta storia. Ecco della solidarietà.)


Ni, nel senso che è un monitor "NON INTERATTIVO" (fa solo vedere le 
cose) per cui il refresh non rompe le scatole se non per quei 2/3 sec di 
reload della pagina.
Una seconda applicazione in deploy invece sarà interattiva e devo 
trovare il modo di intercettare se c'è qualcuno davanti per non 
rompergli le scatole
 
A dire il vero il sw e l'architettura proprio proprio brutte non sono, 
solo che ho l'impressione che non sia stato testato per dei "long run". 
E' anche vero che prima del deploy io l'ho tenuto sulla mia scrivania 
per giorni (anche un weekend completo) senza che si piantasse niente.
L'unica differenza è che io avevo una connessione LAN quello in 
produzione WLAN (potrebbero esserci delle micro-interruzioni perchè uno 
degli AP si riavvia e il coso deve migrare su altro AP)
 
Vediamo cosa succede quanto mi portano i nuovi pezzi per fare i "cloni"
Grazie a tutti
