Errori e diagnostica

Cosa è andato storto in Calíope, quando e su quale dispositivo.

Dove si trova: Workspace › Strumenti › Errori

Il Registro errori salva una riga per ogni errore dell’applicazione, con la data in ora universale, il dispositivo dove è avvenuto, l’area interessata e il profilo di connessione coinvolto, se c’era.

Non è il registro delle query. Quello salva ciò che il server risponde a un’istruzione — un ERROR 1064 di sintassi, per esempio —, che è il risultato normale dello scrivere SQL. Questo salva cosa succede all’app: una connessione che non si stabilisce, un tunnel che cade, un backup che non si può scrivere.

Funziona senza connessione, e non è un caso: il registro è locale e bisogna poterlo leggere proprio quando non ci si riesce a connettere, cioè quando serve di più.

Cosa non viene mai salvato: nessuna password, nemmeno troncata. Un errore di autenticazione registra che è fallito e su quale profilo, mai con quale credenziale. Il server è identificato dall’alias del profilo, non da host, porta e utente.

Un guasto che si ripete da solo non riempie il registro. Il monitor di stato interroga ogni server ogni pochi secondi, quindi uno spento lascerebbe migliaia di righe identiche in una notte. Viene annotato la prima volta e di nuovo se il problema cambia, se il server si riprende e torna a fallire, o se sei ore dopo è ancora uguale. Vedere una sola riga non significa che sia successo una sola volta.

Doppio clic su una riga (o un tocco su iPad) apre il dettaglio completo, con il testo tecnico utile all’assistenza e un pulsante per copiarlo. Se l’errore ha una spiegazione propria, lì c’è il pulsante Vedi soluzione.

Parole chiave: errori, registro, log, diagnostica, guasti, assistenza

Come funziona la sincronizzazione e cosa esce dal dispositivo.

Dove si trova: Calíope › Preferenze › Generale

Il registro può essere replicato nel tuo iCloud privato, così ciò che è fallito su iPad si vede anche sul Mac. Ogni riga conserva il dispositivo su cui è avvenuto: un registro unito in cui non si sa chi ha scritto ogni riga non serve a diagnosticare.

L’interruttore parte spento, e non è una svista. Un registro locale è un tuo file sulla tua macchina; caricarlo fa uscire dal dispositivo gli alias dei tuoi profili e il dettaglio tecnico di ogni errore. Questo si chiede, non si presume. Sta in Preferenze › Generali, separato dall’interruttore che attiva il registro: uno decide se si salva, l’altro se esce da qui.

Perché non viaggia con le altre preferenze. Le preferenze passano da un piccolo archivio iCloud con un tetto di un megabyte condiviso da tutto; quando si esaurisce, smette di sincronizzarsi tutto, non solo ciò che l’ha riempito. Un registro errori cresce con l’uso, quindi passa da un altro canale — CloudKit, record per record —, che permette anche a Mac, iPad e iPhone di scrivere insieme senza sovrascriversi.

Conservazione. 90 giorni di default, regolabile nelle Preferenze. La potatura si applica al file locale e a iCloud, quindi svuotare il registro non lascia una copia lassù che ritorni alla sincronizzazione successiva.

Parole chiave: icloud, sincronizzare, dispositivi, privacy, conservazione

Il server non ha risposto: cosa controllare e in che ordine.

Si applica a: MySQL MariaDB Aurora

Questo errore significa che il tentativo di connessione non ha mai parlato con nessun server: o non c’è nulla in ascolto su quell’host e quella porta, o qualcosa lungo il percorso lo impedisce.

In ordine, dal più al meno probabile:

1. Host e porta del profilo. La porta di default è 3306; un server in container di solito ne pubblica un’altra.
2. Il server è acceso. Verificalo dalla macchina su cui gira, se hai accesso.
3. Il tunnel SSH, se lo usi. Un errore di tunnel si presenta molto spesso come «non si connette»: cerca un errore SSH nel registro, subito prima di questo.
4. Un firewall o la rete. Una VPN caduta, una rete aziendale che filtra la 3306 o una regola di security group nel cloud danno lo stesso errore.
5. Su quale interfaccia ascolta il server. Un server in ascolto solo su 127.0.0.1 è irraggiungibile da un’altra macchina anche se è acceso; lì la soluzione è un tunnel SSH, non aprire la porta.

Parole chiave: connessione, rifiutata, porta, host, firewall, 2003

