{"id":20586,"date":"2026-08-12T17:17:15","date_gmt":"2026-08-12T15:17:15","guid":{"rendered":"https:\/\/webhosting.de\/strace-analysieren-fehler-schneller-finden-debugging\/"},"modified":"2026-08-12T17:17:15","modified_gmt":"2026-08-12T15:17:15","slug":"analizzare-con-strace-individuare-piu-rapidamente-gli-errori-debug","status":"publish","type":"post","link":"https:\/\/webhosting.de\/it\/strace-analysieren-fehler-schneller-finden-debugging\/","title":{"rendered":"Analizzare le chiamate di sistema con strace: individuare pi\u00f9 rapidamente le fonti di errore"},"content":{"rendered":"<p>Con <strong>strace Linux<\/strong> vedo in diretta quali <strong>Chiamate di sistema<\/strong> analizza davvero la mia applicazione e mi permette cos\u00ec di individuare molto pi\u00f9 rapidamente i colli di bottiglia, i problemi di autorizzazioni e i file mancanti. Invece di log incomprensibili, strace mi mostra nel punto cruciale la prima chiamata fallita, gli argomenti e il codice di errore: \u00e8 proprio questo che accorcia notevolmente il mio processo di ricerca degli errori.<\/p>\n\n<h2>Punti centrali<\/h2>\n<p>I seguenti aspetti fondamentali mi aiutano a individuare pi\u00f9 rapidamente le fonti di errore con strace e a circoscriverle con precisione.<\/p>\n<ul>\n  <li><strong>Trasparenza<\/strong>: L'analisi diretta delle chiamate di sistema mette in luce le cause.<\/li>\n  <li><strong>Filtri<\/strong>: Monitorare in modo mirato solo file, processi o reti.<\/li>\n  <li><strong>Analisi in tempo reale<\/strong>: Monitorare i PID attivi e individuare i colli di bottiglia.<\/li>\n  <li><strong>Confronto<\/strong>: Confrontare host e build diversi.<\/li>\n  <li><strong>Sintesi<\/strong>: Visualizza in modo sintetico le chiamate frequenti e costose.<\/li>\n<\/ul>\n\n<h2>Una rapida panoramica delle chiamate di sistema<\/h2>\n<p>Ho impostato <strong>strace<\/strong> quando un'applicazione si blocca, sembra funzionare in modo sospettosamente lento o si chiude senza motivo, perch\u00e9 l'output mi mostra immediatamente il vero <strong>Procedura<\/strong> tra lo spazio utente e il kernel. Le righe contengono i nomi delle chiamate, i parametri, i valori di ritorno, errno e i segnali, cos\u00ec posso individuare immediatamente dove si verifica il problema. Molto spesso il primo messaggio di errore indica gi\u00e0 il vero punto di origine di un problema, ad esempio un openat con ENOENT su un file atteso. Se un processo si blocca, interpreto le chiamate ricorrenti a futex o al polling come modelli di attesa. Per me questo non sostituisce i log, ma li integra con quella profondit\u00e0 decisiva proprio al confine del sistema.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/syscall-analyse-strace-7485.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Inizio: Eseguire i processi direttamente con strace<\/h2>\n<p>Quando voglio analizzare una corsa appena completata, avvio il programma direttamente con <strong>strace<\/strong>, ad esempio con `strace ls`, ottenendo cos\u00ec l'elenco completo <strong>Sequenza<\/strong> delle funzioni di sistema chiamate. Con -e trace=file mi concentro sugli accessi ai file, mentre -e trace=process mi mostra fork, execve ed exit. Per i casi relativi alla rete, utilizzo -e trace=network, in modo che connect, sendto e recvfrom saltino subito all\u2019occhio. Se il numero di righe non mi offre una struttura sufficientemente chiara, utilizzo -c e ottengo una statistica compatta relativa alla frequenza e al tempo. In questo modo riconosco in un batter d\u2019occhio quali chiamate dominano il tempo di esecuzione e dove si sta formando un collo di bottiglia.<\/p>\n\n<h2>Aggiungere e mettere in primo piano i servizi in esecuzione<\/h2>\n<p>Per i servizi gi\u00e0 attivi utilizzo <strong>strace -p PID<\/strong> e mi unisco a quella in questione <strong>Istanza<\/strong>, senza rischio di riavvio o tempi di inattivit\u00e0. Con l'opzione -f includo i processi figli, cosa essenziale ad esempio per i server web e i worker. I timestamp con -tt e le indicazioni sulla durata tramite -T mi aiutano a interpretare con precisione le dipendenze e i tempi di attesa. Se voglio visualizzare solo gli accessi ai file, limito l\u2019output con -e trace=file e mantengo basso il carico sul sistema. Chi ha bisogno di una breve panoramica sulle transizioni del kernel, trover\u00e0 qui una semplice introduzione: <a href=\"https:\/\/webhosting.de\/it\/comprendere-le-chiamate-di-sistema-la-comunicazione-tra-il-kernel-e-le-applicazioni-accesso-controllato\/\">Comprendere le chiamate di sistema<\/a>, il che facilita la lettura delle righe di strace.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/system_calls_strace_analysis_5832.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Come interpretare rapidamente i messaggi di errore: file, permessi, blocchi<\/h2>\n<p>Riconosco i modelli tipici da pochi <strong>Suggerimenti<\/strong>: ENOENT mi segnala percorsi mancanti, mentre EACCES o EPERM indicano <strong>Autorizzazioni<\/strong>, mentre le chiamate futex prolungate o l'uso di ppoll\/pselect indicano la presenza di blocchi o condizioni di attesa. Se riscontro EADDRINUSE o ECONNREFUSED, controllo le porte e le controparti. In caso di problemi TLS o DNS, valuto gli storici di connect\/recvfrom e gli intervalli di tempo tra le righe. Se le chiamate a `openat` sullo stesso file si ripetono senza successo, solitamente si tratta di un percorso di ricerca errato o di una variabile d\u2019ambiente non valida. In questo modo, raramente mi ci vuole molto tempo per individuare il primo errore grave.<\/p>\n\n<h2>Rendere visibile la struttura dei tempi e dei costi<\/h2>\n<p>Con l'opzione -c ottengo una statistica sintetica che mi fornisce <strong>Azioni<\/strong> e mostra la frequenza di utilizzo per ciascuna funzione del sistema, consentendomi cos\u00ec di individuare i punti chiave per <strong>Sintonizzazione<\/strong> Rilevo. Aggiungendo -tt e -T, registro timestamp precisi e la durata di ogni chiamata, il che \u00e8 preziosissimo in caso di blocchi sporadici. Lunghi intervalli tra due righe mi fanno sospettare pause di I\/O o di rete. Se vedo molti piccoli accessi in lettura, controllo il buffering e gli accessi al filesystem della mia applicazione. In questo modo posso indirizzare le ottimizzazioni in modo mirato, senza brancolare nel buio.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/system-calls-strace-analysis-4382.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Confronto tra host e build<\/h2>\n<p>Se un'operazione viene eseguita con successo sull'host A ma fallisce sull'host B, avvio entrambe le esecuzioni con <strong>strace<\/strong> e confronta il <strong>Differenze<\/strong> per quanto riguarda i percorsi, errno, le librerie e le variabili d\u2019ambiente. In questo modo riesco a verificare rapidamente se manca un pacchetto, se \u00e8 attivo un altro percorso di ricerca o se i permessi non corrispondono. Se le chiamate di sistema come openat e statx differiscono nell\u2019ordine o nel percorso di destinazione, ci\u00f2 indica solitamente un contesto di avvio diverso. Per questioni di prestazioni pi\u00f9 approfondite, integro strumenti aggiuntivi; questa panoramica su <a href=\"https:\/\/webhosting.de\/it\/bpftrace-individuare-piu-rapidamente-i-problemi-del-server-di-hosting-e-effettuare-una-diagnosi\/\">bpftrace nell'hosting<\/a> mi aiuta a classificare gli eventi del kernel in modo ancora pi\u00f9 preciso. Letti insieme, strace e bpftrace mi forniscono una mappa chiara del percorso che una richiesta compie all\u2019interno del sistema.<\/p>\n\n<h2>I log vanno integrati, non sostituiti<\/h2>\n<p>Continuo a leggere <strong>Log delle applicazioni<\/strong>, ma strace colma le lacune tra il codice e il kernel quando i messaggi sono incomprensibili o mancano del tutto, il che rende la <strong>Ricerca<\/strong> ridotta notevolmente in base alle cause. Per le questioni relative alla sicurezza, mi piace combinare l'analisi con attivit\u00e0 di audit; chi registra sistematicamente gli eventi di sicurezza trarr\u00e0 vantaggio da questa guida: <a href=\"https:\/\/webhosting.de\/it\/linux-auditd-registrazione-corretta-degli-eventi-di-sicurezza-securetrail\/\">Registrare correttamente auditd<\/a>. In questo modo posso verificare, ad esempio, se una policy blocca l'accesso, mentre strace mi mostra il corrispondente errno. Entrambe le prospettive offrono un quadro pi\u00f9 completo. \u00c8 importante mantenere breve la durata dell'esecuzione di strace, affinch\u00e9 l'output non diventi eccessivo.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/strace_system_calls_nacht_4827.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Flusso di lavoro pratico per una rapida individuazione<\/h2>\n<p>Per prima cosa definisco la <strong>Domanda<\/strong> riguardo al processo: blocchi, crash, risultati errati o risposta lenta, in modo da poter trovare la giusta <strong>Opzione<\/strong> Scelgo. Se riavvio il sistema, utilizzo strace con filtri come -e trace=file o -e trace=network; altrimenti mi collego al servizio con -p. Poi osservo finch\u00e9 non si manifesta l\u2019errore e chiudo nuovamente la sessione. Modifico immediatamente la riga cruciale: controllo il percorso, adeguo i permessi, testo l\u2019endpoint. Se la traccia non \u00e8 chiara, amplio le informazioni temporali e ricorro a -c per individuare i punti critici.<\/p>\n\n<h2>Annotare i risultati e analizzarli in un secondo momento<\/h2>\n<p>Se un errore si verifica raramente, reindirizzo l'output con <strong>-o<\/strong> in un file e, con l'opzione -ff, imposta la suddivisione in base a <strong>PID<\/strong> . In questo modo registro separatamente le attivit\u00e0 dei processi padre e figlio. Con l'opzione -s aumento la lunghezza dell'output per gli argomenti, nel caso in cui i percorsi troncati mi privino di informazioni importanti. In caso di esecuzioni lunghe, imposto una chiara condizione di arresto, ad esempio fino al prossimo punto di errore, affinch\u00e9 la quantit\u00e0 di dati rimanga gestibile. Successivamente filtro il file con grep in base a errno o ai tipi di chiamata e ottengo in un batter d\u2019occhio le righe rilevanti.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/analyse_fehlerquellen_2345.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Panoramica delle opzioni principali di strace<\/h2>\n<p>La tabella seguente riassume i pi\u00f9 comuni <strong>Opzioni<\/strong> e la loro praticit\u00e0 <strong>Benefici<\/strong> insieme, cos\u00ec non devo perdere tempo a cercare durante le analisi frenetiche degli errori.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Opzione<\/th>\n      <th>Scopo<\/th>\n      <th>Utilizzo tipico<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td><strong>-e trace=file<\/strong><\/td>\n      <td>Concentrarsi sulle operazioni sui file<\/td>\n      <td>Verifica rapida di open\/openat, statx, access<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>-e trace=process<\/strong><\/td>\n      <td>Visualizza le attivit\u00e0 di processo<\/td>\n      <td>Tracciare fork\/execve\/clone ed exit<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>-e trace=network<\/strong><\/td>\n      <td>Filtrare le chiamate di rete<\/td>\n      <td>Isolare connect, sendto, recvfrom<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>-p PID<\/strong><\/td>\n      <td>Aggiungersi ai processi in corso<\/td>\n      <td>Analizzare i servizi senza riavviare il sistema<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>-f<\/strong><\/td>\n      <td>Includere i processi secondari<\/td>\n      <td>Registrare integralmente i lavoratori e gli spawn<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>-c<\/strong><\/td>\n      <td>Statistiche sintetiche<\/td>\n      <td>Frequenza e durata per ogni chiamata<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>-tt<\/strong> \/ <strong>-T<\/strong><\/td>\n      <td>Indicazioni temporali pi\u00f9 precise<\/td>\n      <td>Riconoscere le unit\u00e0 di tempo e le durate<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>-o FILE<\/strong><\/td>\n      <td>Reindirizzare l'output<\/td>\n      <td>Consentire un'analisi successiva<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>-ff<\/strong><\/td>\n      <td>Scrivere per ogni file di processo<\/td>\n      <td>Separare genitori e figli<\/td>\n    <\/tr>\n    <tr>\n      <td><strong>-s N<\/strong><\/td>\n      <td>Aumentare la lunghezza dell'argomento<\/td>\n      <td>Rendere visibili i percorsi interrotti<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Sicurezza, diritti ed effetti collaterali<\/h2>\n<p>Calcolo sempre il <strong>Spese generali<\/strong> poich\u00e9 strace intercetta ogni chiamata e ne registra la durata, <strong>Effetti<\/strong> pu\u00f2 causare. Negli ambienti di produzione con risorse limitate, quindi, eseguo il tracciamento in modo mirato e conciso. A seconda del sistema, entrano in gioco meccanismi di sicurezza come ptrace_scope o le policy SELinux che limitano l\u2019accesso, cosa che verifico in anticipo. Quando analizzo processi che trattano dati sensibili, mi assicuro che gli output siano anonimizzati oppure eseguo l\u2019analisi in un ambiente isolato. In questo modo garantisco la riservatezza, mantengo il carico di lavoro moderato e ottengo comunque risultati rapidi.<\/p>\n\n<h2>Esempi pratici tratti dalla vita quotidiana<\/h2>\n<p>Un servizio web si avvia, ma restituisce un errore 500: Con <strong>-e trace=file<\/strong> trovo subito quello che manca <strong>Configurazione<\/strong>-File, perch\u00e9 openat restituisce ENOENT. Uno strumento CLI si interrompe immediatamente: vedo un errore EACCES su una libreria e imposto i permessi corretti. Un\u2019applicazione sembra lenta: -c mostra molte piccole chiamate read, aumento il buffering e riduco il flusso di chiamate di sistema. Un worker si blocca: futex rimane bloccato in modo permanente, controllo il locking nel codice e risolvo il blocco. Si nota un timeout DNS: gli intervalli tra sendto e recvfrom mi indicano un problema di rete esterno all\u2019app.<\/p>\n\n<h2>Rendere visibili i contenuti dei dati e il contesto dei descrittori<\/h2>\n<p>Se i valori di ritorno da soli non mi bastano, nascondo in modo mirato <strong>buffer di dati<\/strong> e il contesto relativo a <strong>Descrittori di file<\/strong> uno. Con <strong>-s N<\/strong> aumenta la lunghezza visibile della stringa per gli argomenti (ad esempio 256 o 1024 caratteri) per visualizzare percorsi completi, blocchi JSON o intestazioni. Per i contenuti non stampabili utilizzo <strong>-x<\/strong> (caratteri non ASCII in formato esadecimale) oppure <strong>-xx<\/strong> (tutto in formato esadecimale), il che \u00e8 particolarmente utile nei protocolli binari. Con <strong>-e read=all<\/strong> e <strong>-e write=all<\/strong> visualizzo i dati effettivi delle chiamate read()\/write() e verifico cos\u00ec se le richieste e le risposte sembrano plausibili. Parallelamente, mi piace attivare <strong>-y<\/strong>, in modo che strace visualizzi anche i percorsi corrispondenti ai descrittori di file (ad es. 3<\/var>), e <strong>-yy<\/strong> per ulteriori dettagli sui socket. Utilizzo questa profondit\u00e0 con parsimonia, poich\u00e9 genera rapidamente una grande quantit\u00e0 di output e pu\u00f2 contenere dati sensibili; negli ambienti di produzione scelgo quindi un <strong>scollo stretto<\/strong> e ruota i file in modo sistematico.<\/p>\n\n<h2>Filtri pi\u00f9 precisi: chiamate di sistema, percorsi ed esclusioni<\/h2>\n<p>Per rimanere concentrato, oltre alle categorie predefinite utilizzo anche <strong>filtri a grana fine<\/strong>. Limito con <strong>-e trace=openat,statx,access<\/strong> inserisco esattamente le chiamate di sistema che mi interessano in questo momento, oppure continuo ad attingere a categorie come <strong>-e trace=segnale<\/strong> oppure <strong>-e trace=ipc<\/strong> torno a questo argomento quando voglio concentrarmi sui segnali o sulla comunicazione interprocessuale. Inoltre, \u00e8 utile <strong>-P PERCORSO<\/strong>, per limitare l'accesso a uno o pi\u00f9 <strong>percorsi concreti<\/strong> da vedere, ad esempio -P \/etc,\/var\/www. Se un classico intramontabile come <em>futex<\/em> Se questo mi d\u00e0 fastidio, mi basta invertire il principio di filtraggio ed escluderlo, specificando esplicitamente solo le chiamate rilevanti. In questo modo ottengo un <strong>a basso rumore<\/strong> Concentrati sull'area in cui si verifica l'errore, mantenendo al contempo basso il carico di lavoro.<\/p>\n\n<h2>Acquisire in modo affidabile cronologie, stack trace ed eventi di breve durata<\/h2>\n<p>I tempi sono la mia bussola. Oltre a <strong>-tt<\/strong> Per ottenere timbri temporali precisi, mi piace usare <strong>-ttt<\/strong>, quando voglio confrontare le esecuzioni su pi\u00f9 host, poich\u00e9 i timestamp delle epoche semplificano l'analisi. <strong>-r<\/strong> mi mostra le distanze relative dall'inizio, il che facilita il riconoscimento di <strong>Angoli di attesa<\/strong> a colpo d'occhio. In caso di crash sporadici, mi aiuta <strong>-i<\/strong> (puntatore di istruzione) insieme a <strong>-k<\/strong> (Stacktrace), per vedere da quale contesto dello stack provenga una chiamata costosa o errata \u2013 particolarmente utile quando sono disponibili informazioni di debug. Per molto <strong>di breve durata<\/strong> Per avviare programmi o cronjob, li eseguo direttamente con strace oppure utilizzo <strong>-ff -o<\/strong>, in modo da non tralasciare nessun execve precoce n\u00e9 nessuna inizializzazione. Se voglio confrontare pi\u00f9 esecuzioni, ordino le statistiche -c con <strong>-S time<\/strong>, per individuare pi\u00f9 rapidamente i picchi nella durata complessiva.<\/p>\n\n<h2>Thread, fork e alberi di servizi complessi sotto controllo<\/h2>\n<p>Non appena <strong>pi\u00f9 processi o thread<\/strong> sono coinvolti, io attivo <strong>-f<\/strong> per consentire l'esecuzione dei processi figli e mi assicuro con <strong>-ff<\/strong> file di output separati per ogni PID. In questo modo posso analizzare in un secondo momento ogni thread per ogni worker ed evitare confusioni. Inoltre, in ambienti con molti processi figli di breve durata, mi \u00e8 d\u2019aiuto la combinazione di <strong>-e trace=process<\/strong> (execve\/clone\/fork\/exit) e <strong>Indicazioni temporali<\/strong>, per comprendere la nascita e la cessazione dei processi nel corso del tempo. Modelli ricorrenti come \u201eParent in attesa di Child\u201c, riconoscibili da <em>wait4<\/em> insieme alla mancanza di attivit\u00e0 da parte del bambino, indicano la presenza di blocchi o di una carenza di risorse. Quando assisto nelle migrazioni, confronto gli alberi dei servizi sull\u2019host vecchio e su quello nuovo e in questo modo verifico se <strong>Distribuzione dei lavoratori<\/strong> oppure <strong>Preforking<\/strong> si svolga in modo identico o si discosti in modo impercettibile.<\/p>\n\n<h2>Container, spazi dei nomi e diritti nell'uso quotidiano<\/h2>\n<p>In container o <strong>Spazio dei nomi<\/strong>-Per questi scenari pianifico le autorizzazioni in anticipo. Per collegarmi a processi esterni ho bisogno dei diritti o delle funzionalit\u00e0 adeguati (ad esempio CAP_SYS_PTRACE) e di meccanismi di sicurezza come <em>ptrace_scope<\/em> oppure alcune politiche possono bloccare l'accesso. Se Ziel e Tracer sono in esecuzione in <strong>diversi spazi dei nomi<\/strong>, mi collego allo stesso namespace oppure passo in modo mirato al contesto di destinazione. Negli ambienti orchestrati tengo inoltre conto del fatto che i PID hanno una durata limitata e <strong>Ruotare le tracce<\/strong> devo fare in modo di non perdere il periodo di tempo rilevante. Riduco al minimo i contenuti trasmessi (ad esempio, nessun payload completo) quando sulla linea transitano dati sensibili e limito rigorosamente la durata all' <strong>Fase critica<\/strong>, per ridurre al minimo gli effetti collaterali.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/08\/systemcall-analyse-8364.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Strace nelle pipeline di compilazione e rilascio<\/h2>\n<p>Anch\u2019io uso strace <strong>presto<\/strong> in CI\/CD, per verificare la creazione dei pacchetti, i percorsi e le autorizzazioni. Una simulazione con <strong>-e trace=file<\/strong> permette di verificare rapidamente se un file binario proveniente dal container di compilazione trover\u00e0 in seguito, nel sistema di destinazione, le stesse librerie e gli stessi percorsi di configurazione. Per i test di regressione, mi assicuro di avere un <strong>Linea di base<\/strong>: Un breve ciclo con l'opzione -c e opzioni costanti (ad es. -ttt, -S time) funge da riferimento. Nelle pipeline successive confronto le statistiche per individuare eventuali picchi improvvisi in <em>statx<\/em>, <em>leggi<\/em> oppure <em>collegarsi a<\/em> da individuare rapidamente. Per garantire che gli artefatti rimangano snelli, mantengo le tracce ben mirate, assegno nomi deterministici ai file (inclusi gli ID di build o di commit) e, se necessario, normalizzo i PID o i timestamp quando genero i diff testuali.<\/p>\n\n<h2>Ostacoli tipici e modelli interpretativi<\/h2>\n<p>Ci sono alcune peculiarit\u00e0 che noto sistematicamente. Quando le chiamate vengono interrotte, spesso compare <strong>EINTR<\/strong> (interrotto da segnali) \u2013 un singolo caso non \u00e8 preoccupante, ma una serie di casi \u00e8 sospetta. Se vedo <strong>ERESTARTSYS<\/strong>- messaggi simili indicano che il kernel ha riavviato alcune chiamate di sistema; sto verificando le fonti dei segnali e le maschere. Quando vengono visualizzati output di diversi processi <strong>misto<\/strong> Quando compaiono, le separo rigorosamente con -ff e ricorro ai timestamp per ricomporle. Le tracce senza un evidente <strong>errno<\/strong>-Gli errori, se accompagnati da lunghi intervalli di tempo, mi fanno sospettare che ci siano tempi di attesa legati all'I\/O o alla rete; in tal caso mi concentro su read\/write\/connect e integro la misurazione dei tempi. Restano i percorsi <strong>tagliato<\/strong>, aumento ulteriormente il valore di -s oppure disattivo le abbreviazioni passando alla visualizzazione dettagliata. Se si riscontrano differenze tra i file binari a 32 bit e quelli a 64 bit (ad es. <em>apri<\/em> vs. <em>openat<\/em>), prendo in considerazione l'architettura e, in caso di dubbio, eseguo entrambe le varianti per confrontarle.<\/p>\n\n<h2>Selezionare con cura le informazioni: la leggibilit\u00e0 prima della valanga di dati<\/h2>\n<p>Proprio quando sono sotto pressione, mantengo un ritmo di spesa ben calibrato: definisco con precisione <strong>Questioni<\/strong> (File mancante? Rete bloccata? Albero dei processi interrotto?), quindi imposta i filtri minimi necessari e termina la traccia immediatamente dopo il <strong>Prova<\/strong>. Per i passaggi di testimone tra squadre scrivo brevi <strong>Note di accompagnamento<\/strong> nella descrizione del ticket: chiamata pertinente, parametri, errno, contesto temporale e causa presunta. Nelle sessioni lunghe non accumulo tutte le opzioni contemporaneamente, ma le attivo <strong>passo dopo passo<\/strong> Ordine: prima -e trace=\u2026, poi -tt\/-T, quindi -y\/-s e, se necessario, -x\/-xx. Questa sequenza mi evita di affogare nei dati e accelera il processo di analisi vero e proprio. Se le prestazioni sono un fattore importante, preferisco utilizzare -c (pi\u00f9 -S time) e una selezione ristretta di chiamate prima di eseguire trace complete.<\/p>\n\n<h2>Riassunto compatto<\/h2>\n<p>Con <strong>strace<\/strong> riesco a individuare pi\u00f9 rapidamente le fonti di errore, perch\u00e9 ho delle vere e proprie <strong>Chiamate di sistema<\/strong> anzich\u00e9 semplici testi di log. I filtri, i timestamp e le statistiche -c mi forniscono indicazioni chiare su percorsi, permessi, reti e tempi di attesa. Avvio i programmi direttamente con strace oppure mi collego brevemente ai PID in esecuzione, focalizzo l\u2019output e interrompo non appena l\u2019errore diventa visibile. Per un'analisi successiva, salvo i file con -o e -ff, aumento -s se necessario e confronto le esecuzioni tra host per individuare le differenze. In questo modo risolvo i problemi quotidiani sui server Linux in pochi minuti anzich\u00e9 in ore.<\/p>","protected":false},"excerpt":{"rendered":"<p>strace su Linux mostra le chiamate di sistema e aiuta a individuare pi\u00f9 rapidamente le cause degli errori su Linux.<\/p>","protected":false},"author":1,"featured_media":20579,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[780],"tags":[],"class_list":["post-20586","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"110","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"strace linux","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"20579","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20586","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/comments?post=20586"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/posts\/20586\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media\/20579"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/media?parent=20586"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/categories?post=20586"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/it\/wp-json\/wp\/v2\/tags?post=20586"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}