!! IMPORTANT !!
We are currently on vacation with NO (or very limited) internet connectivity, so support tickets replies are likely to be delayed. We'll be fully back on July 12th. Sorry!
We are based in Europe with a GMT+1/GMT+2 time zone - support replies may be delayed due to time zone differences with your country.
- This topic has 19 replies, 2 voices, and was last updated 4 years ago by
.
-
Posts
-
Ciao Stefano, rieccomi 🙂
Ti spiego cosa è successo:1) 1 luglio, dopo il recupero automatico dei dati da Analytics effettuo il pagamento a tutto giugno
2) 3/4 Luglio ho avuto dei problemi con i cronjobs e quindi mi ritrovo con dati mancanti
3) Stamattina (6 luglio) ho forzato il ricaricamento da Analytics dal 1 luglioI saldi ora sono in negativo. Cosa ho sbagliato?
Ciao Simone,
probabilmente il problema è solo dato dal fatto che prima avevi dati antecedenti al 1 Luglio. Dovresti provare a ricaricare i dati, come hai già fatto, ma con una data iniziale più vecchia. Non saprei dirti esattamente che giorno, dipende da che giorno avevi inserito al caricamento precedente 🙂Buona giornata,
StefanoMi sembra fosse il 21 febbraio, ripartirò da li.
Ho però un altro problema, le righe in attesa me le processa solo quando aggiorno la pagina ppc-options eppure ora i cronjobs funzionano bene (verificato con WP Control).
Non è normale, vero?
Ho però un altro problema, le righe in attesa me le processa solo quando aggiorno la pagina ppc-options
Questa è una scelta volontaria per evitare ogni tipo di rallentamento indesiderato nelle altre pagine amministrative. Le righe vengono processate solo quando vengono caricate delle pagine del plugin (opzioni/stats per esempio). Normalmente, quando ci sono qualche centinaia di righe in attesa, basta che 3 o 4 utenti carichino le statistiche perché le righe vengano processate tutte. Su caricamenti di dati manuali, può volerci un po’: su numeri molto grandi io mi affido a estensioni di ricaricamento automatico della pagina per Chrome, e in una decina di minuti tutte le righe vengono smaltite con refresh automatici di 15 secondi 🙂
Ah ok, era per capire. Meglio così.
Ho messo il refresh automatico anche io, ti faccio sapere com’è andata
Ok è tornato tutto apposto con i saldi corretti.
Tanto per capire, se mi dovesse ricapitare, devo scaricare sempre i dati dal 21 febbraio? Oppure dalla data di oggi?
Sempre al 21 febbraio. Tra l’altro, dovrebbe già comparire la data corretta nel campo di selezione delle data 🙂
Rieccomi Stefano, come la volta scorsa, anche oggi non riesce a scaricare i dati.
Questo è il LOG che si ripete ogni 5 minuti dalla partenza del cronjob:
8 luglio 2017 15:43:12
An error was thrown with code “ga_read_temp_file_single_error”, message “Errore: non è stato possibile acquisire il blocco sul file temporaneo.” and debug data “array (
‘file’ => ‘/var/www/vhosts/xiaomitoday.it/httpdocs/wp-content/plugins/post-pay-counter-pro/temp/ga/ppcp_ga_request_data_temp_1499514005.5197.txt’,
)”.AH dimenticavo, il file esiste, anche se ha un contenuto (credo) criptato.
Inoltre fino ha ieri non avevo avuto più problemi ed il log degli errori era vuoto.Fermo restando che posso sempre riscaricare tutto il periodo, ma vorrei cercare d’intercettare il problema.
Ciao Simone,
suppongo che l’errore persista? Le righe da processare non sono calate?Quando, durante un caricamento di pagina, il plugin elabora alcune righe, tenta di bloccare il file da cui le legge per evitare che un caricamento contemporaneo possa elaborare le stesse righe e duplicare visite. In generale, errori come il tuo non sono preoccupanti: il plugin sta semplicemente avvertendo che, probabilmente a causa di due caricamenti contemporanei, è fallito il blocco del file da leggere. Pazienza, ci si riproverà al caricamento successivo. I dati, tuttavia, sono già stati scaricati e devono solo essere elaborati.
Sarei stupito, quindi, se anche a distanza di ore ci fossero ancora righe da processare 🙂
Fammi sapere,
StefanoPurtroppo le righe in attesa erano 455 quando ti ho scritto e così sono rimaste.
Il plugin sta riprovando ogni 5 minuti ma restituisce sempre lo stesso errore.8 luglio 2017 22:46:10
An error was thrown with code “ga_read_temp_file_single_error”, message “Errore: non è stato possibile acquisire il blocco sul file temporaneo.” and debug data “array (
‘file’ => ‘/var/www/vhosts/xiaomitoday.it/httpdocs/wp-content/plugins/post-pay-counter-pro/temp/ga/ppcp_ga_request_data_temp_1499514005.5197.txt’,
)”.Okay, allora fai questa prova: vai nel percorso indicato dell’errore e rinomina quel file, aggiungendo un qualche numero prima dell’estensione txt.
Per esempio, fallo diventare
ppcp_ga_request_data_temp_1499514005.519700.txtFammi sapere!
Stamattina, prima che leggessi il tuo messaggio, ho provveduto al ri-download dell’intero periodo.
Farò quella prova se dovesse ricapitare, ma speriamo di no 🙂
Come al solito sei sempre disponibile, grazie.
Ieri sono stato via tutto il giorno ma stamattina ho realizzato che l’errore si è ripresentato.
Nel log di apache però ne ho trovato il motivo, è zeppo di questi 2 errori ripetuti
[Tue Jul 11 05:31:28.807070 2017] [:error] [pid 13265] [client 188.114.102.207:31890] PHP Warning: fopen(/var/www/vhosts/[URL_NASCOSTO]/httpdocs/wp-content/plugins/post-pay-counter-pro/temp/ga/ppcp_ga_request_data_temp_1499663403.0588.txt): failed to open stream: Permission denied in /var/www/vhosts/[URL_NASCOSTO]/httpdocs/wp-content/plugins/post-pay-counter-pro/classes/ppcp_google_analytics_class.php on line 761, referer: https://[URL_NASCOSTO]/wp-admin/admin.php?page=stats
[Tue Jul 11 05:31:28.807107 2017] [:error] [pid 13265] [client 188.114.102.207:31890] PHP Warning: flock() expects parameter 1 to be resource, boolean given in /var/www/vhosts/[URL_NASCOSTO]/httpdocs/wp-content/plugins/post-pay-counter-pro/classes/ppcp_google_analytics_class.php on line 763, referer: https://[URL_NASCOSTO]/wp-admin/admin.php?page=statsLe 2 cartelle Temp e GA hanno permessi 755. Hai qualche suggerimento?
P.S. Per motivi di sicurezza ho nascosto la url con [URL_NASCOSTO] ma i path sono ovviamente corretti
Ciao Simone,
Scusa il ritardo!Puoi provare a riassegnare i permessi 755 alla cartella temp, facendo attenzione a spuntare l’opzione che applichi la modifica anche a tutte le sottocartelle e file in esse contenute. Aiuta?
Buona giornata,
StefanoSto monitorando la situazione e questo è quello che succede:
In pratica, come ti accennai, in passato il wp-cron veniva richiamato da un servizio esterno. Per alleggerire il carico di apache abbiamo da poco passato tutto sul cron interno del server.
Succede però che alcuni dei file non hanno i permessi per apache ed ovviamente non possono essere poi successivamente elaborati. Da li, l’errore “Permission denied” del log.
Mi basta dare un chown a quel file per risolvere.
Nelle 2 prove fatte, il file incriminato è sempre stato il primo di quelli generati. Ma forse 2 prove non fanno ancora testo.
Sto cercando di venirne a capo con un amico sistemista più bravo di me, ma visto che sei lo sviluppatore del plugin forse riesci ad avere un idea del perché di questo comportamento. Hai suggerimenti?
Ciao
Ora che mi dici queste cose, una cosa da verificare mi viene in mente. Se i permessi della cartella sono corretti, ma i file che vengono creati al suo interno non hanno i permessi corretti, forse è il processo sotto cui gira Apache che, per qualche motivo, crea file con permessi limitati. Questo può essere un terreno d’indagine; tuttavia, l’utente del processo di Apache dovrebbe comunque esserne il proprietario quindi non dovrebbero esserci problemi di alcun tipo… E’ un problema che però non è mai stato riportato, quindi al 99 è qualcosa che ha a che fare con la specifica configurazione del tuo server 🙂
Da parte mia, se nelle prossime ore non riesci a risolvere, aggiungerà un chmod nel codice che assegni permessi 755 al file e ciò dovrebbe mandare le cose a posto…
Fammi sapere!
Buona giornata,
StefanoSi esatto, è molto strano che solo il primo file abbia come proprietario l’utente ROOT. Gli altri www-data. In teoria sono generati dallo stesso processo cron.
Faccio qualche altra indagine e ti faccio sapere
- The topic ‘Problema con il recupero dei dati di Analytics’ is closed to new replies.