Disorganise's picture

Hi,

I'm running turnkey wordpress on Windows 10 hyper-v.  It runs fine, and updates plugins ok, but wordpress updates such as 5.2.3 don't seem to work.  I click the update and let it sit there and check the next day and still have the update message.

for the 5.2.2 updgrade, I found instructions on how to do it via the command line, which I can follow again obviously.  But it would be nice to know why it won't work through the web page, and if it is fixable.

I'm pretty much a linux noob and haven't been able to find the appropriate log that shows what is going on.  From what I can tell, the /var/www/wordpress folder is owned by www-data and set to 755

Any help or pointers would be appreciated.

 

version detail: turnkey-wordpress-15.2-stretch-amd64

Forum: 
Jeremy Davis's picture

That all sounds a bit strange. I would expect it to either work successfully, or not and give some sort of error.

It sounds like neither of those things are happening for you though...

Unfortunately, it's really hard to troubleshoot a issue remotely, when there is so little feedback from the system.

You mention that you updated via the commandline last time. Was that because of this issue? Or some other reason? If it only hasn't been working since you did it via commandline, then whilst your permissions do sound ok, perhaps it's worth resetting them, just to be sure?

chown -R www-data:www-data /var/www/wordpress
find /var/www/wordpress -type d -exec chmod 0755 {} \;
find /var/www/wordpress -type f -exec chmod 0644 {} \;

That will grant full ownership to www-data (the webserver user account) and recursively make directories 755 (rwx for owner, rx for others) and files 644 (rw for owner, read only for others). I doubt that will solve the issue, but at least then you'll be sure they're right and that isn't the issue.

The next thing I would check is that you have sufficient free disk space. I would have expected a clear error message if that's the problem, but worth checking anyway. Run this:

df -h

Then look for the line that is "Mounted on /". E.g. here is my dev machine:

Filesystem                Size  Used Avail Use% Mounted on
udev                      2.0G     0  2.0G   0% /dev
tmpfs                     396M   18M  378M   5% /run
/dev/mapper/turnkey-root   25G   14G  9.3G  60% /
tmpfs                     2.0G     0  2.0G   0% /dev/shm
tmpfs                     5.0M     0  5.0M   0% /run/lock
tmpfs                     2.0G     0  2.0G   0% /sys/fs/cgroup
/dev/sdb1                  76G  7.4G   65G  11% /mnt

Mine has 60% usage currently (used 14G on a 25G partition, leaving 9.3G free). So in my case, that's tons of room. I would suggest that if it's anything more than 80-90% that you have a bit of a cleanup, and/or make the root volume larger.

Sorry that that doesn't explicitly address your question, but perhaps the above steps might give us some more info.

Beyond that, I suggest that you try again and watch it. It shouldn't take more than a few minutes and once it's done (assuming no error messages), re check for updates when you're done. If you get any error message, please post back with it verbatim; i.e. capture the error message exactly as it's displayed.

Disorganise's picture

To answer " You mention that you updated via the commandline last time. Was that because of this issue? Or some other reason? " <- yes, because same issue.  I couldn't get it to work through the GUI and iirc there were security  updates so I really wanted to have it updated.

 

I have been setting up to do a screen capture to show the process; which is basically 'transferring...' and then nothing.   In setting up the capture, I closed all the other tabs (for firefox anyway), and hit the update.

Transferring..... and voilla, a webpage about the update.  It worked!

Could it be that the update doesn't like multiple tabs (and multiple browser windows each with multiple tabs) open?

 

fwiw

Filesystem                Size  Used Avail Use% Mounted on
udev                      689M     0  689M   0% /dev
tmpfs                     140M   19M  122M  14% /run
/dev/mapper/turnkey-root   17G  2.2G   14G  14% /
tmpfs                     700M     0  700M   0% /dev/shm
tmpfs                     5.0M     0  5.0M   0% /run/lock
tmpfs                     700M     0  700M   0% /sys/fs/cgroup

plenty of space.  I did not run the permissions command yet either - so nothing changed actually.

the only variable I can think of is perhaps internet speed - did the update time out previously before the patch was fully downloaded, whereas this time the download completed in reasonable time?

Jeremy Davis's picture

Wow, that was an easy "fix"! Great work! :)

As you note, you have tons of free space so that clearly wasn't an issue.

Judging from your experience, it certainly sounds like it may well have been timing out for some reason that was linked to network throughput. I have no experience with Hyper-V, but perhaps the network throughput is being limited for some reason? Perhaps local connections get some priority over remote connections? TBH, I have no idea and am really only guessing... More guessing; perhaps there are some javascript callbacks or similar that run client side (i.e. in your browser) that are replicated in each open window/tab and were soaking up the available bandwidth? TBH, I'm not even sure how that might happen, but your experience seems to suggest that something like that is likely?!

Another possibility is that it was running out of RAM? Although TBH, I would have expected other indications/issues if that was the underlying cause. FWIW, you can check free RAM like this:

free -ht

Again from my dev machine (FWIW 'h' is human readable numbers; 't' provides an additional totals line):

              total        used        free      shared  buff/cache   available
Mem:           3.9G        151M        131M        7.6M        3.6G        3.4G
Swap:          4.0G         12K        4.0G
Total:         7.9G        151M        4.1G

Note that "buff/cache" (disk read/write buffer/cache) doesn't actually count towards the real total used RAM. This is because in Linux, free RAM is used as an extra layer of disk cache to improve performance. If the RAM is needed by the system, the caching is reduced and RAM is handed back to the system. So you need to pay attention to the "available" column and/or the "total" vs "used" columns (the "free" column is deceptive).

Regardless of the cause, personally, I still would have expected WordPress to come back with some error message about what went wrong (even if it was a generic "failed to download" message), but it seems not...!

Regardless, thanks tons for posting back with your experience. I'm sure that other users may well hit this same issue and to have it noted here is fantastic! So thanks for that...

Add new comment