New answers tagged

0

After adding DirectoryIndex index.php The error Got error 'Primary script unknown\n' Means that index.php can't be found in /var/www/roundcubemail are you sure that it is there ? For roundcube it is a good practise to use the public_html folder to keep sensitive files out of reach, so your index.php might be there instead.


0

Side note here In the situation where your're developing using Laravel, in the config/app.php file you can specify timezone only of that project.


0

I'm not sure why, but I was able to fix the problem by switching to Unix sockets over TCP for the FastCGI connection. It looks like there's a bug somewhere, but I don't know who's to blame!


0

Although this post is from 2015 and I feel I am necroing (sorry community), I feel like it's valuable to add at this point in time: Nowadays (and since Kubernetes was mentioned) when you're working with Docker you can use Kubernetes or Docker Swarm very easily to solve this problem. Both orchestrators will take in your docker nodes (one node = one server ...


0

This is a PHP-FPM prank. Setup the clear_env = no on /etc/php/7.2/fpm/pool.d/www.conf, so; On Dockerfile start de php-fpm with init.d, not use service. Ex: CMD /etc/init.d/php7.2-fpm start && nginx -g 'daemon off;' Check environment variables now 🤩


-2

Another method for MaxOS Open ActivityMonitor, search php-fpm, find the pid. Open terminal, use kill [pid] to stop php-fpm Then php-fpm on terminal to start it. If there is error information that 127.0.0.1:9000 Already in use, just ignore that. Refresh Nginx page, should see php.ini changes take effects.


0

It wasn't a php-fpm issue, it was a web-server permission issue. By default on Arch nginx server runs workers as http user, you can see it at the start of your nginx.conf file: user http; worker_processes 1; So the http user couldn't access files in the directory /home/MYUSERNAME/Desktop/grav; When you moved the files to the directory to which the http ...


0

I had this problem with a few PHP scripts and finally resolved it. I had written a script to close and release the browser connection but continue processing the script. The problem was my script was timing out (because it was doing a time-intensive activity) causing the connection to be stuck in "Gracefully finishing." My PHP was doing some third party API ...


0

Got it. The issue was listen.acl_users (emphasis mine): When POSIX Access Control Lists are supported you can set them using these options, value is a comma separated list of user/group names. When set, listen.owner and listen.group are ignored. Solution: comment out this line: ;listen.acl_users = apache,nginx


0

The error occurs most probably due to a malformed URL - even though it reports just a vague Bad Request error. It was probably the missing /.... RewriteRule ^(.*)$ /index.php [L,QSA] Instead of RewriteRule ^(.*)$ index.php [L,QSA] Why is my rewrite rule resulting in "400: Bad Request"?


Top 50 recent answers are included