Linux: capire perché un programma non si avvia

Quando un programma non si avvia su Linux, il problema quasi mai è “misterioso”: di solito c’è un eseguibile non trovato, un permesso sbagliato, una libreria mancante, un errore nell’ambiente grafico o un blocco dovuto a configurazioni utente corrotte. La cosa più importante è non cambiare tutto insieme. Si parte da un controllo minimo, si raccoglie l’errore reale, poi si interviene nel punto giusto.

Questa guida è pensata per chi vuole arrivare in fretta alla causa, senza perdere tempo in tentativi casuali. I passaggi valgono su Ubuntu, Debian, AlmaLinux, Rocky Linux e in generale su server e desktop Linux. Dove serve, indico sia l’approccio da terminale sia quello pratico per capire cosa sta succedendo davvero.

1. Prima domanda: il programma non parte proprio o parte e si chiude subito?

Questa distinzione cambia tutto. Se clicchi l’icona e non succede nulla, il problema può essere nel launcher, nelle dipendenze grafiche o nel profilo utente. Se invece appare una finestra e poi si chiude, spesso c’è un crash immediato, un file di configurazione rotto o una libreria incompatibile.

Il principio corretto è semplice: prima osservare il sintomo, poi cercare il log. Un’app che “non parte” senza un errore visibile va quasi sempre avviata da terminale, così l’errore compare in chiaro.

2. Avvio da terminale: il primo controllo che vale più di dieci tentativi

Se hai un’icona o un menu applicazioni, apri il terminale e lancia il programma dal nome esatto dell’eseguibile. Se non sai il nome, puoi ricavarlo dal collegamento desktop o dal pacchetto installato.

nome-programma

Se il comando non viene trovato, il problema è già chiaro: il programma non è nel PATH oppure non è installato correttamente. Se invece il comando produce messaggi, questi sono il punto di partenza per la diagnosi.

Alcuni segnali tipici:

• command not found: eseguibile non presente nel PATH o installazione incompleta.
• Permission denied: permessi insufficienti sul file o sulla directory.
• No such file or directory: spesso manca il binario, la path è sbagliata oppure manca una libreria richiesta.
• symbol lookup error o errori su librerie: dipendenza incompatibile o mancanti.

Se il programma si avvia da terminale ma non da interfaccia grafica, il problema è quasi sempre nel launcher, nel desktop environment o nelle variabili d’ambiente dell’utente.

3. Controllo del file eseguibile e dei permessi

Una causa molto comune è un file che non è eseguibile. Prima verifica dove si trova il binario o lo script:

which nome-programma

Se il comando restituisce un percorso, controlla permessi e proprietario:

ls -l /percorso/del/programa

Esito atteso: deve esserci il bit di esecuzione, ad esempio -rwxr-xr-x. Se manca, il programma non può essere avviato direttamente.

Per correggere un binario o uno script tuo, il comando tipico è:

chmod +x /percorso/del/programa

Se il file appartiene a un pacchetto di sistema, non modificare a mano senza motivo. Meglio reinstallare il pacchetto o verificare l’integrità dell’installazione. In molti casi il problema non è il file in sé, ma il launcher che punta al percorso sbagliato.

4. Verificare se mancano librerie o runtime

Su Linux un programma può esistere, ma non partire perché una libreria condivisa non è disponibile. Questo è frequente con software scaricato a mano, AppImage, binari precompilati o applicazioni vecchie.

Su sistemi Debian e derivati, puoi usare:

ldd /percorso/del/binario

Esito atteso: tutte le librerie devono risultare risolte. Se vedi not found, hai trovato il punto debole.

Esempio di situazione tipica: il binario esiste, ma una libreria come libQt5*, libssl o libstdc++ non è presente nella versione richiesta. In quel caso la soluzione più sicura è installare la dipendenza mancante dal repository corretto, oppure usare una versione del programma compatibile con la tua distribuzione.

Se il software è installato tramite pacchetto, puoi fare un controllo rapido con il gestore pacchetti. Su Debian/Ubuntu:

dpkg -l | grep -i nome-pacchetto

Su Alma/Rocky/CentOS:

rpm -q nome-pacchetto

