• Resolved gt1329a

    (@gt1329a)


    I’m seeing all attempts to run a backup, whether scheduled, manually triggered, or initiated via the debug function, stall at 0%. This is on a WordPress installation on a Linode VPS where UpdraftPlus was working previously for nearly a year.

    As far as I can tell, wp-cron is working okay. I’ve looked via Crontrol and have verified that I’m seeing wp-cron requests in the access logs and they’re responding with 200s. Also, UpdraftPlus’ retries after 300 seconds are happening if I wait.

    This is an example of the UpdraftPlus log file I’m seeing:

    0000.000 (0) Opened log file at time: Mon, 16 Mar 2015 05:23:01 +0000 on https://encosia.com/blog
    0000.002 (0) UpdraftPlus WordPress backup plugin (http://updraftplus.com): 1.9.60 WP: 4.1.1 PHP: 5.5.9-1ubuntu4.6 (Linux linode-1 3.18.5-x86_64-linode52 #1 SMP Thu Feb 5 12:18:36 EST 2015 x86_64) MySQL:  Server: Apache/2.4.7 (Ubuntu) safe_mode: 0 max_execution_time: 900 memory_limit: 256M (used: 12M | 12.3M) multisite: N mcrypt: Y LANG: C ZipArchive::addFile: Y
    0000.003 (0) Free space on disk containing Updraft's temporary directory: 15478.3 Mb
    0000.006 (0) Tasks: Backup files: 1 (schedule: daily) Backup DB: 1 (schedule: daily)
    0000.008 (0) Requesting semaphore lock (fd)
    0000.009 (0) Semaphore (fd) was stuck, set lock time to 2015-03-16 05:23:01
    0000.011 (0) Semaphore (fd) reset to 1
    0000.012 (0) Set semaphore last lock (fd) time to 2015-03-16 05:23:01
    0000.013 (0) Semaphore lock (fd) complete
    0000.018 (0) Backup run: resumption=0, nonce=45bd41aaaa0e, begun at=1426483381 (0s ago), job type=backup
    0000.021 (0) Scheduling a resumption (1) after 300 seconds (1426483681) in case this run gets aborted

    I also tried setting up a manual backup trigger here, using this PHP:

    <?php
    define('WP_DEBUG', true);
    define('UPDRAFTPLUS_CONSOLELOG', true);
    define('DOING_CRON', true);
    require_once('wp-load.php');
    do_action('updraft_backup_all');
    ?>

    All of my plugins are up to date. WordPress is up to date. Everything else seem to be working normally.

    Any suggestions? What’s the bit about the semaphore being stuck?

    https://wordpress.org/plugins/updraftplus/

Viewing 15 replies - 1 through 15 (of 18 total)
  • Plugin Author David Anderson

    (@davidanderson)

    Hi,

    It looks like PHP crashes at an early stage. If you check the PHP error log, then that should give information on why. I see you’re on Ubuntu, though, so I’d guess that Ubuntu is still shipping a buggy PHP version. There’s a fix here:

    https://wordpress.org/support/topic/zlib-problem-in-ubuntu-1404-backups-wont-work?replies=2

    David

    Thread Starter gt1329a

    (@gt1329a)

    I have this in my functions.php to cover that, which seemed to be working okay until recently:

    if (!function_exists('gzopen')) {
    function gzopen($filename , $mode, $use_include_path = 0 ) { return gzopen64($filename, $mode, $use_include_path); }
    }

    Where should I look for other PHP errors?

    I’ve tried enabling debug mode in WordPress and sending that to a log file. I see some deprecation notices, but no errors when I trigger a backup. These are the deprecation notices I’m seeing for each request, if it’s relevant:

    [16-Mar-2015 14:27:03 UTC] PHP Notice:  add_option was called with an argument that is <strong>deprecated</strong> since version 2.3 with no alternative available. in /var/sites/Encosia.com/public_html/blog/wp-includes/functions.php on line 3497
    [16-Mar-2015 14:27:03 UTC] PHP Notice:  WP_User->id was called with an argument that is <strong>deprecated</strong> since version 2.1! Use <code>WP_User->ID</code> instead. in /var/sites/Encosia.com/public_html/blog/wp-includes/functions.php on line 3495
    [16-Mar-2015 14:27:03 UTC] PHP Notice:  WP_User->id was called with an argument that is <strong>deprecated</strong> since version 2.1! Use <code>WP_User->ID</code> instead. in /var/sites/Encosia.com/public_html/blog/wp-includes/functions.php on line 3495
    [16-Mar-2015 14:27:03 UTC] PHP Notice:  WP_User->id was called with an argument that is <strong>deprecated</strong> since version 2.1! Use <code>WP_User->ID</code> instead. in /var/sites/Encosia.com/public_html/blog/wp-includes/functions.php on line 3495
    [16-Mar-2015 14:27:03 UTC] PHP Notice:  WP_User->id was called with an argument that is <strong>deprecated</strong> since version 2.1! Use <code>WP_User->ID</code> instead. in /var/sites/Encosia.com/public_html/blog/wp-includes/functions.php on line 3495
    [16-Mar-2015 14:27:03 UTC] PHP Notice:  WP_User->id was called with an argument that is <strong>deprecated</strong> since version 2.1! Use <code>WP_User->ID</code> instead. in /var/sites/Encosia.com/public_html/blog/wp-includes/functions.php on line 3495
    [16-Mar-2015 14:27:03 UTC] PHP Notice:  load_plugin_textdomain was called with an argument that is <strong>deprecated</strong> since version 2.7 with no alternative available. in /var/sites/Encosia.com/public_html/blog/wp-includes/functions.php on line 3497
    Plugin Author David Anderson

    (@davidanderson)

    Is your functions.php still taking effect? Try moving that snippet to an early part of wp-config.php, instead.

    If that still fails, you’ll need to find your PHP error log. The location of this depends on how PHP is setup – if in doubt, ask your web hosting company.

    David

    Thread Starter gt1329a

    (@gt1329a)

    I tried commenting that code out of functions.php and now I get this notice at the top of the UpdraftPlus debug tab:

    Abort class-pclzip.php : Missing zlib extensions

    After uncommenting that bit in functions.php, the zlib error is gone. So, it seems to be taking effect.

    I’m looking everywhere I can for more errors, but all I can find in the PHP error log, apache error log, and the WordPress error log are those notices I posted above. After searching, it seems like those are probably coming from other plugins using older, deprecated APIs? Could those affect UpdraftPlus to this extent?

    Plugin Author David Anderson

    (@davidanderson)

    After uncommenting that bit in functions.php, the zlib error is gone.

    I’ve got lost a bit here – which zlib error is this? I can’t find a reference in this thread to zlib errors.

    I don’t think any of the PHP notices mentioned are related. Those are just coding style notices and shouldn’t be anything to do with it.

    It looks, though, as if the crash is too early for the gzip issue to come into it.

    Do you have shell access to the server?

    David

    Thread Starter gt1329a

    (@gt1329a)

    I wasn’t seeing a zlib error before in relation to this 0% stall. I was just testing to be sure the functions.php gzopen shim is still in effect by pulling it out, seeing that there’s a new error without it, putting it back, and verifying that the error is gone again.

    I do have shell access to the server. It’s a VPS at Linode.

    Plugin Author David Anderson

    (@davidanderson)

    If you’ve got shell access, then it should be possible to see the PHP fatal error by running a backup directly from the shell.

    With the file you created earlier in the WP root…

    <?php
    define('WP_DEBUG', true);
    define('UPDRAFTPLUS_CONSOLELOG', true);
    define('DOING_CRON', true);
    require_once('wp-load.php');
    do_action('updraft_backup_all');
    ?>

    … run that directly via the PHP interpreter from the shell. If/when it finishes, the last thing it prints ought to be the PHP fatal error.

    Thread Starter gt1329a

    (@gt1329a)

    Interesting. Running it from the command line resulted in a full files/database backup without any errors. Going back to the wp-admin interface, backups still hang at 0%.

    Plugin Author David Anderson

    (@davidanderson)

    How weird… I think you’ll need to find the PHP error log file in order to find what the fatal error is. Fatal errors don’t go to any log file configured within WP (because they’re fatal – nothing more can be done – control passes back to PHP’s exit handler, and it can log in its own places, but control can’t pass back to any part of the PHP script).

    If you’re not sure where that log file is, then check the error_log setting in your php.ini file.

    David

    Plugin Author David Anderson

    (@davidanderson)

    P.S. Or, you could just set up a cron job using the shell, to call the php file from the shell on a schedule, since it works that way.

    Thread Starter gt1329a

    (@gt1329a)

    That was my first thought too, re: running it from a system cron job. I’m going to set that up for now as a stopgap.

    I do have PHP error logging enabled in the php.ini:

    error_reporting = E_ALL | E_STRICT
    error_log = /var/log/php_errors.log

    The file is totally empty though. Tailing it while trying to run backups in wp-admin doesn’t result in any output.

    As a sanity check, I created a trigger-error.php file with just this in it:

    <?php trigger_error("Fatal error", E_USER_ERROR); ?>

    And did see an error logged out to php_errors.log when I requested trigger-error.php in a browser. So, it seems like the error logging is working and none are occurring when I try to run a backup.

    I don’t know if this matters, but I can even go to the wp-admin page and watch an accurate progress bar for backups triggered from the command line. It seems to just be the triggering that doesn’t work there.

    Plugin Author David Anderson

    (@davidanderson)

    I wonder if some other plugin is conflicting; you could try de-activating other plugins + themes to see if this makes a difference.

    Thread Starter gt1329a

    (@gt1329a)

    The system-level cron.d job has been working well for the past week, which is comforting. Thanks for that suggestion.

    I suspected plugins too, but was reluctant to try disabling them since my site gets pretty constant traffic and the layout/functionality breaks pretty quickly without some of them enabled. Saturday night is the lowest point for my traffic though, so I’m going to give that a try now.

    Thread Starter gt1329a

    (@gt1329a)

    Interesting. When I disabled all plugins, trying to run a backup still had the same issue as before. However, I saw an error in the WordPress errors.log that I haven’t seen before:

    [29-Mar-2015 02:31:56 UTC] PHP Fatal error: Cannot redeclare class UpdraftPlus_BinZip in /var/sites/Encosia.com/public_html/blog/wp-content/plugins/updraftplus/class-zip.php on line 12

    Does that mean anything to you?

    Plugin Author David Anderson

    (@davidanderson)

    Hi,

    Yes… I’ve seen that a small handful of times before… it’s caused by a faulty PHP opcode cacher (http://en.wikipedia.org/wiki/PHP_accelerator) – if you either disable the opcode cacher, or disable it for WP scheduled tasks (I’d guess the file/URL to match is wp-cron.php, if your opcode cacher has per-file settings), then all should be well. (For a first test, best to just switch it off entirely).

    Best wishes,
    David

Viewing 15 replies - 1 through 15 (of 18 total)
  • The topic ‘Backups recently began hanging at 0% after "Began backup"’ is closed to new replies.