EPrints Technical Mailing List Archive

See the EPrints wiki for instructions on how to join this mailing list and related information.

Message: #10406

< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

Re: [EP-tech] IRStats2 issue: process_stats processes raw logs (2021–2026) but irstats2_cache_downloads stops at April 2026

CAUTION: This e-mail originated outside the University of Southampton.
First thing I would check is that the stats cron job is not running and then look at database table irstats2_internal to see if it has an entry set to prevent the job from running multiple times concurrently.

From the top of my head it would be called something like “access_lock” with a value of ‘1’ .  This is created when the cronjob runs and deleted near the end of the process and will have stopped the process from picking up new records if the processing was terminated abnormally in April and this record not removed.

If you are sure no irstats2 processes are currently running, you can delete this record from the data and the cronjob should then catch up, though it may take a long time for 4 months of backlog.

Alan

From: eprints-tech-request@ecs.soton.ac.uk <eprints-tech-request@ecs.soton.ac.uk> on behalf of Abid Fakhre Alam <abidfakhrealam@gmail.com>
Date: Friday, 7 August 2026 at 11:25
To: David R Newman <drn@ecs.soton.ac.uk>; eprints-tech@ecs.soton.ac.uk <eprints-tech@ecs.soton.ac.uk>; justin@soton.ac.uk <justin@soton.ac.uk>
Subject: [EP-tech] IRStats2 issue: process_stats processes raw logs (2021–2026) but irstats2_cache_downloads stops at April 2026

External email: if the sender or content looks suspicious, please click the Report Message icon, or forward it to report-phishing

CAUTION: This e-mail originated outside the University of Southampton.
CAUTION: This e-mail originated outside the University of Southampton.
Hi EPrints Community,

I am running into an issue with IRStats2 on an EPrints 3.4 server hosting multiple repository archives on a single instance (target Archive ID: purejguopjindal).

However, when running incremental stats processing:
/opt/eprints3/archives/purejguopjindal/bin/stats/process_stats purejguopjindal --verbose

The process completes without throwing fatal errors, but the aggregated cache table irstats2_cache_downloads (and public abstract pages) only populates statistical data up to April 2026. Statistics from May 2026 through August 2026 are not aggregating into the cache.

System Details & Environment:

Despite this, the monthly cache aggregation halts at April 2026.

Has anyone encountered an issue in multi-archive setups where process_stats skips aggregating raw logs past a certain date boundary into irstats2_cache_* tables? Could this be related to a specific date formatting/timestamp threshold in the IRStats2 Perl code or MySQL 8 date handling?


Thanks and Best Regards,
Abid Fakhre Alam