Se il pacchetto risulta installato ma il programma non parte, il sospetto si sposta su dipendenze, configurazione utente o bug del software.

5. Capire se il problema è nel launcher grafico

Molti programmi “non si avviano” solo dal menu, ma funzionano da terminale. In quel caso il launcher può avere un percorso sbagliato, un parametro errato o un ambiente grafico non coerente.

Controlla il file .desktop se esiste. Di solito si trova in una di queste posizioni:

• /usr/share/applications/
• ~/.local/share/applications/

Apri il file e verifica le righe principali, in particolare Exec=, TryExec= e Icon=. Se Exec punta a un percorso errato, il programma non partirà dal menu anche se il binario esiste altrove.

Un controllo utile è confrontare il comando del launcher con quello che funziona nel terminale. Se differiscono, correggi il file .desktop copiandolo prima in una posizione utente, così il fix resta reversibile.

Backup prudente:

cp ~/.local/share/applications/nome.desktop ~/.local/share/applications/nome.desktop.bak

Poi modifica solo la voce necessaria. Dopo il cambio, riloggati o aggiorna il database applicazioni se necessario.

6. Verificare il profilo utente e la configurazione locale

Se il programma si chiude subito senza messaggi o funziona con un altro utente, il problema può essere nella configurazione locale del profilo. È una causa frequente con browser, client grafici, editor, programmi Qt o GTK.

Test semplice e reversibile: avvia il programma con un utente nuovo oppure rinomina temporaneamente la cartella di configurazione dell’utente corrente. Molti software usano directory come:

• ~/.config/nome-programma/
• ~/.cache/nome-programma/
• ~/.local/share/nome-programma/

Prima di toccare qualcosa, fai una copia di sicurezza della directory interessata. Poi prova a rinominare la cartella di configurazione, avvia il programma e osserva il comportamento.

Se riparte, il problema era un file di configurazione corrotto o una cache difettosa. A quel punto puoi ripristinare solo i file utili dalla copia, invece di cancellare tutto.

7. Leggere i log giusti senza perdersi

Molti utenti aprono mille log a caso. Meglio concentrarsi su quelli che contano davvero.

Se il programma è stato avviato da terminale e ha stampato errori, parti da lì. Se è un servizio o un’app che gira in background, guarda il journal di systemd:

journalctl -xe

Se conosci il nome del servizio:

journalctl -u nome-servizio -b

Esito atteso: messaggi coerenti con il momento del tentativo di avvio. Cerca parole chiave come failed, permission denied, segmentation fault, missing, cannot open, library.

Per applicazioni desktop puoi controllare anche i log dell’ambiente grafico o quelli nella home dell’utente, ma il criterio resta lo stesso: trovare il primo errore, non l’ultimo effetto collaterale.

8. Se il programma è installato con Snap, Flatpak o AppImage

Qui i sintomi sono simili, ma la diagnosi cambia leggermente.

Per Snap:

snap list

e poi prova l’avvio dal terminale con il nome dello snap. Se non parte, controlla anche i permessi concessi dal confinement.

Per Flatpak:

flatpak list

flatpak run nome.app

Esito atteso: eventuali errori di runtime, permission o portal emergono subito. Se un’app Flatpak non vede file, stampanti o dispositivi, spesso manca una permission concessa nel gestore.

Per AppImage, verifica che il file sia eseguibile e che il sistema abbia i componenti richiesti. In alcuni casi serve libfuse o una versione compatibile del runtime. Se l’AppImage non parte, prova ad estrarla o a eseguirla da terminale per leggere l’errore reale.

9. Quando il problema è un crash immediato

Se il programma si apre e si chiude subito, il sospetto principale è un crash. Le cause più comuni sono:

• configurazione utente corrotta;
• libreria incompatibile;
• versione del programma non adatta alla distribuzione;
• bug noto del software;
• problema con accelerazione grafica o driver.

Un controllo pratico è avviare il programma con un profilo pulito, se supportato, oppure disattivare temporaneamente accelerazione hardware o plugin. Se il software genera un core dump, il journal può indicarlo. In quel caso il crash non è casuale: è ripetibile e quindi analizzabile.

