Support community for TTG plugins and products.
NOTICE
The Turning Gate's Community has moved to a new home, at https://discourse.theturninggate.net.
This forum is now closed, and exists here as a read-only archive.
You are not logged in.
After quite some time I just wanted to publish a new album.
This is what I find in the log:
[04-Jun-2018 01:09:12] TRACE: returning: {"status":"error","message":"Update query failed with error: SQLSTATE[HY000]: General error: 10 disk I\/O error\nsql:\n'UPDATE `engine_view` SET\n`name`=\\'loop.php\\',\n`type`=\\'dynamic\\',\n`path`=\\'\\',\n`rename`=\\'\\',\n`passthrough`=\\'no\\',\n`modified`=\\'2018-06-04 01:09:12\\'\nWHERE `engine_id`=\\'99\\' AND `view_id`=\\'view.loop\\''\nparams:\narray (\n) in PdoExtended.php on line 552"}
I can ftp to the server and also login to backlight admin
Any ideas?
Help apreciated.
Best wishes
Michael
Last edited by michilge (2018-06-23 07:22:39)
Offline
Sounds like a server issue.
Did you get an error when you tried to publish the album?
Daniel Leu | Photography
DanielLeu.com
My digital playground (eg, Backlight tips&tricks): lab.DanielLeu.com
Offline
Yes. The error said the same as the line from the log, just more nicely formatted.
Authentication between LR and publisher is fine btw.
Last edited by michilge (2018-06-04 13:29:39)
Offline
That looks like a server error. Perhaps a full disk on the server. Can you download the file backlight/data/designer/master.sq3 and email it to me, so that I can check that the file itself isn’t corrupted?
Offline
Hi Ben,
Did You get the file? The hoster says, there's no problem with disk space and I can upload files into the directory where database file is located. I also tried to remove an eventual lock by copying the database file to another location, deleting the original and copying back the copy.
I also don't unterstand, why publisher has to touch an entry concerning Wordpress Theme while I publish a gallery with a pangolin template.
Michael
Offline
I also don't unterstand, why publisher has to touch an entry concerning Wordpress Theme while I publish a gallery with a pangolin template.
I'm not following this statement, Michael. Can you clarify what's going on here? In what way is publisher "touching" an entry having to do with a Wordpress Theme? And are you referring to Backlight's Wordpress module, or something entirely separate?
Offline
Hi Michael, I've only now had a chance to look into this. I'll have a go at creating a hidden album tonight to see whether I can see the problem.
Looking into database locking, this sounds like a database that hasn't been closed properly. Backlight does not explicitly close database connections, as PHP is meant to automatically close them at the end of each response. There's an extra measure I can take to try and close them just before that is meant to happen automatically. That *may* help the problem from happening again, but probably won't solve the current locking.
Publisher touches Wordpress themes due to menus that may be affected by changes to the album structure.
Offline
Hi Michael,
have you and/or Ben been able to resolve your issues? I have exactly the same problem. I have sent Ben an email already before I found this thread. Who is your Hoster? I am with host europe in Germany. Would be nice if you could let me know if and how you have solved your problem.
Cheers Alfred
Last edited by alfred (2018-06-17 13:06:13)
Offline
Hi Michael and Alfred, I'm pretty sure you're both using the same host. Can you share the name of the host?
Michael, were you able to get this resolved for your site?
Offline
Yes indeed. I'm with Hosteurope too. I had two contacts with their telephone hotline. In the second contact their second level support was involved. Unfortunately they did not put me through directly but the agent switched lines between us.
They claimed everything to be OK on their side and the cause of the database being a frequency of database accesses to high for sqlite. They proposed switching to mysql and as I told them that this would be far out of scope they proposed to add a "sleep" command in appropriate places.
I precisely aked them to have a look at the file /backlight/data/designer/master.sql with the "fuser" command to find out which process keeps the database locked and possibly kill that process, which they refused. I tried that myself on the ssh console, but I have no permissions to execute "fuser". They asked me to open a ticket with support@hosteurope.de first. I had been very occupied last week and did not yet do that because I want to make certain that I will be reachable for requests and questions which was not given last week.
Alfred: I first noticed the problem on June 4th. If You log into backlight now and try to clear the template cache, You will probably get the same error message. If You download and read the recent logfiles in /backlight/data/designer/logs/ You will also find entries like
[11-Jun-2018 18:17:52] ERROR: Update query failed with error: SQLSTATE[HY000]: General error: 10 disk I/O errorsql:'UPDATE `engine_view` SET`name`=\'loop.php\',`type`=\'dynamic\',`path`=\'\',`rename`=\'\',`passthrough`=\'no\',`modified`=\'2018-06-11 18:17:51\'WHERE `engine_id`=\'99\' AND `view_id`=\'view.loop\''params:array () in PdoExtended.php on line 551You will also find entries beginning like
[05-Jun-2018 00:00:32] ERROR: SQLSTATE[HY000]: General error: 5 database is locked|#Just use the search string "error".
If You contact them and want to refer to me in case they recorded my calls in their support database: My hosting package is a shared hosting plan with the package number 1139230, so the virtual server is http://wp1139230.server-he.de/
If You mail me at ttg@michilge.de, I will tell You my Kundennummer. I will not find the time to open a ticket before Thursday.
Good luck so far
Michael
Last edited by michilge (2018-06-19 15:21:20)
Offline
Hi Ben, Michael,
I am afraid I can't add much information to what is here already. Michael is right; trying to clear the Template Cache creates the error he has described. I had not noticed this before.
I don't see a "Database is locked" error, I only see this:
[19-Jun-2018 11:29:16] ERROR: Update query failed with error: SQLSTATE[HY000]: General error: 10 disk I/O errorsql:'UPDATE `engine_view` SET`name`=\'index.php\',`type`=\'dynamic\',`path`=\'\',`rename`=\'\',`passthrough`=\'no\',`modified`=\'2018-06-19 11:29:16\'WHERE `engine_id`=\'111\' AND `view_id`=\'view.index\''params:array () in PdoExtended.php on line 552
Since I have been away from end of May into June, I can't confirm that the problems started for me around the same time as they did for Michael, but it is most likely.
I will lodge a ticket with hosteurope and see what they say. I have had no problems with them in the past, but the fact that Michael and I use them as our host and our problems started at the same time, makes it very likely that it is a host issue, but I'd be lost should they say all fine on our end ...
I have launched a ticket with hosteurope, let's see what they say.
Alfred
Last edited by alfred (2018-06-19 21:13:10)
Offline
Hi,
I just got home and tried something:
I deleted backlight/data/designer/master.sq3, logged into backlight and made sure, that backlight created a new, minimal instance of master.sq3.
I could then clear the template cache, which was not possible with the original master.sq3 present.
I created a new test album with put in a photo and published successfully. Of course the LR plugin offered me only the default template.
I then put the original master.sq3 back into place.
Clearing the template cache resulted in the same error as before..
Isn't this a sign, that the database file might be corrupt?
If yes is there a way to test this? Or even mend it? Restore the database file from a backup?
My last successful publishing was in March. The farthest reaching Backup I can access through the Hosters Admin panel is from June 2nd. Two days before I first encountered the error. If the master.sq3 had been corrupted during the last publishing that went without error message that was in March :-(
Alfred: Moin, moin. Not knowing if this will be of any use, I would recommend You to get hold of a backup before the dates rotate out of reach.
Log into KIS, go to Produktverwaltung - Webhosting - Konfigurieren - Restore & Backup - Webspace Restore
Choose a suitable date (You may also be limited to dates after June 2nd) if You can remember the date of last publishing that seemed to have worked, the backup of that day might have been the one that caught Your master.sq3 in an OK state (or the date before - who knows) You can provide the path to Your /backlight/data/designer as source. If You choose "Restore-Typ tar.gz" that will result in a compressed file in the root of Your webspace once the backup is finished. You can than download and extract that and pull the master.sq3 from the package. "Restore-Typ direkt" will replace the current files with the version from the respective backup date which may not be what You want. The whole process will take a while.
You can only have directories restored, not single files. So the tar.gz type is what I recommend.
Do You have access from where You are? Edit: I just realize that You're not on a holiday but live in Australia. I like Your birding photos by the way.
By for now.
Michael
Last edited by michilge (2018-06-20 06:11:11)
Offline
Hi Michael, I don't think it's a sign of a corrupt database, unless that is another issue again. When I looked at your site, I made a copy of the database, exported it as SQL and re-imported that SQL into a new database. Doing that ensures that the integrity of the master.sq3 file itself and internal structure isn't an issue. That didn't help the problem.
Your method may have found a way of unlocking the file as far as the file system or SQLite management is concerned.
Offline
Hi Ben,
what I don't really understand is that i can publish an album with the minimal database in place, but as soon as I restore the regular version I get the error again as soon as I clear the template cache. There must be a difference between the two versions that causes the regular one to produce an error the minimal one does not produce.
Offline
Hi Michael, that is strange. Can you email me with the names of the files on the server or the two files themselves?
Offline
Hi Ben, Michael,
I have received the following response from hosteurope:
In this case, there had no tmp path been defined for your script. For that reason SQLite has tried to write to /var/tmp, which is not writable for customer (scripts). As a matter of a one-time curtesy we have extended the relevant config files by the following line,
putenv("TMPDIR=/is/htdocs/user_tmp/wp1134443_GK99ZZU9WE/");
which should now make your script writing to your usertmp in the future, hence the problem should have disappeared. Please use MySQL in the future as opposed to SQLite, because this should be significantly less error prone.
I am up and running again, all observed problems have indeed gone! Not sure though what to make of the comment re SQLite/MySQL - my knowledge is not good enough to have an educated opinion.
Ben, Michael it would be nice if you could comment and thus close this topic.
Ben and Michael, thanks for all your support.
Alfred
Offline
Hi Ben,
sounds interesting.
Is there a possibility to specify a tmpdir for sqlite from within backlight or should I beg Hosteurope to do me the same favour they did to Alfred?
Cheers Michael
Offline
Hi Alfred and Michael, that sounds like some promising progress on the issue. Michael, are you able to ask your host for a similar change, or ask where in your control panel or files you could make a similar change? I can't see it being a change anywhere in Alfred's hosted files.
EDIT: Michael, looking at your phpinfo page, it looks like the TMPDIR is already set in the same way as it has been for Alfred. Is this the result of you contacting support? If not, they may have provided a global fix. Are you still getting errors?
To be honest, I'm not impressed with your host's remarks on this.
A properly-configured PHP environment should have SQLite writing to the correct locations, without any need to configure this. This "one time courtesy" is fixing something that should not have been broken.
We have been very pleased with SQLite as a technology, which has exceeded our expectations. It is fast and robust. We have had thousands of supported installations over the years, with some sites having tens of thousands of photos, without any noticeable degradation of performance, or any loss of data integrity.
MySQL would be a more performant and robust solution, but I see nothing lacking in SQLite for what we need in Backlight. The huge benefit of using SQLite is that the data is managed through files, and requires no setup of databases and users through the control panel, which would be a massive headache for us to advise across the various hosts that our customers use.
Offline
Hi Ben, hi Alfred,
I see, You're being optimistic ;-)
No, it still doesn't work for me. I believe, what we see in phpinfo() is the apache's server environment which is different from the system environment. I will ask them to do me the same favour they did for Alfred.
But I can be convincing towards hosteurope. If neccessary I will just offer them to stay their customer.
I'll drop them a line tomorrow and will report after success.
Alfred, thank You for dealing with the ticket.
Michael
Offline
Hi again,
it seems to be sorted. Template cache could be cleared, upload succeeded.
Hosteurope made the same changes to my configs they did to Alfred's. They also did a good job in having me understand that this was a matter of courtesy. I learned that they had been acquired by GoDaddy in 2016.
Ben, do You by chance recall if there are Backlight users successfully hosting with all-inkl.com ? Just asking for a friend.
I have some questions left:
All the interrupted attempts to publish the last album have left some directories that I will have to delete.
After deleting them in Backlight, is there anything I can do to give the database some care?
I had the value for "Delay API requests" in the settings of my publisher service put to a hight value, which had not been necessary before. What are typical values that help with GoDaddy?
Thank You for help, advice, patience and all the things I like around here.
A fine weekend for You.
Michael
Alfred: It is fun and pleasure browsing Your birding photos. I like Your idea of using the juxtapose presentation with the honey eaters sand plovers and tattlers.
Offline
Hi Michael, that's positive that they were able to get your site going again. Although it's owned by GoDaddy, it may still be under a different set of infrastructure. If you haven't encountered the request blocking, then I would leave the delay disabled. I haven't heard back from any users about which values they've found to work.
Do you have extra galleries that have been created? If so, the best approach is to try deleting them from Backlight. Visit Backlight > Publisher > Top-level Galleries, then Albums and click on the album name. At the bottom of the View Album page is a Delete Album link.
I haven't heard of any customers with all-inkl.com. Are you looking to move to them?
Thanks, wishing you a fine weekend too!
Offline
Hi Ben,
deleting the additional galleries went well. I downloaded and inspected publisher's database. There was no further debris left from my numerous test uploads.
The earlier proposal of the providers support to add some "sleep" to sqlite calls might be a hint that they are harmonizing standards to facilitate synergies.
I have always been content with them in the past. But in the past it was easier to reach a competent person on the telephone hotline. I liked being able to listen to and talk with people who are about to help me with problems.
That was why I have paid above average price for a hosting service for more than 15 years. They seem to have given away that distinguishing feature they had in the past. I have high respect for standardized and well documentetd processes. Having experts spend parts of their time in smalltalk and kindness isn't the route a profitable business should take. But in my case that led to a problem has not been handled. That signal "we screen our valued experts, don't call us, wee call you" made me guess I should better take the time to prepare the written information well and be precise.
in the end insisting that running a service as common as sqlite according to spec should be regarded as an exception and an act of courtesy gives me a strange feeling.
I had recommendations for all-inkl in the past from a friend who hosts multiple high traffic sites based on wordpress and phpBB there. But he does it on dedicated servers instead of a shared hosting enviroment, which will be configured differently. It would half my cost from the start. I could use a let's encrypt certificate instead of the one I now pay for. This means further savings when the current one expires. In a year or two I will run out of space. With HE I would have to switch to another contract AND to another physical server which had been some work and configuration trouble the last time I did that. They offer test accounts at all-inkl. I will get one as soon as work gets less ;-)
I still have some time to decide.
A fine weekend again.
Sent from the garden
Michael
Offline