This is the first release which is causing havoc.
After upgrading the plugin from 3.0.12, .maintenance file was created.
Removed .maintenance, restarted wp and tried again the upgrade proces with all other plugins disabled (which might conflict with 3.0.13)
This time internal server error. I reversed to 3.0.12 to be able to login again in wp admin.
I managed to get everything working again on my wp multisite installation
, reversing to 3.0.12.
However, I can reproduce the errors mentions above, when trying to upgrade from 3.0.12 to 3.0.13
the update run smoothly on many sites. Did you get any error messages? Because internal server errors can be caused by memory usage or too much script runtime. Please provide more informations that we can help you.
I replicated the error by installing 3.0.13 both from scratch and upgrading from 3.0.12. All other plugins disabled. Also checked wp-settings and wp-config files.
No problems with installing 3.0.12 and below
apache2 html output: 500 Internal server error
tail -f access.log | egrep backwpup
tail -f access.log | egrep backwpup
10.0.0.201 – – [13/Aug/2013:10:57:38 +0200] “GET /wp-admin/network/plugins.php HTTP/1.1” 200 9511 “http://testserver.lan/wp-admin/network/plugin-install.php?tab=search&s=backwpup&plugin-search-input=Search+Plugins” “Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0”
tail -f error.log | egrep backwpup
[Tue Aug 13 10:59:08 2013] [warn] [client 10.0.0.201] mod_fcgid: read data timeout in 40 seconds, referer: http://testserver.lan/wp-admin/network/plugin-install.php?tab=search&type=term&s=backwpup&plugin-search-input=Search+Plugins
[Tue Aug 13 10:59:08 2013] [warn] [client 10.0.0.201] (110)Connection timed out: mod_fcgid: ap_pass_brigade failed in handle_request_ipc function, referer: http://testserver.lan/wp-admin/network/plugin-install.php?tab=search&type=term&s=backwpup&plugin-search-input=Search+Plugins
cat /etc/php5/cgi/php.ini | egrep -i timeout
; Default timeout for socket based streams (seconds)
default_socket_timeout = 60
; Maximum time (in seconds) for connect timeout. -1 means no limit
mysql.connect_timeout = 60
;oci8.persistent_timeout = -1
; Set per-context timeout
; Connect timeout
;mssql.connect_timeout = 5
; Query timeout
;mssql.timeout = 60
cat /etc/php5/cgi/php.ini | egrep -i memory
; Maximum amount of memory a script may consume (128MB)
memory_limit = 128M
; If this parameter is set to Off, then memory leaks will not be shown (on
; enabled, registering these variables consumes CPU cycles and memory each time
; to proxy requests or to process the POST data in a memory efficient fashion.
; Enable / Disable collection of memory usage statistics by mysqlnd which can be
mysqlnd.collect_memory_statistics = Off
; A default size of the shared memory segment
I’ve installed 3.0.13 and now can’t get a backup to to run to completion. It stalls during the compression stage at 91%. How can I get back to 3.0.12 ? (I’m using WordPress 3.6)
novocastrian, ALWAYS make a backup of wp-content/plugins/backwpup before upgrading 😉
Remove the backwpup from your current wp installation and replace with previous version from here
Thank you. I reverted to 3.0.12 (which was working prior to update) and that is not working now either. It won’t compress beyond 9% – says I don’t have enough free space, but I have 133 Gb free. I guess 3.0.13 changed something. What a mess. I’ll look for an alternative backup.
I used an FTP program to delete BackWPUp entirely, then did a clean install of the new version, and it worked. That may be an option to try.
from the msg in my Apache error_log, i.e. mod_fcgid: ap_pass_brigade failed in handle_request_ipc function, I guess it has something to do with FCGI and the runtime of the backwpup 3.0.13 script
I m running Apache 2.2.22 with FCGI and SuExec.
I increased the PHP memory limit to 128MB but that doesn’t seem to be related to the problem , which I can still reproduce….
I’ll look into it when I got some more spare time…
I tweaked my fastcgi wrapper script a bit to increase the max number of php processes. No EFFECT
Increased PHP memory limit to 256MB. NO EFFECT
Reversed back to 128MB
As a last resort I just manually ‘installed’ (i.e. simple unpack) backwpup 3.0.13. It is a workaround, but at least I can use this release now : )
I m pretty sure it is a memory problem.
In size, Backwpup is the largest plugin ever I have installed.
Release 3.0.13 even more : 4.2MiB compared to 3.3MiB for 3.0.12
So it might have to do with memory limits when running the wp installer script in wp-admin/network/update.php and the ‘pluginzip‘ method of the File_Upload_Upgrader object in core WP 3.6.
Backwpup 3.0.12 is BIG and 3.0.13 maybe TOO BIG
BTW I m not a wp developer but have some basic working knowledge of the system
- The topic ‘3.0.13 upgrade fails’ is closed to new replies.