La connessione è arrivata, ma le credenziali non valgono da qui.

Si applica a: MySQL MariaDB Aurora

Questo errore è una mezza buona notizia: la rete funziona e il server è vivo. Ciò che fallisce è l’identità.

Tre cause, che si risolvono in modo diverso:

- La password o il nome utente non sono quelli che il server si aspetta. Controllali nella gestione connessioni. Attenzione agli spazi iniziali o finali quando incolli una password.
- L’account esiste ma non da questa macchina. In MySQL e MariaDB un account è la coppia utente + host di origine: dba@localhost e dba@% sono account diversi con password diverse. Con un tunnel SSH il server ti vede arrivare da localhost; senza tunnel, dal tuo IP. È la causa più frequente di «da una parte funziona e dall’altra no».
- L’account non ha permessi su quel database. Se il messaggio nomina un database, l’utente è entrato ma non può usarlo; manca un GRANT su di esso.

L’Amministrazione utenti mostra, per ogni account, da quali host può connettersi e quali privilegi ha.

Parole chiave: accesso, negato, credenziali, password, privilegi, 1045

O è stato eliminato, o rinominato, o il tuo account non può vederlo.

Si applica a: MySQL MariaDB Aurora

Calíope ricorda l’ultimo database usato in ogni profilo, quindi questo errore compare di solito riconnettendosi a un server che è cambiato.

Cosa guardare:

- Maiuscole e minuscole. Su Linux i nomi dei database distinguono le maiuscole di default; su macOS e Windows no. Un database creato su un portatile e cercato su un server Linux può sparire solo per questo.
- Privilegi. Un account senza diritti su un database non lo vede nell’elenco, quindi «non esiste» e «non puoi vederlo» si somigliano molto da qui. Se un altro utente lo vede, è questo.
- Il server sbagliato. Con più profili simili è facile guardare la produzione credendo che sia il collaudo.

Aggiorna l’albero dello schema per vedere l’elenco che il server restituisce davvero adesso.

Parole chiave: database, sconosciuto, schema, privilegi, 1049

Si è interrotta a metà operazione: perché succede e cosa resta a metà.

Si applica a: MySQL MariaDB Aurora

La connessione era stabilita e poi è caduta. L’importante non è riconnettersi — è facile — ma sapere cosa è rimasto a metà.

Se era in corso un’istruzione di scrittura fuori da una transazione esplicita, può essere stata applicata del tutto, in parte o per niente, a seconda di dove si è interrotta. Il registro delle query indica qual è stata l’ultima inviata; verificala sul server prima di ripeterla.

Cause abituali:

- Timeout del server. Una connessione inattiva più di wait_timeout (8 ore di default, ma molti server lo abbassano a minuti) si chiude da sola. Si manifesta come «è caduta proprio quando sono tornato all’app».
- Una query più lunga del consentito. Lì scade net_read_timeout o un limite del proxy in mezzo.
- Un pacchetto troppo grande. Un INSERT che supera max_allowed_packet chiude la connessione invece di restituire un errore leggibile.
- La rete. Cambiare wifi, sospendere la macchina o una VPN che si riconnette tagliano la connessione senza avviso.

Parole chiave: connessione persa, timeout, wait_timeout, rete, 2006, 2013

Autenticazione SSH fallita: chiave, password e il caso del secondo dispositivo.

Il tunnel ha raggiunto il server SSH ma non è riuscito a identificarsi. Il database non è ancora stato nemmeno tentato.

Il caso che confonde di più: hai appena configurato l’altro dispositivo. I profili si sincronizzano via iCloud, ma il permesso di leggere il tuo file di chiave privata no, e non è una dimenticanza: quel permesso è un riferimento al file system di una macchina e su un’altra non significa nulla. Sul dispositivo nuovo bisogna riselezionare il file di chiave nel profilo. È la causa numero uno di «lo stesso profilo funziona sul Mac e non su iPad».

Il resto, in ordine:

- L’utente SSH non è quello del database. Sono due identità distinte e spesso con nomi diversi.
- La chiave pubblica non è sul server. Deve comparire nel ~/.ssh/authorized_keys di quell’utente, su quella macchina.
- Permessi del file sul server. Un authorized_keys leggibile da altri viene ignorato in silenzio dal server, senza dire perché.
- La passphrase della chiave. Se la chiave è protetta va inserita; una chiave protetta senza passphrase si comporta come una chiave sbagliata.

Parole chiave: ssh, autenticazione, chiave privata, authorized_keys, tunnel

