Friends need help.
After a system failure on the host there was such a mistake.
Fatal error: unknown class App\Entry in /home/uzbek/uzbek.rf/www/app/Vacancy.php on line 25
error: inflate: data stream error (unknown comperssion method)
fatal: loose object 130dc6556560992b5a0f13992d5f0d716867c6ba (stored in .git/objects/13/0dc6556560992b5a0f13992d5f0d716867c6ba) is corrupt
fatal: The remote end hung up unexpectedly
The site gives you a white screen , what to do?
I understand that this is a problem with Git, but I'm with him, unfortunately , bad. :(
If you have a "good" copy of the repository
First of all you need to know if you have a backup somewhere (another copy of the repository).
If you do simply grab the last good copy and you are good to go.
If you don not have a "good" copy of the repository
If will be hard to "fix" the repository.
First of all try to find out which file is broken:
git show 0dc6556560992b5a0f13992d5f0d716867c6ba
or:
git cat-file -p 0dc6556560992b5a0f13992d5f0d716867c6ba
Once you know which file is it try to recover it from the history of your editor.
You can also run :
git fsck --full
to see if you have some other "broken" objects.
Related
I have been trying to commit to my local git repository but i always receive the above error. I checked online and all solutions are for linux machines(ie they involve using 'sudo') but I am running windows 7. How can i fix the error? thanks in advance :)
fatal: cannot update the ref 'HEAD': unable to append to '.git/logs/HEAD': Permission denied
I would first try a simple reboot, followed by your Git command right after login.
That way, I would minimize the possibility of another process keeping a handle to .git/logs/HEAD, preventing Git to access/update that file.
I'm following the official docs to setup google cloud firestore to integrate with my php project
[1] https://cloud.google.com/firestore/docs/quickstart-servers
when I initialize the FirestoreClient I get the following error
Error rendering 'projects/{project=*}/databases/{database=*}': expected binding 'project' to match segment '{project=*}', instead got null\n
Provided bindings: Array\n
(\n
[project] => \n
[database] => (default)\n
)\n
First In the documentation it tells to use ENV VARIABLE though using the following command
export GOOGLE_APPLICATION_CREDENTIALS=/Users/user/Desktop/programming/workarea/.firebase.config.json
I investigated a lot and I think the problem happens when the library tries to establish a connection with the firestore server.
I couldn't find the root of the problem. but I think for some reason the php server not reading the env vars so it's not able to establish a proper connection
I struggled some time with this too, resolved it after realizing this: as said here, you first have to authenticate. For that, install the gcloud-sdk available here, then follow the steps provided.
Second, you have to set your environment variable with the path to your project's credentials file, as you were doing, in the bash (i use ~/.bashrc), exit the terminal and reenter it (necessary, as it may not apply the file edit for that terminal session). You could also type source .bashrc to apply changes without closing the terminal.
Then you should be fine, assuming you have the other required environment dependencies installed found here.
I am trying to upgrade Moodle 2.7 to 3.1.But for some reason I can't. This is the error:
Coding error detected, it must be fixed by a programmer: The data source class does not exist.
Debug info:
Error code: codingerror
Stack trace:
line 498 of /cache/classes/definition.php: coding_exception thrown
line 515 of /cache/classes/helper.php: call to cache_definition::load()
line 480 of /cache/classes/helper.php: call to cache_helper::purge_store()
line 323 of /admin/index.php: call to cache_helper::purge_all()
What could be the problem of this?
I just had the exact same problem trying to update from version 2.8 to 3.1, I found the solution in this Moodle Tracker issue:
Removed the following directories (and let Moodle rebuild them),
cache, lock, temp, trashdir, sessions, localcache, muc (and anything
else that shouldn't have been in there). Obviously don't delete your
files/filedir!
I leave the solution in case someone else has this problem.
cd /var/moodledata
rm -fr ./cache/ ./lock/ ./temp/ ./trashdir/ ./sessions/ ./localcache/ ./muc/
You may have removed a file which was meant to be included when loading the cache definitions from any db/caches.php. Grep those files for datasource, that will help you identify where the problem is.
Another reason would be that the class cannot be found because the cache code runs before the autoloading definitions are set. That would be very surprising, but you can have a look at [moodledatafolder]/cache/core_component.php to see if the class is in there, and its path exists.
im trying to install Sylius with composer for an e commerce project however i just cant get it done..i follow the docs but i always get an other error when i fix one.
already fixed some errors eg. incl extension exception, paypal bundle renaming issues on git and memory size problem.
Now where im stuck:
When i fill the parameters with the interactive script
if i give any password for the database i get this:
Doctrine\DBAL\Driver\PDOException
Acces denied for user 'root'#localhost
if i dont give password then i get this:
Doctrine\DBAL\Driver\PDOException
SQLSTATE[HY000]Unknown database databasename_dev (it appends _dev prefix)
then in both cases it ends up with this: RunTimeException
An error occured when executing the ""cache:clear --no-warmup"" command
and the proccess is terminated with this exception..
i tried if i could continue with the $ cd acme
$ php app/console sylius:install commands but:
if i gave a password then get acces denied Doctrine\DBAL\Exception\ConnectionException
if didnt then Doctrine\DBAL\Driver\PDOException
SQLSTATE[HY000]Unknown database databasename_dev
i created the database manually which seems to solve the problem however get this: General error: 1007 cant create database databasename_dev; database exists
(i dont think this solution is the right one)
but after this it doesnt terminate yet and creates the database schema and then after some installation it terminates with this:
RuntimeException
The source file "C:\Users\user\acme\app/../web/bundles/cmfcreate/vendor/create/themes/midgard-tags/tags.css" does not exists
i checked the page if it may useable but got twig exception that currency not found and many components are missing from the page..
What's your workspace?
If you work on Windows with WAMP I'll give you some things to check :
set the database port to : 3306
create a new user for the database, juste for your sylius project
when you run create-project commande, in databaseport write : localhost
I hope it helps you.
The easy part...
Usually when migrating a ZF1 application from built-in auto-loading to composer based auto-loading (which is strongly recommended for deploying on CloudControls Pinky stack) you just need to take some simple steps:
Create a composer.json file and require Zend Framework (e.g. latest release from version 1.12) with:
{
"require" : {
"zendframework/zendframework1" : "1.12.*"
}
}
Install composer dependencies via CLI with:
composer install
Update your .gitignore file and add:
vendor/*
Recursively delete current ZF folder from your library path (e.g. ./library):
rm -r library/Zend
Include composer autoloader in your index.php before any usage of Zend_ classes by adding:
$loader = include 'vendor/autoload.php';
Remove every now obsolete ZF related require or require_once statements from your index.php - e.g. this is not needed anymore:
require_once 'Zend/Application.php';
Once you are done with the above changes you commit and push via git as normal and then you deploy the new version on CloudControl via CLI (where APP_NAME and DEP_NAME here refer to your app and deployment names):
cctrlapp APP_NAME/DEP_NAME deploy
You will notice that cctrlapp prints out some information about resolving composer dependencies and finally initiates the deployment of the new version. To check whether it is done you can run:
cctrlapp APP_NAME/DEP_NAME log deploy
Ok, deployment log looks fine – nice – let's open the browser!
What the f***! Internal server error? Why?? Everything worked well with the local LA(M)P stack!!!
The tricky part...
Fortunately CloudControl gives us access to the error logs as well ...
cctrlapp APP_NAME/DEP_NAME log error
Shouldn't be too hard to find out what's wrong here.
But ... err ...
8/1/14 5:23 AM error [error] [client ] FastCGI: incomplete headers (0 bytes) received from server "/app/php/box/php-fpm"
8/1/14 5:23 AM error [error] [client ] (104)Connection reset by peer: FastCGI: comm with server "/app/php/box/php-fpm" aborted: read failed
As the above error messages are not helpful at all we first need to track down this very bug. And this can indeed be tricky! We can google a bit. We can try something. We can then redeploy. We can google a bit more. We can try another thing. We can then redeploy again. We can google another time. We can try out every other thing. We can ... but do we want?
Luckily the Pinky stack offers another way to speed things up (which Luigi does not all). While it still incorporates cumbersome manual debugging at least we can save some time – go to your CLI and execute:
cctrlapp APP_NAME/DEP_NAME run bash
CloudControl now instantiates a new container for us and gives us SSH based shell access to it. As the documentation says everything should be as it is inside our deployment boxes:
The distributed nature of the cloudControl platform means it's not
possible to SSH into the actual server. Instead, we offer the run
command, that allows you to launch a new container and connect to that
via SSH.
The container is identical to the web or worker containers but starts
an SSH daemon instead of one of the Procfile commands. It's based on
the same stack image and deployment image and does also provides the
Add-on credentials.
Let's see if we can find out more (from inside the container):
cd code/public
php index.php
Hmm ... nothing reported here ... and ... nothing reported at the logs?! What the hell?!!
So, there seems to be a difference between the web and the run containers – and there is!
To find this out I started by editing the index.php right away:
vi index.php
And after a while I finally got to reproduce at least another error:
8/1/14 8:55 AM error [error] [client ] FastCGI: server "/app/php/box/php-fpm" stderr: PHP message: PHP Fatal error: require_once(): Failed opening required '' (include_path='/srv/www/code/vendor/zendframework/zendframework1/library:/srv/www/code/library:.:/usr/share/php') in /srv/www/code/vendor/zendframework/zendframework1/library/Zend/ ...
8/1/14 8:55 AM error [error] [client ] FastCGI: server "/app/php/box/php-fpm" stderr: PHP message: PHP Warning: require_once(/srv/www/code/vendor/zendframework/zendframework1/library): failed to open stream: No such file or directory in /srv/www/code/vendor/zendframework/zendframework1/library/Zend/ ...
Looks like some file is missing – maybe related to auto-loading – shouldn't be too hard to fix it.
But wait, what's that: Failed opening required ''? Sure you fail to require nothing you stupid code you!!
Well ... when looking at the respective ZF library files you won't find anything wrong there. The include paths seem to be correct as well – and yes, the files are present – composer managed both things correctly.
It's a PHP bug!
To be more precise it is a bug with PECL APC which affects Pinky's current versions of PHP 5.4.30 / APC 3.1.13 - see:
https://bugs.php.net/bug.php?id=62398
And that's exactly the difference between the run and the web containers as php.ini option apc.stat is set to 0 (off) for the web containers and 1 (on) for the run container.
tl;dr
Clone the CloudControl Pinky PHP buildpack from GitHub:
git clone https://github.com/cloudControl/buildpack-php.git
Copy all files from this repository and add them to your project root folder at:
.buildpack/php
Edit .buildpack/php/conf/php.ini and set:
apc.stat = 1
Commit, push, deploy and enjoy!
Notes:
Keep in mind that this is just a workaround as APC stat does not need to be activated in such an environment (where the stack is recreated on deploy) and it slows down execution. See the PHP docs:
On a production server where the script files rarely change, a
significant performance boost can be achieved by disabled stats.
Thanks:
Finally I'd like to thank Dimitris and Mateusz from CloudControl for general advises – though I need to find out on my own what was going on here. Furthermore I want to thank #BullfrogBlues and #Thierry_Marianne here at Stack Overflow who tried to answer another questioners thread dating back to November last year, which finally pointed me to look for APC related issues.