Se il programma è importante e il crash avviene dopo un aggiornamento, la soluzione più sicura è spesso tornare alla versione precedente o reinstallare il pacchetto dalla fonte ufficiale. Evita di miscelare repository diversi senza necessità.

10. Se il programma richiede dipendenze grafiche o sessione utente

Alcune app non partono se mancano variabili come DISPLAY, WAYLAND_DISPLAY o accesso alla sessione grafica. Questo succede spesso quando si prova ad avviare un programma GUI da SSH, da cron o con un utente diverso.

Se stai lavorando da remoto, verifica se stai dentro una sessione grafica reale. Un’app desktop non si comporta bene in un ambiente senza display, a meno che non sia pensata per farlo. In questi casi il problema non è il programma, ma il contesto di esecuzione.

Per applicazioni che devono girare come servizio, conviene usare un’unità systemd dedicata o un container, invece di un avvio manuale improvvisato. Se il programma è GUI-only, va lanciato nel contesto grafico corretto.

11. Metodo rapido di diagnosi in 5 minuti

Se vuoi una sequenza pratica e veloce, usa questo ordine:

1. Avvia il programma da terminale e leggi l’errore.
2. Controlla il binario con which o il percorso esatto.
3. Verifica i permessi con ls -l.
4. Controlla le librerie con ldd se si tratta di un binario ELF.
5. Prova con un profilo utente pulito o rinomina la configurazione locale.

Questa sequenza risolve una grande parte dei casi reali perché separa subito il problema in: binario, dipendenze, configurazione o ambiente.

12. Errori tipici e lettura corretta

Un errore non va letto in modo letterale, ma come indizio. Ad esempio:

• Segmentation fault: crash del processo, spesso legato a librerie, plugin o configurazione corrotta.
• cannot open shared object file: libreria mancante o percorso non corretto.
• Permission denied: permessi, SELinux/AppArmor, o accesso negato a file o directory.
• Gtk-WARNING o errori Qt: problema grafico, tema, plugin o sessione.

Se SELinux è attivo su AlmaLinux, Rocky Linux o CentOS, un programma che “non parte” può in realtà essere bloccato dalla policy. In quel caso i log di audit sono fondamentali. Se AppArmor è attivo su Ubuntu, vale un ragionamento simile.

13. Soluzione consigliata quando non trovi subito la causa

Se il problema resta ambiguo, usa una strategia prudente:

1. fai backup della configurazione utente del programma;
2. reinstalla il pacchetto o verifica il repository ufficiale;
3. prova l’avvio con configurazione pulita;
4. controlla i log subito dopo il tentativo;
5. solo alla fine valuta downgrade o cambio versione.

È la strada più sicura perché evita di alterare più variabili insieme. Se cambi configurazione, librerie e versione nello stesso momento, non saprai mai cosa ha davvero risolto il problema.

14. Esempio pratico di verifica minimale

Supponiamo che un editor grafico non parta. Fai così:

which nome-editor

ls -l $(which nome-editor)

ldd $(which nome-editor) | grep -i not

nome-editor

Esito atteso: il primo comando restituisce un percorso, il secondo mostra il file eseguibile, il terzo non deve mostrare librerie mancanti e l’ultimo deve produrre o aprire l’app oppure un errore utile da leggere. Se invece il programma parte solo dopo aver rinominato la cartella di configurazione, il problema è nel profilo utente e non nel binario.

15. Controlli finali e manutenzione

Dopo il fix, verifica sempre che il programma si avvii in modo stabile almeno due volte, non solo una. Se è un software critico, riavvia la sessione o il servizio e controlla che il problema non ritorni.

Per ridurre i rischi futuri:

• aggiorna regolarmente il sistema e il programma;
• installa solo pacchetti da fonti affidabili;
• mantieni una copia della configurazione funzionante;
• se possibile, annota la causa reale e la correzione applicata.

La diagnosi fatta bene vale più del fix veloce. Un programma che non si avvia non è quasi mai un problema “generico”: è quasi sempre un errore preciso che il sistema sta già dicendo, basta leggerlo nel punto giusto.

La regola utile è questa: avvia, osserva, isola, correggi. Se salti uno di questi passaggi, rischi di sostituire un guasto chiaro con un altro guasto più difficile da vedere.