Quando è normale, quando no, e come verificare prima di accettare.

La prima volta che ti connetti a un server SSH, Calíope salva l’impronta della sua chiave. Se in una connessione successiva il server ne presenta un’altra, si ferma e avvisa.

Questo avviso non è una formalità. Un cambio di chiave è esattamente ciò che si vede quando qualcuno si è interposto fra la tua macchina e il server: accetta la chiave nuova e gli consegneresti le tue credenziali senza accorgertene.

Quando il cambio è legittimo:

- Il sistema operativo del server è stato reinstallato.
- La macchina virtuale o il container è stato ricreato.
- Il nome o l’IP sono stati riassegnati a un’altra macchina (frequente nel cloud).

Come verificare bene: chiedi l’impronta a chi amministra la macchina, con un canale diverso dalla connessione stessa — un messaggio, una chiamata — e confrontala con quella mostrata nell’avviso. Se coincide, accetta. Se non puoi verificarla, non accettare.

Parole chiave: ssh, host key, impronta, sicurezza, man in the middle

Formati supportati e perché il file smette di essere leggibile da solo.

Calíope ha una propria implementazione SSH e non usa l’ssh di sistema, quindi supporta un insieme preciso di formati: chiavi ed25519 ed ECDSA in formato OpenSSH.

Se il file esiste ma non si legge:

- Il permesso potrebbe essere scaduto. Calíope accede solo ai file che scegli tu in una finestra di dialogo, e quel permesso viene salvato come un riferimento che a volte smette di valere: se sposti il file, rinomini la cartella o ripristini la macchina da un backup, va riselezionato.
- Potrebbe essere una vecchia chiave RSA. Convertila in ed25519, che è anche più veloce e più corta.
- Potresti aver selezionato la chiave pubblica. Il file giusto è quello che non finisce in .pub.
- Potrebbe essere protetta da passphrase. Allora va inserita alla connessione; senza non si può decifrare e il risultato è indistinguibile da un file illeggibile.

Parole chiave: chiave privata, ed25519, ecdsa, openssh, permesso, segnalibro

Cade ogni pochi minuti: quasi sempre è il server che chiude le sessioni inattive.

Il tunnel era aperto e poi non più. Riconnettere il profilo lo risolve, ma se succede spesso c’è una causa precisa che si può togliere.

La più frequente è il server SSH stesso che chiude le sessioni inattive. Molti sshd hanno ClientAliveInterval e ClientAliveCountMax impostati per disconnettere dopo pochi minuti senza traffico. Poiché una sessione di lavoro su un database ha lunghi periodi di lettura senza inviare nulla, il tunnel cade proprio quando torni all’app.

Altre cause:

- La macchina è andata in stop. Al risveglio le connessioni di rete precedenti non valgono più.
- Un cambio di rete. Passare dal wifi al cavo, o da una wifi a un’altra, cambia l’indirizzo di origine e taglia la sessione.
- Un limite di sessioni simultanee sul server, se più persone usano lo stesso utente SSH.

Il pannello Attività mostra il tunnel come una modalità accesa finché è vivo, quindi lì si vede a colpo d’occhio se è ancora aperto.

Parole chiave: ssh, tunnel, disconnessione, ClientAliveInterval, inattività

Cosa serve a Calíope da iCloud e cosa smette di funzionare senza.

Calíope usa iCloud per portare i tuoi profili, le tue preferenze e — se lo attivi — i tuoi registri da un dispositivo all’altro. Senza account attivo, tutto questo resta locale.

Cosa controllare:

1. Di aver effettuato l’accesso a iCloud nelle Impostazioni di sistema.
2. Che iCloud Drive sia attivo, non solo l’account.
3. Che Calíope compaia nell’elenco delle app autorizzate a usare iCloud Drive. È facile non vederlo: l’account può essere a posto e l’app deselezionata.

Nel frattempo non si perde nulla. Tutto resta salvato su questo dispositivo; ciò che non avviene è la copia sull’altro. Appena iCloud torna, la sincronizzazione si aggiorna da sola.

Parole chiave: icloud, account, drive, sincronizzazione, companion

Un errore di caricamento non perde dati; cosa fare se si ripete.

Prima cosa: non si è perso nulla. Tutto ciò che Calíope sincronizza ha la sua copia su questo dispositivo, e il caricamento è una copia in più. Un errore qui significa che l’altro dispositivo vedrà i dati più tardi, non che siano stati cancellati.

