Ciao
Non riesco ad aggiornare i cron dal server...
sul server ho aggiunto il cron tramite questo link: http://www.miosito.net/cron.php
Ma sul rapporto di stato di drupal mi continua a dare il tempo che non è aggiornato il cron...
Perchè non funziona?
ora ho dato i permessi 777 al file cron.php ma non cambia...
Su drupal.org cercando Cron ti trovi il modo per configurarlo come deve essere fatto
http://www.chromeos.eu
Volendo anche qui ti spiega come funziona:
http://it.wikipedia.org/wiki/Crontab#Campi
Un paio di esempi su un server virtuale che uso io:
Alle ore 0 di ogni 6 ore:
0 */6 * * * /usr/bin/wget -O - -q -t 1 http://www.sito.zz/cron.php
Alle ore 2 di ogni giorno:
0 2 * * * /usr/bin/wget -O - -q -t 1 http://www.sito.zz/cron.php
eh, sì ragazzi. Grazie, ho impostato qualche cron in passato, anche per Drupal… ;)
Visto che però la frase di chi ha fatto la domanda è un po' zoppicante credo che se ci spiega cosa ha fatto effettivamente, forse veniamo a capo del suo problema.
Ma perchè il modulo Poormanscron non và bene ?
.. si, oddio, forse non è il massimo..
Poormascron oltre a dare problemi a livello seo rende più lento il sito, è una soluzione di ripiegho.
http://www.chromeos.eu
e te pareva : quindi che dovremmo fare ?
aprire cron.php e metterci la riga :
0 2 * * * /usr/bin/wget -O - -q -t 1
perchè cronni il sito una volta al di ?
(su drupal org ci sono 30 versioni diverse tra loro su comeforsefare, e su wikipedia .. bisogna prima prendersi una seconda laurea in informatica dei cms)
Prova e vedi, ogni soluzione di per se è valida.
http://www.chromeos.eu
Ok, provo su uno e vedo se mi funziona, perchè il poormanscron ho notato che rallenta (come anche tu confermi).
vedendo poi alcune discussioni anteriori a questa, era un pò di tempo che ci pensavo sopra, ma indeciso: per il dubbio di far peggio con qualche Caos.
Il cron non va impostato in cron.php ma tramite riga di comando o per mezzo del pannello di controllo fornito da tuo servizio di hosting.
Ad esempio se hai a disposizione un pannello Plesk devi andare su task pianificati ed impostare in base a quello che ti serve:
Che disdetta : se si poteva farlo nel cron.php di drupal ..ero più felice.
cmq : netsons ha Cpanel : ma del Cron non vedo traccia ..
Misterdomain, peggio ancora, ha un plesk ridotto all'osso che più ridotto non si poteva : e stanno facendo parecchio schiffio come service.
Iniziero' a tampinare quelli della Netsons e sentire "che dicono a riguardo".
--
PS
Se qualcuno riesce a dare la sveglia a misterdomain (per il Cron) o sà come fare : me lo faccia sapere x favore : cosi gli romperò le scatole anche io sull'argomento con richieste specifiche.
Questo anche perchè quando un fornitore "toglie" invece che "dare" al suo host service e..inizia con Fantasiose Non-Risposte o con Risposte Assurde : ... fà anche presto a stancarmi.
cPanel è un bel po' che non lo uso e non ne ho uno sottomano. Però ho trovato questa guida http://www.vittorioatzeni.com/2011/03/appunti-cpanel-creare-cancellare-c...
Niente da fare, qui nel cpanel non c'è ombra di CRON.
gli aprirò un ticket...
@KRIMA: queste le risposte CRON-iche dei signori della Netsons :
Salve,
CRON non è disponibile sull'hosting condiviso ma solo sul semidedicato superiore.
Se necessita di tale funzione può richiedere un upgrade al servizio semidedicato tramite il presente ticket al costo di 50€+iva
--
Inaccettabile.
vedi
http://www.onlinecronjobs.com/
http://www.wsscheduler.com/
http://cronless.com/
http://www.setcronjob.com/
http://www.webcron.org/
http://www.drupalcron.org/
oppure fai da te se hai una macchina sempre accesa
Certified to Rock
Altolà ragazzi !!!
Mi potete spiegate bene questa cosa del cron ?
Io uso poormanscron e l' ho configurato per eseguire il cron ogni 2 ore e mi va bene; perchè non dovrebbe andare bene ?. Siamo sicuri che conviene impostare il cron da server ?
@Lorenzo
Dai che 50 euro all' anno te li puoi permettere; il vantaggio non è solo il cron.
@Lorenzo sai cosa significa per il server un carico programmato? Anche loro si fanno i loro conti.
@giovanninews
Bastava leggere su e in giro per il web trovi mille altri motivi.
http://www.chromeos.eu
Il cron serve per la gestione delle operazioni pianificate in Drupal.
Il punto è che quando dici a Drupal di compiere una certa operazione ogni X minuti, ore o giorni (e parlo delle normali operazioni di manutenzione, come eliminare i file temporanei diventati inutili, o delle operazioni definite attraverso i moduli, ad esempio aggiornare un blocco scaricando un feed RSS da un altro sito/blog ogni 10 minuti), le cose non funzionano come uno si aspetta: Drupal, per ragioni varie, controlla le cose da fare solo su richiesta.
Insomma, se dico a Drupal di mostrarmi un blocco con le ultime notizie prese dal feed RSS di un certo sito e di aggiornarle ogni 10 minuti, questo non significa che Drupal ogni 10 minuti le aggiorna; significa che, quando chiedo a Drupal di controllare le cose da fare, se Drupal vede che sono passati 11 minuti (o anche tre giorni, basta che siano più di 10 minuti!) dall'ultima volta che ha compiuto questa operazione la compie. Notate che se io non chiedo mai a Drupal di controllare, queste operazioni non vengono mai fatte (e infatti Drupal lo segnala nello Status Report).
Bene, "chiedere a Drupal di controllare" è l'operazione che in gergo è definita "eseguire il cron". Farla a mano è banalissimo: basta aprire il file cron.php sul vostro sito (ad esempio http://drupalitalia.org/cron.php esegue il cron su questo sito) e il risultato, se tutto va bene, è una pagina completamente bianca. In Drupal 7 l'indirizzo è personalizzabile per evitare abusi, ma sostanzialmente le cose non cambiano.
Ho visto gente che esegue il cron su tutti i suoi siti in questo modo, cioè aprendo manualmente gli indirizzi nel browser (ad esempio mettendoli tutti in una cartella di preferiti di Firefox e poi aprendoli tutti ogni tanto). Benché sia una soluzione molto artigianale, funziona. E' chiaro che funziona anche la soluzione, equivalente ma molto più noiosa, di entrare come amministratore in tutti i siti uno per uno ed eseguire cron dallo status report.
Salendo di livello, è bello automatizzare il tutto. E ci sono due modi: usare il modulo poormanscron (in Drupal 7 è integrato nel core, in Drupal 6 è un modulo indipendente) o impostare un automatismo che scarica la pagina cron.php a intervalli regolari.
Poormanscron, in pratica (semplifico, vedete http://drupal.org/project/poormanscron per i dettagli), fa il controllo di cui sopra ogni volta che un utente apre una pagina del vostro sito. Questo rende il sito un po' più pesante in teoria, ma in molti casi il rallentamento non si nota neppure. Caso limite: se nessuno visita il vostro sito, poormanscron non viene mai eseguito.
Impostare un automatismo si fa invece come preferite: se usate un server basato su Linux, c'è il meccanismo cron nativo configurabile come negli esempi postati da altri qui sopra; ma dato che la chiamata a cron.php si fa via web, potete anche impostarla sul vostro PC di casa o su un qualsiasi sistema che permetta di fare operazioni pianificate, non c'è alcun bisogno che l'operazione pianificata sia configurata sul server o sul pannello di controllo del vostro hosting; forse si riesce a fare persino con le operazioni pianificate di Windows. Se lo pianificate in questo modo, cron viene sempre eseguito (a prescindere dal fatto che qualcuno visiti il vostro sito o no).
Io ritengo migliore farlo nel secondo modo (senza poormanscron) perché ho un controllo migliore e non svolgo operazioni inutili durante il caricamento della pagina; conosco però persone che per comodità preferiscono poormanscron e ne sono soddisfatte, e il fatto che Drupal 7 lo includa mi fa pensare che sia comunque un modulo che non ha effetti devastanti a livello di prestazioni.
http://nuvole.org
http://youthagora.org
Ah Giovanni, scusa se ero distratto, stavo ancora pensando agli ultimi "Bottoni di Bohz".
Cmq il cron dal server è importante, fa figo e pulisce il sito come mastrolindo.
--
Pescetti : aha ah : su molti siti io faccio il lavoro "più barboso" .. entro e attivo a manetta.
Però credo che se qualche Anima Buona ci mette mano sul serio, secondo me, riesce a farlo "un pò di codice Php", su un file, che prende il login di admin e fà il cron in automatico, al posto del mio ditino: ..lo dico cosi, giusto x non pagare agli Hosters 50 euri a botta ! e per non avere poormanscorn che qualche difettuccio/rognetta ce l'ha.. si che ce l'ha.
PS
Giovanni : 50 euri x circa 100 siti drupal sono 5.000 euri solo di CRONS .. cioè spendo più di telefonate che altro, a convincerli tutti..
compra un dedicato sono 2000€ per 100 siti, 20€ a sito e il resto lo puoi dare a me :-)
http://www.chromeos.eu
2000 euri x cento web è pensabile: è un pensiero vago che ho anchio da parecchio .. ma di chi fidarsi ?
se ti pappano i duemila e poi va tutto a schiffio ?
difficile vai da un hosting serio
http://www.chromeos.eu
@ealmuno : qualche esempio ?
perchè io non ne ho.. dico la verità : ognuno di quelli che conosco ha la "sua".
--
@bohz : perdonate la diffidenza, ma tutte queste ditte che forniscono "tutti questi servizi gratis Cron + Backup + tutto il resto", ma perchè lo fanno ? (Cronless-com, x es.)
Avranno un loro interesse/guadagno no ? o sono Opere Pie ?
Esempio : possiedono i tuoi dati per mailing list ?, possono fornire ciò che fai a terzi ? ..e tu manco lo sai .. sono Google Friends ? ..ecc..
Piacerebbe sapere, da chi ha più esperienza, perchè doversi registrare online (quando si potrebbe usare un sw e farsene ciò che si desidera, giusto per dirne un'altra) ?
Piacerebbe sapere se li avete usati e quali, secondo i Guru-drupal sono più affidabili e quelli un pò meno.
Questo anche per la privacy, intendendo "non la Mia Privacy" (che è inesistente da tempo immemore) .. quanto la riservatezza e la sicurezza della privacy per i siti fatti e da gestire c/terzi.
Scusate la pedanteria.. ma i dubbi ci sono, magari sono inesistenti : cosa ne pensate?
pure gli hosting qui citati offrono server dedicati su quei prezzi.
Se cerchi il server senza problemi e che non abbia mai down non esiste, si sceglie in base al supporto.
http://www.chromeos.eu
La perfezione no ma neppure che un fornitore ci metta 2 mesi per sistemare il server mail (net..) e un'altro ancora ci metta 3 mesi per farti lavorare sui "nuovissimi plesk siiweb" (mist..) dove è vietato dare un chmod 777 e (secondo lui) è Drupal che usa sistemi contestabili : come se fosse un Cms "che non capisce niente e che non è sicuro (?).
Altri esempi.
Parlando di bufale sui virtuali, per es., ho visto, anche se superficialmente e non ricordo ora il dettaglio, che diverse aziende di host pubblicano dettagli tecnici dichiarandoli come "veramente appropriati e funzionali".
Peccato che, andando dopo su alcuni forums, ho trovato i post di Esperti, i quali demolivano questi dati, dimostrando come fossero "aleatori e anche ingannevoli per l'utente" e dando, in aggiunta, tutte le indicazioni e le spiegazioni dettagliate per evitare di "farsi prendere in giro" da dati tecnici che sembrano ottimali ma in realtà non lo sono minimamente.
Non si tratta quindi di una "mina inesplosa" persa qua e là, dato che un blocco/calo momentaneo di down può capitare, si tratta invece di veri e propri campi minati dove alcune aziende di hosting non agiscono in modo lineare ed etico.
E se uno dice una cosa e poi ne fà un'altra : io inizio a credergli già un pò di meno.
Un altro esempio.
Se ti dico che su mister dice di avere image magik nei suoi services: ma io non l'ho mai vista, allora gli chiedo dove la directory (per digitarla dentro a drupal e fargliela prendere) .. e mister mi risponde cosi al ticket di help :
ma .. sà .. forse è questa.. però .. non sò .. provi, ma non credo funzionerà.
--
Magari sbaglio però credo che sia alquanto complicato "centrare obbiettivi" buoni (buoni in linea di massima, intendo) ed evitare queste odiose trappole, senza appoggiarsi ai consigli di chi ne sà "moltomolto" di più.
Anzi : se qualcuno ci ha picchiato il naso, tantomeglio, perchè saprà descriverci in dettaglio alcune esperienze concrete (da evitare).
D'altronde Cron è un discorso di rilievo, particolarmente per sitiweb di un certo peso di moduli e contenuti e utenze, accessi, iscrizioni, ecc. (credo).
@lorenzo: non è cosa nuova mi pare. hai presente i servizi di google o drupal gardens? il livello di entrata "free" garantisce la massa critica che permette il profitto dei servizi a pagamento. Almeno in teoria. del resto pingare un url ogni ora è meno di una caccola anche per il computer più disastrato ;) specialmente senza GUI
@pescetti: grazie per l'esaustiva spiegazione! ti confermo che con windows, installando wget, si puo' eseguire cron con gli "scheduled tasks" con una certa professionalità...
per quanto riguarda poormanscron, il caveat più importante a parer mio è non poter contare sulla regolarità dell'esecuzione. ad esempio per l'indicizzazione dei contenuti: può capitare che un nodo/utente venga eliminato e ricreato con un nuovo ID; finchè l'indice non viene aggornato, le ricerche che puntano a quella url daranno un bel risultato di errore. Se il nodo/utente in questione è importante per il sito (tipo la home page), può diventare un problema serio.
Certified to Rock
@bohz
Grazie per aver riportato la discussione sul tema principale, in quanto, ritenendola particolarmente interessante, ha rischiato di essere deviata da Lorenzo ed ealmuno.
Una piccola parentesi per Lorenzo ed almuno. Per Lorenzo: 50 euro all' anno non significa avere solo il cron, ma anche un limite di memoria PHP a 256 Mb (al contrario dei tuoi 64 o 128) e probabilmente anche qualcos' altro che io non utilizzo.
Per ealmuno: in un' altra discussione ti avevo chiesto se avevi un indirizzo per verificare, ma non hai risposto. Certo, avere un dedicato con 100 siti conosciuti, forse sarebbe una ottima soluzione, ma non credo che l' hosting te lo farebbe fare; un dedicato, come dice la parola, è un dedicato, al massimo ci puoi mettere altri siti tuoi, ma non credo di altri.
@Pescetti
Innanzitutto ti ringrazio per la risposta molto particolareggiata; personalmente, e chiedo scusa per la mia inesperienza, ho però qualcosa che mi porta in disaccordo.
L' esecuzione del cron dall' indirizzo web per me non porta affatto ad una pagina bianca, ma è essenziale farla quando l' esecuzione automatica con poormascron non ha avuto successo, in quanto, oltre ad esguire cron, riattiva correttamente poormascron; questo significa che per me è fondamentale controllare il log almeno una volta al giorno, sia per verificare la corretta esecuzione di cron che per controllare attacchi cracker sempre più frequenti (ieri un c99.php ed oggi un r57.php).
Dalla tua approfondita risposta, mi sembra di capire che l' automatismo da te preferito sia quello di schedulare un task da un pc remoto; ma questo non significa avere sempre il pc acceso e perennemente collegato ?
Credo di rientrare nel caso da te descritto "conosco però persone che per comodità preferiscono poormanscron e ne sono soddisfatte" perchè, nel mio caso, il rallentamento dovrebbe essere una ventina di secondi ogni 2 ore, il tempo di esecuzione di cron via poormascron.
Non capisco invece ealmuno quando dice che poormascron è dannoso lato SEO. Perchè ?
@Bohz
Perchè con poormanscron non si può contare sulla indicizzazione dei contenuti ?
Anzi, proprio nel mio caso che sto appena cominciando a capire qualcosa con Drupal, trovo particolarmente utile poormanscron (ed il cron in genere) in quanto sto ultimamente facendo una marea di redirect 301 con path_redirect ed ho proprio bisogno che le pagine siano puntate correttamente e che quindi la cache sia svuotata; in questo caso, per me, il problema è la lentezza con cui passano spider e motori di ricerca.
Per ultimo, ho indicato a poormascron di essere eseguito ogni 2 ore anche perchè, come detto da Pescetti, ho bisogno di scricare feed RSS da alcuni siti esterni.
In conclusione, quello che vorrei capire, conviene utilizzare poormanscron o creare un task da server (nel mio caso con CPanel) ? Il task da server esegue le stesse operazioni di poormascron ? Immagino che se abilito il task da server, poormascron deve essere disabilitato.
Grazie a tutti.
Preferisco non fare ancora nomi, comunque intendevo mettersi d'accordo fra di noi, ovvio che non puoi farlo con sconosciuti.
Avevo trovato la discussione sui problemi al seo mesi fa ma non riesco più a recuperarla.
http://www.chromeos.eu
Sicuro? Se apri http://www.drupalitalia.org/cron.php non vedi una pagina bianca? Puoi fare la stessa identica cosa sul tuo sito, ed equivale ad eseguire cron dal pannello di controllo di Drupal dopo essere entrato come amministratore (in quel caso non vedi una pagina bianca perché il pannello ti reindirizza).
Non lo faccio dal mio PC personale... Io ho un certo numero di server web basati su Linux sempre collegati; per i clienti che lasciano il loro sito su uno dei miei server, uso il cron locale; per i clienti che invece portano il sito sul loro server, pianifico le operazioni su uno dei miei server per evitare di dipendere dall'hosting che scelgono.
No, il rallentamento ce l'hai ogni volta che qualcuno carica una pagina, perché poormanscron controlla a ogni caricamento di pagina se è il momento di eseguire un'operazione pianificata; tuttavia è un rallentamento molto modesto e trascurabile nella maggior parte dei casi.
Eseguono le stesse operazioni. Puoi anche tenerli entrambi e non succede niente, ma è un'inutile duplicazione.
http://nuvole.org
http://youthagora.org
- bene, vedo che la discussione è diventata molto utile
- argomenti ev. accessori ..possono capitare in discorsi tra persone: forse non succederà tra 2 robots meccanici.
@Bohz : l'altro giorno era irraggiungibile http://www.drupalcron.org/ .. poi si è ripreso è ho letto del modulo, che proverò.
Lo metto su un sito senza poormanscron.
--
Aggiungo un'ultima "devianza" :
Per chi è a secco sul discorso Cron consiglio la lettura di Matteo85 che è una ulteriore nota conoscitiva dei problemi cron:
http://www.cmswiki.net/content/crontab-drupal-configura-i-cron-jobs-serv...
-- grazie a tutti e buona sera--
@pescetti
E' vero, vedo una pagina bianca, ma quello che intendevo è che, controllando sul log, vedo che la richiesta di cron è stata eseguita correttamente. Non so cosa implica invece avere una pagina bianca come risultato visivo. Una cosa che invece vedo dal log è che cron eseguito via poormascron esegue anche aggregator, cosa che invece non fa se eseguo cron dall' indirizzo web, e questo è fondamentale.
Nel mio caso quindi, non avendo server personali, dovrei impostare cron sul mio server.
Questa non la sapevo e la ritengo fondamentale per provare cron da server nel sito di test (anche se il sito di test è perennemente offline, cron è lo stesso eseguito).
Quello che mi manca è l' esecuzione di aggregator.
Grazie, ti farò sapere.
Allora, il primo risultato è un fiasco.
Impostando il cron da server (con CPanel) con una notifica email, dopo un' ora ho ottenuto 60 email di errore inviate una ogni minuto del tipo:
/bin/sh: indirizzo-web/cron.php: No such file or directory
Presumo che i motivi siano due:
Primo: ho sbagliato ad impostarlo
Secondo: per farlo eseguire cron dal sottodominio di test forse devo mettere come comando da eseguire /root/cartella-sottodominio/cron.php
Provo per ora a cambiare l' impostazione.
Provando con wget-O --q-t 1 http://test.miosito.com/cron.php ottengo come risultato /bin/sh: wget-O: command not found. In compenso la schedulazione sembra corretta.
Provo con /usr/bin/wget-O --q-t 1 http://test.miosito.com/cron.php sperando che sia la volta buona.
Risposta:
/bin/sh: /usr/bin/wget-O: No such file or directory
Cavolobis.
OK !
Il cron da server, al contrario di poormanscron, per funzionare necessita che il sito non sia in stato di manutenzione.
Per impostarlo correttamente da CPanel, il comando da eseguire è:
/usr/bin/wget -O - -q -t 1 http://www.example.com/cron.php
Bisogna fare molta attenzione agli spazi.
Il cron da server esegue correttamente anche aggregator.
L' e-mail sembra che viene inviata solo se il cron job ha avuto problemi di esecuzione.
Per la precisione (se stai usando un server basato su Linux come immagino) cron invia un messaggio di posta elettronica se il suo output non è vuoto (il -q tra le opzioni di wget dice di sopprimere l'output normale e di segnalare solo gli errori, per cui è corretto quello che dici: se il sito è irraggiungbile, ad esempio, riceverai un messaggio).
http://nuvole.org
http://youthagora.org
@pescetti
Grazie per l' info; a questo punto dovrei chiedere qual' è l' opzione di wget per segnalare anche l' output normale (non credo che sia semplicemente togliere -q).
Ma probabilmente questo è chiedere troppo.
Ciao e grazie di nuovo.
Sì, basta togliere "-q", non serve tanta fantasia... l'elenco delle opzioni è su
http://www.gnu.org/software/wget/manual/wget.html#Basic-Startup-Options
(scorri la pagina verso il basso)
Tieni presente che wget è un programma di download, quindi il suo output non ha nulla a che fare con Drupal. Per intenderci, sulla mia macchina l'output di "wget http://www.drupalitalia.org/cron.php" senza opzioni è semplicemente:
--2011-03-29 00:10:31-- http://www.drupalitalia.org/cron.php
Risoluzione di www.drupalitalia.org... 81.174.68.55
Connessione a www.drupalitalia.org|81.174.68.55|:80... connesso.
HTTP richiesta inviata, in attesa di risposta... 200 OK
Lunghezza: non specificato [text/html]
Salvataggio in: "cron.php"
[ ( = ) ] 0 --.-K/s in 0s
2011-03-29 00:10:31 (0,00 B/s) - "cron.php" salvato [0]
e mi scarica un file vuoto di nome "cron.php" (che a te non scarica perché usi l'opzione "-O -" che è un caso particolare in cui il file scaricato non viene salvato ma mostrato all'utente, quindi nel tuo caso a questo output verrebbe aggiunto il contenuto del file scaricato, che tuttavia è vuoto; se c'è un errore di qualsiasi tipo lo riceverai via e-mail, se tutto tace va tutto bene).
http://nuvole.org
http://youthagora.org
Uahu !(grande!)
Non immaginavo che si potessero fare tutte quelle cose. Questa me la segno. Magari un giorno riuscirò a configurarlo per farmi avvisare per e-mail quando provano ad attaccare il sito (e magari rilanciare in automatico una routine di contrattacco).
Scusate ragazzi ma ho un po di confusione in testa per quanto riguarda cron e wget:
wget non server per scariare file dalla rete? non capisco il suo funzionamento col file cron.php di drupal per capirci.
Guarda la path, per eseguire il file devi accedere a quel file ed appunto con il wget ci riesci che non viene lanciato come parametro ma è il percorso
http://www.chromeos.eu