I issued the following commands to my Debian Server apt-get update, and then apt-get upgrade, after which whenever I visit my site (fundlined.com) it returns a NGINX 404 Not Found Error. It's probably caused due to certain files being over written.
I tried to search for any overwritten code, but can't seem to find any.
What changes should I make, in order to fix this issue?
I also experienced this issue.
After checking virtual host file as to where the right error and access log were, I found that it runs on fast-cfi not php5-fpm which conflicts after upgrade. So I removed php5-fpm, stopped it and started fastci.
Related
I'm having a strange issue with Ubuntu 18.04 and Nginx with ModSecurity. I've compiled everything correctly and it's working when activating the ModSecurity module, however whenever I activate a rule, I get the following:
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid
Nginx crashes and doesn't serve the page - any ideas?
I'm having this issue in Ubuntu 16.04 as well. This seems to be an issue with the latest version of ModSecurity as seen in this bug: https://github.com/SpiderLabs/ModSecurity/issues/2180
If you downloaded ModSecurity via git, you can use this command to get back to a working version:
git reset --hard d5b93c1013ca9c9a96c75369576b54832e9a2b48
Then clean your ModSecurity build directory and build it again. Once you have ModSecurity rebuild, restart nginx. Once the above bug is closed in GitHub, it will probably be safe to update to the latest version again.
Edit: This issue has been corrected. Simply update and recompile ModSecurity.
I have used Valet without problems for nearly a year, though occasionally needed a restart or reinstall to get it going. Yesterday I upgraded to a fresh valet 2.0.3 and as a result and ever since then there is no connection in the browser to any of my *.dev hosts (though there is appropriate ping response in the terminal).
Have executed brew update and tried a full reinstall several times (with preceding brew uninstall dnsmasq / php70 etc). There is no error or warning during installation process. Error logs remain empty even after valet start / restart / park commands. Also, there are apparently no caddyfile and Caddy directory generated neither in ~/.valet nor in ~/.composer/vendor/bin/laravel/valet.
An attempt to download Caddy from github and apply it like hinted here had no effect.
As I need valet badly for my work I have researched night and day for any solution, but not succeeded yet. Any hints welcome.
Valet 2 utilizes no more Caddy, but nginx instead. The solution is to uninstall the present nginx via brew and let nginx get reinstalled during the valet installation procedure. As described here by Switzer: https://laracasts.com/discuss/channels/laravel/valet-2-upgrade-all-sites-refuse-to-connect
I followed the installation guide at https://www.cloudcontrol.com/dev-center/Add-on%20Documentation/Data%20Storage/MemCachier. The memcachier server is up and running, I tested it from the command line. But my cloudcontrol app isn't able to access it.
Here's the error in our logs:
Info MemcachedError: error 40 from memcached_set: FAILED TO SEND AUTHENTICATION TO SERVER, no mechanism available, host: [my-memcachier-server-url]:11211 -> libmemcached/sasl.cc:221
Notice No worthy mechs found
This seems to be a SASL-related issue. Is it possible that cctrl does not have the correct sasl2 libraries installed? Did anyone else experience this problem?
Further info:
django-pylibmc==0.5.0 and pylibmc==1.4.1 in requirements.txt
url and credentials are read from the cctrl environment correctly
This is caused by the libmemched version bundled with the buildpack missing a patch (https://bugs.launchpad.net/libmemcached/+bug/1381160). Because it is a stackoverflow bug, it can work systematically on your machine while it systematically breaks in the container. I will update the python buildpack to use the patched libmemcached library from the stack.
In the meantime you can try to achieve this manually by setting the LD_LIBRARY_PATH environment variable to /usr/local/lib either via config add-on or web: env LD_LIBRARY_PATH=/usr/local/lib <your_command> in the Procfile.
I was trying to move my Drupal site from my WAMP server to another computer's WAMP server and I followed all the necessary steps but I faced the error below. I tried updating but it didn't work.
Fatal error: Call to undefined function cache_get() in C:\wamp\www\try\includes\bootstrap.inc on line 901
I am using PostgreSQL and PhpPgAdmin. Any ideas?
See if Memcache is used in previous server.
If not see if some other cacheing mechanism like varnish cache is used
If none of the above:
When you type drush in the command line probably you reached the right place to solve you problem. This error arises when drush is not update and this occurs when you install drush from official repository in Ubuntu. The workaround is easy: just install a new version of drush! And to do so, you have to install from backported package of Ubuntu.
I am trying to install Symfony 2.1.3 (latest). I am running composer and installs everything okay. The only error that I get is:
Script Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::clearCache
handling the post-install-cmd event terminated with an exception
[RuntimeException]
An error occurred when executing the "'cache:clear --no-warmup'" command.
It's being installed under www folder. I am running nginx and followed the composer approach. I read on internet that apache should be run manually not as a service, however I am using nginx instead. Does apache still have any bearing on it? I'm using debian squeeze.
Edit: As per AdrienBrault's suggestion the error was because the timezone was not set in the php.ini. Only with --verbose I could see the warning. Thanks guys.
Apache is not related - PHP is called via command line.
Most likely is the permission in the cache folder: did you check if the user that runs the composer update can actually write the cache folder?
Try to manually run rm -Rf app/cache/dev (for production environment replace dev with prod) and see if you get any permission error.
Also you will get this error if the default.timezone setting is not configured in php when running in CLI. To verify just run
php --info | grep timezone
and check that the setting date.timezone is correctly configured.
On the security side, setting 777 to the folder is not the optimal solution - if you have ACL enabled you could use that to correctly set up the permission for the cache and logs folder. Read more at the Symfony2 official installation page
I had this same issue for a while and after hours of face to brick wall pounding I realized... I have a .gitmodule in my project, and on initial checkout these submodules are NOT initialized and as such are not there for your composer to update, which results in the above error.
Make sure you run the following
git submodule update --init src/Acme/Sadness/Bundle
of course replace src/Acme/Sadness/Bundle with YOUR project namespace.
Hope this helps someone not go through the same pain I just did.
If you have vendor folder already I would remove it and install symfony 2.1.3 again via "composer.phar install". Problem might be coming from outdated version of composer
I had the same problem and I resolve in this way.
execute this on the console
and you should see something like this
$ locate php.ini
/etc/php5/apache2/php.ini
/etc/php5/cli/php.ini
/etc/php5/fpm/php.ini
the first line is probably your php.ini that appear when you do a phpinfo();
the problem is that when you execute composer update this no check the same php.ini
in my case the second line
all my sites work fine but always I had problems not now
after edit the second file and put the same time zone that you set in the first one
run
$ sudo service apache2 reload
and now
$ composer update
I hope that this work for you like work for me
regards
Emiliano