[wp-trac] [WordPress Trac] #24578: .maintenance file exists when not needed

WordPress Trac noreply at wordpress.org
Fri Jun 14 16:46:43 UTC 2013


#24578: .maintenance file exists when not needed
-----------------------------+-----------------------------
 Reporter:  novasource       |      Owner:
     Type:  defect (bug)     |     Status:  new
 Priority:  normal           |  Milestone:  Awaiting Review
Component:  Upgrade/Install  |    Version:  3.5.1
 Severity:  normal           |   Keywords:
-----------------------------+-----------------------------
 Responsiveness from the WordPress server that hosts update files was slow
 earlier today. It took >10 seconds just to get '''/wp-admin/network
 /update-core.php''' to respond as it apparently waited on the WordPress
 server.

 Our network identified 4 themes that needed updating. Downloading and
 installing these themes took a few minutes.

 The problem is that the '''.maintenance''' file was left on the server for
 a very long time, causing that '''Briefly unavailable for scheduled
 maintenance. Check back in a minute.''' message to display for a very log
 time.

 That file needs to only be written to the file system while actual
 maintenance is ongoing, and it should not be present while waiting on file
 downloads. This way, if file downloads are taking a very long time, that
 alone doesn't cause pointless access problems for other users.

 I'm not sure if all themes are first downloaded then updated, or if it's a
 download-update-download-update-download-update pattern. If the latter,
 them removing the .maintenance file between updates could cause user
 experience to thrash between uptime and downtime. This would not be good
 design.

 Now, to be clear, we're not 100% sure download slowness was behind this,
 but we're leaning thay way for a few reasons:
 * No known or observed problems with performance on our corporate internet
 pipe. This is a university pipe iwth a multi-gigabit connection which
 isn't being utilized heavily in the summer.
 * Analysis of process performance with '''top''' showed nothing amiss. No
 swapping, plenty of unused CPU capacity.
 * This server hosts two WordPress networks. Nothing in either network was
 slow except for updating.
 * We've been running WordPress for years here and have never had a prior
 problem like this with updates.

--
Ticket URL: <http://core.trac.wordpress.org/ticket/24578>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software


More information about the wp-trac mailing list