Backwpup next run schedule resetting to December 31, 1969

Hello,

did you have the lastes Version? There it schuld be fixed. Else i must become a installation where the problem occoures.

If you save the job again it will be automaticly corerected.

Thank you for the response, Daniel.

I keep the plugins up to date, so I assumed it is the latest version. It is version 3.1.4.

Manually going to Jobs -> Edit -> Schedule and clicking the Save Changes button did indeed reset the next scheduled run time correctly. One job is set to run daily, so I’ll know tomorrow if it automatically schedules the next run correctly.

The issue still persists.

The job that got correctly scheduled by my re-saving it has had its Next Run date reset to December 31, 1969. And, the job did not run. It is a daily job, and the last time it ran was six days ago when I ran it manually.

Is there something I need to do to help you resolve this?

Lee

Did you have installed a chaching plugin like W3TC ?

You can provide me the setting for the schdeule than i can test with it.

There is no caching plugin installed. I am using iThemes Security, Wordfence Security, WordPress SEO, and WP-SpamShield (plus others I can list if needed) if that makes any difference.

The schedule is set with:
Start job: with WordPress cron
Scheduler type: basic
Scheduler: daily 3:0 (3am)

Sorry, but looks all normel.

Come to find out, this is not caused by an invalid date being stored in the database, because WP-Cron does not store dates (timestamps) directly but serializes the data to a string before storing.

I have determined that the particular issue I am experiencing is caused by two things:

1. Line 212 of class-page-jobs.php has faulty logic. With a ‘gmt_offset’ option value of anything other than zero, the test will always return True even if wp_next_scheduled() returns False. This causes date_i18n(), on line 213, to return “December 31, 1969” if the job is not scheduled; instead of correctly reporting that the job is, ‘Not scheduled!’

2. When it comes time to run the single event, the event is removed from the WP-Cron schedule. But, it does not get rescheduled, because the BackWpup job (which would also reschedule the single event), as far as I have been able to determine so far, never runs.

I tried instituting some event logging in the Cron and WPBackup systems to try and see where the disconnect might be. But, it must be getting late, because I’m sure what took the site offline was a 500 Internal Server Error. I’ll try again later after I’ve had some rest to clear my bleary eyes.

To help determine the cause of #2, where would be the best place(s) to put some event logging:
BackWPup_Job::start_http(),
BackWPup_Job::start_wp_cron(),
BackWPup_Job::run(),
BackWPup_Cron::run(), and/or
BackWPup_Cron::cron_active()?

Lee

After more testing, I have discovered that:

1. wp-cron.php is indeed firing the ‘backwpup_cron’ event by calling do_action_ref_array() with that tag, but …

2. do_action_ref_array() is simply returning without calling the user function, because $wp_filter['backwpup_cron'] is not set.

I have gone as far as I can to help diagnose the problem.

I decided to use a ‘real’ cron job. But, that was not without its own set of frustrations.

First, “@$1php” at the start of the second line in the ‘start script’ (“BackWPup_cmd_start_job_1.sh”) caused an error:
“@php: command not found”

After fixing that, PHP gave me another error (“option not found r”), because the webhost has disabled the ‘run’ (“-r”) option for php.

So, I converted the shell script to a PHP script and launched it with php. That produced:

“Set-Cookie: bb2_screener_=1422648002+23.28.34.110; path=/
Set-Cookie: PHPSESSID=cff583bedd412c851906aa7318c608a3; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-type: text/html”

And, the job did not run. Probably because of this line in BackWPup_Job::start_cli(): if ( php_sapi_name() != 'cli' ) return;

The webhost’s PHP_SAPI is “cgi-fcgi”.

I ended up having to use lynx -dump with the appropriate (“Start job”) link to get automated backups working.