Ciao a tutti
mi succede una cosa strana.
Sito che funzionava (fino a un'ora fa) regolarmente.
Su una sandbox (per fortuna non è on-line), ma voglio capire cosa è successo e risolvere.
Lavoro ad un tipo di contenuto che ho creato con cck; passo a sviluppare una views.
Parto da una view già sviluppata, per lo stesso contenuto e per gli utenti anonymous, ma voglio clonarla per creare una views diversa per permettere ad un ruolo specifico di operare in modo diverso.
Clono. Prima cosa che faccio di solito è:
- modifico il link
- modifico il riferimento al menu
(se esistono)
Procedo; aggiorno; premo salva.
Dopo un po' mi appare una bella schermata bianca (WSOD)
Ricarico la pagina ... niente da fare, sempre bianca.
Azzero la cache
Ricarico la pagina
Mi sono perso tutti i menù e tutte le viste; nel senso che qualunque link selezioni, la pagina che mi appare è sempre la stessa. Quella di "default" che elenca i contenuti inseriti ...
Vado di phpmyadmin per verificare il DB; una rapida occhiata ma sembra ok.
Faccio ripartire apache e mysql.
Come prima.
Faccio un reboot del sistema.
Idem
Anche scrivendo l'indirizzo di login http://nomesito/user/login questo carica SEMPRE la stessa pagina ... e anche se scrivo http://nomesito/?q=user
QUindi non riesco ad entrare neanche come admin ... loop
Ho provato a svuotare le tabelle di cache (in DB con phpmyadmin)
AIUTO ... non so cosa fare, sono proprio a terra ... il backup ultimo è tutto sommato recente (2 settimane) anche se non è il massimo.
Idee ?
Perchè il WSOD ... poche risorse della macchina ?
Grazie
k
Forse è un problema di db corrotto...
Ooops. Ha macinato a lungo? Sufficiente per andare in timeout? Nella tabella
views_viewc'è questo nuovo view?Tabelle
menu_router,menu_linkseviews_viewsono apposto? Se il menu router non vede un percorso allora presenta il front page.Hai provato con?q=, perchè se è un problema clean URLs allora un indirizzo tipoadminnon verrà vista - quindi default page. Anche con clean URLs abilitato un indirizzo?q=adminfunziona.Controllato la tabella
watchdog?Prima di tutto meglio fare un backup del db cosi com'è. Poi tenterei di ripristinare il db con l'ultimo backup (almeno per vedere se il problema sta col db). Il sito risponde usando drush? prova
drush statusodrush watchdog show. Forse dirà qualcosa in più se il sito continua a morire.Non necessariamente. Di solito Drupal/PHP riesce a scrivere qualcosa prima di morire. Anche una pagina WSOD non è detto che sia vuoto, controlla anche il sorgente. Comunque è segno di qualcosa veramente brutto, perchè (probabilmente) manda in palla l'interprete di PHP. Questo può succedere con programmi 'data driven' come Drupal, se l'informazione è corrotto.
Certo che sei bravo invocare le legge di Murphy!
Più imparo, più dubito.
una volta successe una cosa simile anche a me quando spostai il sito da un hosting all'altro, dove cliccavo andavo sempre in homepage.
un amico mi modificò htaccess ed andò di nuovo però non ho mai capito cosa era.
una volta successe una cosa simile anche a me quando spostai il sito da un hosting all'altro, dove cliccavo andavo sempre in homepage.
un amico mi modificò htaccess ed andò di nuovo però non ho mai capito cosa era.
Pensato anch'io allo stesso ... infatti ho controllato con phpmyadmin e "mi sembrava consistente"
Si si ... era presente finchè non l'ho rimossa (vid=31 nel mio caso) ... rimuovendo anche i vari riferimenti, penando fosse stata la causa del crash. Fatto un ...azzata ? mmhh ... direi di si ad occhio
le tabelle menu_ sembrano ok; nel senso che ho controllato i contenuti e questi contengono i links corretti;
Provato, con
?q=admin, ma risponde con "accesso negato"; questo è il dramma non riesco più ad entrare neanche come admin ...Si .. ma a dire il vero non saprei cosa guardare;
l'ultimo record è datato "martedì 26 gennaio 2010 13.55.59" esattamente l'ora in cui è andato in crash, e restituisce un "page not found" a seguito di un user/login, con severity= 4 e variables = N;
Fatto, prima cosa che ho fatto ieri: freeze !
Pensavo di farlo stamattina, anche se sono riluttante. Vorrei (cercare di) "capire" cosa è successo e soprattutto perchè. Se mi capita una cosa simile in produzione ... ?!?
Non so come eseguire drush & co.
sorry ...
Azz ... questo non l'ho fatto ... e adesso è tardi.
Eh eh ... siamo cugini ;-)
Grazie per le dritte
Adesso provo a ricaricare il DB backup e vediamo cosa succede.
tks
k
Guarda gli ultimi 10-20 record (SELECT * FROM watchdog w order by wid desc) valori di warning (più basso il valore più critico l'errore 0 == 'crash & burn'
Impara (vale la pena IMHO). Mi ha salvato il sederone più di una volta...
Non importa.
Iscriviti qui: http://www.facebook.com/group.php?v=wall&gid=87917172551&_fb_noscript=1
Più imparo, più dubito.
Grazie per la risposta, stavo lavorando al DB ...
per watchdog:
- ultimi 30 records, il severity non è mai sceso sotto il 4 ...
Drush: interessante, l'ho appena scaricato ... provo ad installare ed eseguire
Grazie per l'info ;-)
c u soon
k
drush è un modulo o un applicazione esterna?
la seconda che hai detto.
va installato nella stessa cartella che contiene la root di drupal:
root- drush
- drupalroot
-- (...)
-- sites
-- (...)
l'accesso tramite command line va eseguito dall'interno della root di drupal (
root/drupalroot drush -command, nell'esempio)Certified to Rock
Allora, riepilogo.
Ho provato di tutto (escluso DRUSH che mi riprometto di imparare a breve; al momento DEVO recuperare il DB e far riapparire il sito di test che sto sviluppando).
Fattu un restore di un "vecchio" DB, 10 gennaio ... ma il sito mi è apparso in "manutenzione"; ok, nessun problema. Entro in login ... bla bla bla.
Mi sembra estremamente LENTO; è vero che come sandbox uso un P4 1.8Ghz con 1 G di RAM ... ma puzza un po'.
Allora vado in Prestazioni > Cache per pulirla ... ma non cambia nulla.
Un analisi del DB mi fa vedere che di fatto le tabelle di cache rimangono "untouched" ... ovvero continuano a crescere ... oops.
Come mai ?
Dov'è il problema ?
Scusate ... mi sono perso.
Grazie
k
ho trovato anche un modulo per drupal 6 di drush, è la stessa cosa?
@asdomar Non proprio, ma se leggi la pagina scopri che non è un modulo - è un script. Ecco perchè la versione è 'All-versions'... C'era una volta un modulo (ancora disponibile) ma molto, molto meno potente. Ma cerchiamo di non dirottare il discorso.
@kasiski - novità? Hai provato 'rimontare' il db più recente? Qualche volta succedono cose magiche...
Più imparo, più dubito.
Eccomi
ho reintallato l'ultimo DB utile che sono riuscito a recuperare ...
tutto ok, il sito ha ripreso vita; funziona.
Anche se ho due settimane di lavoro fumate ... puff !
Rimane comunqua ancora un "mistero" il motivo per cui si è sputtanato così ... e di brutto
certo il metodo di koan è il primo che viene in mente ... sarebbe bello però riuscire anche a capire perhè.
Sicuramente una cosa ho imparato: backup, backup, backup, backup, backup, !
Gia messo a punto lo script per fare inautomatico; giornaliero e settimanale, su tre macchine diverse ...
GRazie per l'aiuto.
Dopo aver riallineato il lavoro perso, mi butto ad imparare drush ... mi sembra molto interessante
tks again
k
Secondo il koan, io proverei con il db di ieri (ti costerà qualche minuto, non si sa mai)...
Il codice per scrivere al db non prevede le transactions. Questo significa che se le cose vanno storto durante il processo, ho un db 'instabile' - ci sono altri aggettivi più coloriti, tipo SNAFU.
Esempio: Creo un nuovo nodo con campo CCK. Questo vuol dire 2 query, prima per la tabella
node, poi per tabellacontent_whatever. Se il primo funziona ma il secondo fallisce?Per questo esistono le transazioni, che rendono il tutto atomico - o tutto funziona, o il rdbms fa un 'rollback' riportando il db nello stato prima di cominciare la transazione - e manda un messaggio di errore. Facile pensare al 'classico' debito/credito - prendo €10 dal tuo c/c e lo aggiungo al mio c/c - grazie. Se il primo funziona, ma il secondo no - vince la banca!
Avendo scelta PDO per Drupal 7, forse questo problema svanirà... se vengono usati... correttamente... da tutti... anche autori dei moduli aggiunti...
Essagerato! Aspetta che faccio un backup anch'io...
Più imparo, più dubito.
:-)
si in realtà le tre macchine sono, il server-sandobox dove risiede il sito, la mia macchina ed un vecchio PIII che mi fa da ... maggiordomo, proxy, gw, nfs ... di tutto un po'
k
Ok, ripristinato quanto possibile.
Domanda: c'è un modo per implementare le transactions in Drupal 6 ?
Un modulo ... ?
La paura di perdere il DB (anche entualmente a causa di un DOS) mi fa "dormir male" ...
karl
Buono a sapere...
Che sappia io - no. E' non sarebbe facile. Credo che questo, insieme alla possibilità di usare altri RDBMS (Oracle, SQL server, per esempio) siano il motivo "enterprise" di usare PDO in Drupal 7.
Condivido il tuo sentimento, Karl. Per Drupal 6, l'unico è backupare frequentamente, dove 'frequentamente' è proporzionale ai numeri di cambiamenti al giorno o all'ora... Ma siamo tutti nella stessa barca! Pensa a chi fa e-commerce...
Più imparo, più dubito.