XF 1.2 1.2.3 Cron Entries Not Running

[Divvens]

One of my users told me that he should have received a trophy, and for the past 12 hours even though he reached the criteria he hasn't received the trophy.

I'm running 1.2.3, and it seems my cron entries are all stuck in the past, it's currently 4:16 AM GMT (24th), I'm given to believe that cron entries are shown in GMT Was mistaken about it, it was stuck in 4:16 AM my local time.

However, all of them have a next update time of 24th (past), and the cron entries don't seem to be running

 

[Divvens]

I've got it to work after reading a few other threads, I see that the time in Cron Entries actually shows my local time setting,

I disabled one of the crons and re-enabled it, it has since updated and not stuck in the past anymore.

Any reasons why this would happen? My page_container template isn't modified, and the only add-on that adds a cron entry is Sitemaps by @Rigel Kentaurus which has been working without problems since installation.

 

[Divvens]

I have tried to see if the cron created by the add-on caused this problem by running the cron out of its scheduled time, after the cron was run the other crons also run properly. So it seems this issue isn't related to the add-on (it never had a problem to begin with).

Did something possibly change from 1.2.2 to 1.2.3, or maybe this is a issue that is effecting only my board? If so, how do I debug to find out the possible causes of the issue?

Edit:
Found an issue here in this thread that said the feeder cron was causing an issue, would like to clarify that I do not have any RSS Feeds that create content, so the issue is not similar.

Edit 2:
I have disabled the feeder cron entry, it isn't used on our board and I'll notice if that was the one causing the problem.

 

[Mike]

I spent a while debugging this for someone over the weekend (the linked thread). As far as I could tell, the script was being semi-randomly killed while it was running. The cron script would start to run actually be killed before anything had actually run in it, but enough had been started such that other parts of the system thought it had run. If that's what's happening here, it's really rather nightmarish to sort in code because nothing can truly be trusted to run.

So I'd check if there's any info logged at the server level regarding processes being killed or the like.

1.2.3 starts the cron and immediately tells it to run in 5 minutes in case there's a fatal error. Then it runs the pending cron(s). If they run successfully, it then automatically detects the correct next run time. (The script was getting killed between starting and setting the next run time -- very hard to deal with from a code perspective.)

 

[Divvens]

I spent a while debugging this for someone over the weekend (the linked thread). As far as I could tell, the script was being semi-randomly killed while it was running. The cron script would start to run actually be killed before anything had actually run in it, but enough had been started such that other parts of the system thought it had run. If that's what's happening here, it's really rather nightmarish to sort in code because nothing can truly be trusted to run.

So I'd check if there's any info logged at the server level regarding processes being killed or the like.

1.2.3 starts the cron and immediately tells it to run in 5 minutes in case there's a fatal error. Then it runs the pending cron(s). If they run successfully, it then automatically detects the correct next run time. (The script was getting killed between starting and setting the next run time -- very hard to deal with from a code perspective.)

I run on a shared host, can I access the logs of processes being killed via cPanel, or should I get my host to check it for me?

 

[Mike]

You might be able to see something in the Apache error log, but I would ask your host (though if I'm honest, I wouldn't expect much from them).

 

[Divvens]

You might be able to see something in the Apache error log, but I would ask your host (though if I'm honest, I wouldn't expect much from them).

Our server runs LiteSpeed, the error log is clean in cPanel, I've contacted my host, what they said is that processes getting killed is unlikely since that only happens in an event if we exceed the given resources (which we haven't).

It is exceedingly rare for a process to be killed on our service, and there is no reason to suspect this is the issue unless your account is already using substantially more resources than it is allocated. Instead, our system queues processes that exceed your allocation, or simply refuses connections if that queue is full.

 

[Mike]

Well, please let me know if it happens again then. I really see no reason for it to happen unless a process gets killed.

Just to double check, are there any errors logged in the control panel that might be related?

 

[Divvens]

Well, please let me know if it happens again then. I really see no reason for it to happen unless a process gets killed.

Just to double check, are there any errors logged in the control panel that might be related?

I'll let you know if this repeats again Mike, it hasn't since this morning after I disabled and enabled + refreshed one of the cron entries.

There are no errors logged either in ACP (xF) or in the cPanel error log, double checked it

 

[Luke F]

I've had this happen on my live board - was resolved by setting next_run manually in the database. For some reason the next run times were all several days in the past - surely the logic should handle this?

If it makes a difference I am using the RSS feeder and a system cron calling deferred.php via curl every minute

 

[Divvens]

Just had the problem repeat, it looks like for the past 9 hours the cron stopped running. Since its a weekend I didn't submitted a ticket, I just disabled and enabled a cron entry and refreshed to fix it.

If it occurs again during a week day I'll open a ticket on xenForo. All error logs are clean and nothing has been logged (xenforo or control panel error log).

 

[Mike]

I've spent extensive time debugging this for someone and the only reason I could see for it was the process getting killed (very quickly after it started actually). There's very little that we can do to truly prevent that if this is the case.
The only way it fails is if the cron actually starts successfully but stops before one of the first lines in it (before any actions are actually run).

There are a couple more tweaks coming in 1.2.4, but we're definitely getting into diminishing returns here.

 

[Divvens]

@Mike 1.2.4 seems to have fixed any problems that we were facing with Cron Entries Was running 1.2.4 from the day it released, and the Cron Entries haven't bugged out even once.