Se succede una volta e non si ripete, quasi sempre era la rete. Si riprova da solo.

Se si ripete:

- Controlla lo spazio del tuo account. Un iCloud pieno dà questo errore in modo costante.
- Verifica se ci sono troppe scritture di fila. Calíope raggruppa gli invii in lotti proprio per non urtare il limite di frequenza di iCloud, ma un primo caricamento di un registro molto grande può richiedere più tentativi.
- Disattiva e riattiva la sincronizzazione che fallisce. Riattivandola si ricarica tutto da zero.

Prima di toccare qualcosa, fai una copia. Le Preferenze hanno un’esportazione completa della configurazione; esiste perché un’attivazione di sincronizzazione fatta male può sostituire il file delle connessioni del contenitore con uno vuoto. È un incidente misurato, non un’ipotesi.

Parole chiave: icloud, sincronizzazione, errore, riprovare, backup

Cosa occupa spazio in Calíope e cosa si può ridurre senza perdere nulla di importante.

Calíope salva pochissimo su iCloud di default: i tuoi profili di connessione e le preferenze occupano pochi kilobyte.

Ciò che cresce con l’uso sono i registri, e solo se li attivi: il registro delle query e il registro errori. Entrambi hanno una conservazione configurabile nelle Preferenze, e abbassarla è il modo più diretto per recuperare spazio senza perdere nulla che stavi guardando.

Cosa ridurre, per effetto:

1. I giorni di conservazione del registro query. Di gran lunga il più voluminoso: salva il testo completo di ogni istruzione.
2. I giorni del registro errori.
3. Lo storico dell’assistente IA, se lo hai sincronizzato.

Svuotare uno dei tre dal proprio strumento cancella anche la copia su iCloud, quindi lo spazio si recupera davvero e non torna alla sincronizzazione successiva.

Nulla di tutto ciò tocca i tuoi dati di lavoro: i database vivono sui loro server e Calíope non li copia mai su iCloud.

Parole chiave: icloud, spazio, quota, conservazione, registro, pulire

Come funziona l’accesso ai file in un’app dell’App Store.

Calíope gira in un ambiente isolato, requisito dell’App Store: non può aprire un file dal suo percorso, solo quelli che scegli esplicitamente in una finestra di apertura o salvataggio.

Questo ha una conseguenza pratica che la prima volta sorprende: scrivere il percorso a mano non basta. Anche se il file esiste ed è tuo, se non è passato da una finestra di dialogo l’app non lo vede.

Come si concede il permesso: apri il file o la cartella con Apri… o Salva col nome…. Da quel momento Calíope conserva il permesso e può riusarlo senza chiedere.

Quando va concesso di nuovo:

- Se sposti o rinomini il file o la sua cartella.
- Se ripristini la macchina da un backup.
- Se è un altro dispositivo. Questi permessi non si sincronizzano di proposito: su un’altra macchina non significano nulla.

È lo stesso motivo per cui una chiave privata SSH o una cartella di backup pianificati vanno riselezionate su ogni dispositivo.

Parole chiave: permesso, sandbox, file, accesso, app store, sicurezza

Perché un file che prima funzionava smette di aprirsi senza che tu abbia toccato nulla.

Quando scegli un file in una finestra di dialogo, Calíope non salva il suo percorso: salva un permesso di accesso, un riferimento emesso dal sistema che può scadere. Quando scade, l’app non riesce più ad aprire il file anche se è ancora nello stesso posto.

Cosa lo invalida:

- Spostare, rinominare o ricreare il file.
- Rinominare una cartella del suo percorso.
- Ripristinare la macchina da un backup.
- Che il file sia su un volume esterno o di rete smontato.

E c’è un caso che non è un difetto ma una regola: questi permessi non si sincronizzano tra dispositivi, e non per distrazione. Un permesso così è un riferimento al file system di una macchina precisa; su un’altra non punta a nulla, e portarlo produce errori senza alcuna spiegazione visibile — tipicamente un’autenticazione SSH che fallisce senza motivo apparente.

La soluzione è sempre la stessa: riseleziona il file. Non perdi altro; basta concedere di nuovo l’accesso.

Parole chiave: permesso, scaduto, segnalibro, file, dispositivo, sincronizzazione

Cosa intercetta, perché, e come eseguirla lo stesso se sei sicuro.

