[BUG] actualize_script.php not updating feeds

[mattisphere]

Describe the bug
Noticed the feeds weren't updating. Checked chron, command still there and manually ran the update, no feeds updating. Manual update works.

• Replaced actualize_script.php and made sure www-data was owner
• Deleted the cache

To Reproduce
Run actualize_script.php

Expected behavior
Feeds be updated

Screenshots

Environment information (please complete the following information):
Ubuntu, nginx
Non-docker

[Alkarex]

Hello,
Please provide the usual details: FreshRSS version, PHP version, etc.
Anything in the Web server logs, FreshRSS logs, in /tmp/FreshRSS.log...
And please try the current edge branch of FreshRSS

[The-Michael-R]

It seems that I have the same/similar problem.

From my observations the cron job takes often too long and my hoster terminates it after 120 seconds. The manual update via web interface seems fine and take less than a minute. And that seems to help the actualize_script.php script as for the following actualize-task is less to do. The following updates take less than the 120 seconds (see below). But as soon as too many new articles are there it never finish in time from that time on. Until I force the manual update.

The problem seems to happen since the last update to 1.22.1 (forgot which the previous one was but that previous version was the latest that came via web-updater, so probably 1.21.0).

The actualize_script.php took here 1:43 Minutes to update 35 RSS feeds resulting in 20 unread articles:

FreshRSS starting feeds actualization at 2023-12-02T22:05:01+01:00
FreshRSS actualize Michael…
FreshRSS actualization done for 1 users, using 14.00 MiB of memory, in 0 day(s), 0 hour(s), 1 minute(s) and 43 seconds.
Results: 
Michael OK
End.

Given, that server isn't the highest performance one, but the update via Web-Interface take far less than a minute to do the same trick. And the bandwidth with > 10MB/s should be sufficient.

I can't find and FreshRSS.log file anywhere; there's a tmp folder I have access to but not such a file. The for me accessible server and PHP logs doesn't show any issues.

My server uses PHP 8.1.20.
FreshRSS 1.22.1
~35 RSS feeds, 1 806 articles (6.95 MiB)

Purge the database and purge the user doesn't help.

Experimenting is a but cumbersome due to the time-limits prevent to update too often as it will just return:

FreshRSS feeds actualization was already running, so aborting new run at 2023-12-02T21:55:01+01:00

[Alkarex]

@The-Michael-R Your case is probably different than the parent. In your case, try to check the syslog if you have access to it to see a log of all the requests. If it takes that long, it can be some feeds that are answering very slowly. It can also be that you use some full content retrieval, which generates many requests. A difference when refreshing via the Web interface is that 10 feeds are refreshed in parallel, so if one of them takes one minute, it is not so noticeable.

[The-Michael-R]

@Alkarex,
After some additional checks what's going on. I see that the problem is bigger. as some feeds haven been updated since the try to solve the problem by "Manage Users --> user --> Purge". I think I'll fresh install and import the feeds via OPML.

And if needed I'll open a different issue.

---

Some feedback to your questions that might be obsolete by doing so:

Unfortunately I don't have access to the syslogs (it's a webserver with very limited SSH access). Maybe if I can't fix the problem I'll see if I can run FreshRSS in a local VM where I have full control.

OK, that the cron job does only issue sequential requests while the web interface can issue multiple in parallel this could explain the difference for the execution time. But why did it work earlier on?

I can't find an option to change any full content retrieval. If that comes with an extension: I only have "Fixed Nav Menu" and "Mobile Scroll Menu" enabled (both seem not to have impact to the update process).

In the FreshRSS logfile I noticed a huge block of ~300 SQL errors issued in the same second last month, they might be aligned with my update to 1.22.1:

SQL error searchById ["HY000",2014,"Cannot execute queries while other unbuffered queries are active. Consider using PDOStatement::fetchAll(). Alternatively, if your code is only ever going to run against mysql, you may enable query buffering by setting the PDO::MYSQL_ATTR_USE_BUFFERED_QUERY attribute."]

[Alkarex]

@The-Michael-R Could you try this patch #5916 to better debug your SQL error?

[The-Michael-R]

Hi @Alkarex,
installed 1.22.1 from scratch (new MySQL DB, new folder) with #5916 patch on Webserver same issues (not all Feeds are updated, long updater time, no error logs found anywhere). I'll check if the database issue re-appears.

Currently I switched back to 1.21.0 which seems to behave a bit more robust (might be just a feeling). But indeed I see long cron runs.

Will do more tests later on a local VM to see if I can figure out more. But not this week.

Any findings will be in a new ticket.

[Alkarex]

Please try again the edge version, which has fixed related issues

[The-Michael-R]

@Alkarex A short test looks like you nailed it 👍. All feeds seems to be updated right from the beginning (that wasn't the case earlier). And the update-time looks reasonable ~25 seconds for 51 feeds and 10 new articles. I'll keep it running in parallel with my production version. I just patched the lock-file name to prevent any collisions.

Also the protocol looks clean. But that's what I would expect for a clean install with a new database.