Mi è capitato di lanciare uno script che fa una serie di operazione ma poi vederlo “bloccato” senza apparentemente fare nulla.
In questi casi può essere d’aiuto fare un po’ di debug sul processo “appeso”.
Immaginiamo che il processo abbia PID 1937 (lo possiamo recuperare con un ps au), come prima cosa “agganciamoci” al processo per vedere cosa fa:
1 | strace -p 1937 |
risponde in questo modo:
1 2 3 4 5 6 7 | Process 1937 attached restart_syscall(<... resuming interrupted call ...>) = 0 poll([{fd=4, events=POLLIN}], 1, 1000) = 0 (Timeout) poll([{fd=4, events=POLLIN}], 1, 1000) = 0 (Timeout) poll([{fd=4, events=POLLIN}], 1, 1000) = 0 (Timeout) poll([{fd=4, events=POLLIN}], 1, 1000^CProcess 1937 detached <detached ...> |
da man poll possiamo vedere i dettagli dei vari stati di polling:
1 2 3 4 | POLLIN There is data to read. POLLPRI There is urgent data to read. POLLRDNORM Equivalent to POLLIN. POLLRDBAND Priority band data can be read (generally unused on Linux). |
Bene, il processo è in polling e non c’è risposta alla richiesta. Ma esattamente qual’è la richiesta che sta facendo? Lanciamo:
dove 1937 è il PID e 4 è il valore che abbiamo letto prima da strace “poll([{fd=4,…”. qui vediamo:
lrwx—— 1 web1 web1 64 nov 19 12:30 /proc/1937/fd/4 -> socket:[16431]
Ci siamo quasi; si tratta del socket 16431, vediamo a chi è relativo:
1 | lsof -p 1937|grep 16431 |
che ci risponde con:
1 | php 1937 web1 4u IPv4 16431 0t0 TCP 10.10.66.45:46876->10.10.66.48:ms-sql-s (ESTABLISHED) |
Ecco qui. La riga incriminata indica una richiesta verso il server con IP 10.10.66.48 al servizio ms-sql-s (sql server di microsoft).
Bisogna controllare cosa c’è che non va nella connessione a SQL server.
enjoy!
Se hai trovato utili le informazioni su questo blog,
Fai una donazione!
Clicca sul bottone qui sotto o almeno clicca sul banner pubblicitario 🙂