La modalità sicura esamina le istruzioni prima di inviarle e ferma quelle che possono distruggere dati in modo irreversibile: DROP, TRUNCATE e i DELETE o UPDATE senza clausola WHERE.

Non è una restrizione di permessi. Il tuo account può benissimo farlo; la modalità sicura ti obbliga solo a confermare che era quello che volevi. Esiste per l’errore di un secondo: il DELETE a cui è rimasto fuori il WHERE perché l’avevi selezionato a metà prima di eseguire.

Per eseguirla comunque, disattiva la modalità sicura nella barra dell’editor SQL e rilanciala. L’interruttore è in vista, non nascosto nelle preferenze, proprio perché spegnerlo sia un atto consapevole e momentaneo.

Consiglio d’uso: lasciala accesa nei profili di produzione e spenta in quelli di sviluppo. L’impostazione è per profilo, quindi non c’è da ricordarselo.

Parole chiave: modalità sicura, drop, delete, where, protezione

Dove inserirla, dove viene salvata e perché non viaggia con le impostazioni.

Dove si trova: Calíope › Preferenze › Assistente IA

L’assistente SQL usa un fornitore esterno e serve una tua chiave API per parlarci. Si inserisce in Preferenze › Assistente IA.

Dove viene salvata: nel portachiavi di sistema, non in un file dell’app. Questo significa che né il backup della configurazione né la sincronizzazione normale se la portano di default: un segreto esce da qui solo se lo chiedi esplicitamente e lo cifri con una password che scegli in quel momento.

Se hai appena configurato un altro dispositivo e lì l’assistente non funziona, è questo: la chiave va inserita su ogni dispositivo, oppure va attivata la sincronizzazione del portachiavi nelle Preferenze.

Calíope non fa da intermediario in quel rapporto. La chiave è tua, va direttamente al tuo fornitore e il consumo è addebitato sul tuo account. Per questo limiti d’uso e saldo si gestiscono nel pannello del fornitore e non qui.

Parole chiave: chiave api, assistente, ia, portachiavi, fornitore

Limiti d’uso del fornitore e cosa si può regolare da Calíope.

La quota non la impone Calíope: la impone il fornitore di IA che hai configurato, in base al tuo piano e al tuo saldo.

Due limiti diversi che danno lo stesso errore:

- Frequenza. Troppe richieste in poco tempo. Basta aspettare un minuto.
- Consumo. Il credito o il monte del periodo è esaurito. Lì va ricaricato nel pannello del fornitore.

Cosa si può regolare qui: in Preferenze › Assistente IA puoi abbassare il massimo di token per risposta, che è ciò che consuma di più, e passare a un modello più economico. Anche una conversazione lunga costa di più, perché lo storico viaggia con ogni richiesta: iniziare una conversazione nuova riduce il costo delle successive.

Il resto del programma funziona esattamente come prima. L’assistente è uno strumento fra gli altri; nulla di ciò che fai con l’editor SQL, i backup o i cataloghi dipende da lui.

Parole chiave: quota, limite, token, modello, costo, fornitore

Il database resta in uno stato intermedio: come sapere dove si è fermato e cosa fare.

Dove si trova: Workspace › Strumenti › Backup

Si applica a: MySQL MariaDB Aurora

Un ripristino applica il file istruzione per istruzione. Se si ferma, ciò che è stato applicato fino a quel punto è applicato: il database non torna da solo allo stato precedente.

Prima cosa: non darlo per buono. Un database ripristinato a metà ha tabelle complete, tabelle vuote e tabelle inesistenti, e a prima vista può sembrare che funzioni.

Dove guardare: il dettaglio tecnico dell’errore indica su quale istruzione si è fermato. Di solito è una di queste tre cose:

- Una tabella che esisteva già. Ripristinare su un database non vuoto si scontra al primo CREATE TABLE ripetuto.
- Un DEFINER che su questo server non esiste. Viste, routine e trigger portano l’utente che li ha creati; se quell’account qui non c’è, falliscono. Calíope toglie quella clausola nei propri backup, ma un file fatto con un altro strumento può portarla.
- Un limite di dimensione dell’istruzione. Un backup preso su un server con max_allowed_packet alto produce istruzioni che un server con il valore di default rifiuta.

Come uscirne: la via più pulita è eliminare il database e ripristinare da zero su uno vuoto. Riprendere da metà richiede sapere esattamente cosa è stato applicato, e il file non porta quell’informazione.

Parole chiave: ripristinare, backup, definer, max_allowed_packet, a metà