Supervisor is not started into my docker container (Laravel project) - php

Supervisor is not started into my container and i am not able to run my php artisan queue:work command for my laravel project.
Extract from my Dockerfile
# Add worker to supervisor config file
COPY laravel-worker.conf /etc/supervisor/conf.d/
CMD ["/usr/bin/supervisord"]
Here is the laravel-worker.conf:
[program:laravel-worker]
command=php /var/www/test/current/artisan queue:work --tries=3
user=myuser
process_name=%(program_name)s_%(process_num)d
directory=/var/www/test/current
stdout_logfile=/tmp/supervisord.log
redirect_stderr=true
numprocs=1
autostart=true
autorestart=true
When i go into the container, the supervisor service is not started:
root#e7227ef40f63:/# service supervisor status
supervisord is not running.
And process are following:
root#e7227ef40f63:/# ps -aux | grep supervisor
root 1 0.0 0.0 4328 652 ? Ss 18:21 0:00 /bin/sh -c service ssh restart && service apache2 restart && service cron start && bash /usr/bin/supervisord
root 365 0.0 0.0 55808 10632 ? Ss 18:25 0:00 /usr/bin/python /usr/bin/supervisord
root 380 0.0 0.0 11120 712 ? S+ 18:27 0:00 grep supervisor
UPDATE
I edited my DockerFile and put this line:
ENTRYPOINT service ssh restart && service apache2 restart && service cron start && /usr/bin/supervisord && bash
The service is now well started when the container starts :
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.1 0.0 4328 652 ? Ss 05:20 0:00 /bin/sh -c service ssh restart && service apache2 restart && service cron start && /usr/bin/supervisord && bash
root 25 0.0 0.0 55176 1140 ? Ss 05:20 0:00 /usr/sbin/sshd
root 43 0.1 0.0 406408 25504 ? Ss 05:20 0:00 /usr/sbin/apache2 -k start
www-data 46 0.0 0.0 406440 8416 ? S 05:20 0:00 /usr/sbin/apache2 -k start
www-data 47 0.0 0.0 406440 8416 ? S 05:20 0:00 /usr/sbin/apache2 -k start
www-data 48 0.0 0.0 406440 8416 ? S 05:20 0:00 /usr/sbin/apache2 -k start
www-data 49 0.0 0.0 406440 8416 ? S 05:20 0:00 /usr/sbin/apache2 -k start
www-data 50 0.0 0.0 406440 8416 ? S 05:20 0:00 /usr/sbin/apache2 -k start
root 59 0.0 0.0 17484 636 ? Ss 05:20 0:00 /usr/sbin/cron
root 63 0.2 0.0 56012 10788 ? Ss 05:20 0:00 /usr/bin/python /usr/bin/supervisord
root 64 0.0 0.0 20032 1280 ? S 05:20 0:00 bash
root 89 0.1 0.0 20240 1996 ? Ss 05:20 0:00 bash
root 112 0.0 0.0 17492 1168 ? R+ 05:21 0:00 ps -aux
But it seams that supervisor doesn't start my config file because i don't see the 8 processes that should be run..

This is the bad part:
&& bash /usr/bin/supervisord
supervisord is not a bash script. Execute it as is: && /usr/bin/supervisord.
However, I recommend you to completely avoid using service in a container. In general, running more than one process into a container is considered an antipattern, but if you really need it, better only use supervisor . Create a .conf file for each process (cron, sshd, etc) and only run supervosord as is in your CMD.

Related

reload `procmgr` in container?

So I have a docker container build with buildpack that runs the following command under PID 1
procmgr /layers/paketo-buildpacks_php-web/php-web/procs.yml
is it possible to reload the configs passed into procmgr somehow?
🐳 [DEV] backend-v1-7476cc6cfd-l68p2 app #
ps aufx
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
cnb 30 1.0 0.0 18648 3444 pts/0 Ss 03:22 0:00 bash
cnb 77 0.0 0.0 34412 2944 pts/0 R+ 03:22 0:00 \_ ps aufx
cnb 1 0.0 0.1 1013616 4096 ? Ssl 03:20 0:00 procmgr /layers/paketo-buildpacks_php-web/php-web/procs.yml
cnb 24 0.0 0.7 323596 31260 ? Ss 03:20 0:00 php-fpm: master process (/layers/paketo-buildpacks_php-web/php-web/etc/php-fpm.conf)
cnb 28 0.3 0.6 330252 24112 ? S 03:20 0:00 \_ php-fpm: pool www
cnb 29 0.1 0.6 330016 23900 ? S 03:20 0:00 \_ php-fpm: pool www
cnb 25 0.0 0.1 25132 5648 ? S 03:20 0:00 nginx: master process nginx -p /workspace/app -c /workspace/app/nginx.conf
cnb 26 0.0 0.0 25132 1988 ? S 03:20 0:00 \_ nginx: worker process
cnb 27 0.0 0.0 25132 1988 ? S 03:20 0:00 \_ nginx: worker process
🐳 [DEV] backend-v1-7476cc6cfd-l68p2 app #
cat /layers/paketo-buildpacks_php-web/php-web/procs.yml
processes:
nginx:
command: nginx
args:
- -p
- /workspace/app
- -c
- /workspace/app/nginx.conf
php-fpm:
command: php-fpm
args:
- -p
- /layers/paketo-buildpacks_php-web/php-web
- -y
- /layers/paketo-buildpacks_php-web/php-web/etc/php-fpm.conf
- -c
- /layers/paketo-buildpacks_php-web/php-web/etc
At the time of writing this, no. The procmgr cli that is used here is very basic.
https://github.com/paketo-buildpacks/php-web/blob/main/cmd/procmgr/main.go
It loads the processes information listed in procs.yml, starts those processes, redirects all STDOUT/STDERR, and watches for a process to exit. If one process exits, then they all exit. There's no reload capability.
If you need to reload the information in procs.yml, you'll need to reload your container.

Nginx + php fastcgi unable to open file, permission denied

I am having some permission issues with Nginx and Php fastcgi when trying to get to the php file. I am using 5.5.15 and Nginx 1.6.0 in Redhat 7 .
My php file is very simple for now.
<?php
echo "\nscript owner : ".get_current_user()."\n";
$myFile = '/usr/share/nginx/html/test.log';
$fh = fopen($myFile, 'a') or die("can''t open file");
?>
Get current user will result in : "myuser"
The error that I am getting is the following:
2014/08/26 22:47:14 [error] 6424#0: *16 FastCGI sent in stderr: "PHP message: PHP Warning: fopen(/usr/share/nginx/html/test.log): failed to open stream: Permission denied in /usr/share/nginx/html/test.php on line 19" while reading response header from upstream, client: XXXXXX, server: XXXXXXX, request: "GET /test.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "XXXXXXX"
Here is the permissions for the directory /usr/share/nginx( all of the parent directories have x permissions):
drwxrwsrwx. 4 myuser myuser 4096 Aug 26 22:32 html
Running the following commands:
$ ps aux | grep "nginx: worker process"
myuser 6423 0.0 0.3 111228 3880 ? S 22:36 0:00 nginx: worker process
myuser 6424 0.0 0.5 111228 5428 ? S 22:36 0:00 nginx: worker process
myuser 6480 0.0 0.0 112640 980 pts/0 R+ 22:41 0:00 grep --color=auto nginx: worker process
$ ps aux | grep "php"
myuser 5930 0.0 0.1 128616 1860 pts/0 T 21:09 0:00 vi /etc/php-fpm.conf
myuser 5931 0.0 0.2 128628 2052 pts/0 T 21:09 0:00 vi /etc/php.ini
myuser 5933 0.0 0.1 128616 1864 pts/0 T 21:13 0:00 vi /etc/php-fpm.conf
myuser 5934 0.0 0.1 128616 1860 pts/0 T 21:14 0:00 vi /etc/php-fpm.d/www.conf
myuser 5935 0.0 0.1 128616 1864 pts/0 T 21:15 0:00 vi /etc/php-fpm.conf
root 6313 0.0 2.4 544732 25208 ? Ss 22:25 0:00 php-fpm: master process (/etc/php-fpm.conf)
myuser 6314 0.0 0.8 544732 8356 ? S 22:25 0:00 php-fpm: pool www
myuser 6315 0.0 0.8 544732 8328 ? S 22:25 0:00 php-fpm: pool www
myuser 6316 0.0 0.9 545076 9892 ? S 22:25 0:00 php-fpm: pool www
myuser 6317 0.0 0.9 544860 9452 ? S 22:25 0:00 php-fpm: pool www
myuser 6318 0.0 0.9 544860 9212 ? S 22:25 0:00 php-fpm: pool www
myuser 6483 0.0 0.0 112640 976 pts/0 R+ 22:47 0:00 grep --color=auto php
My Server looks like the following:
server {
listen 80;
root /usr/share/nginx/html;
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
location ~ \.php$ {
try_files $uri =404;
fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
}
And in the nginx.config I am using the same user: "user ec2-user;"
I have also changed the /etc/php-fpm.d/www.conf file to have the same user and group.
user = myuser
group = myuser
So, both Nginx and PHP are running on the same user "myuser".
All the directories up to where the log file and the php file are located(/usr/share/nginx/html) have x access and that user has 777 access to that html directory.
Not sure what I am missing. I have been searching online for 2 days now but no luck.
I suppose rights are correct, but you have 3 line of code in test.php, but due to error this is not true :) Check what file you run.
"in /usr/share/nginx/html/test.php on line 19"

codeigniter doesn't display the page requested

I have a working MVC framework using codeigniter. The codebase is located in /var/www/project,
where project follows the same structure as codeigniter. I have placed a info.php file under /var/www/project, which is the basic phpinfo() script. On typing
http://localhost/project/info.php
the page displays the information as it should.
My config.php under /var/www/project/application/config has been configured so that the [base_url] is : http://localhost/project
The 'project' is trying to connect to database : 'development' and the database.php has been configured properly ( afaik). On enabling the debug mode in database.php, it doesnt throw any error which makes me think that there is no issue as far as accessing the database is conerned( Though I can be wrong).
Also doing a ' ps aux | grep apache' shows:
root 14892 0.0 0.1 215404 9668 ? Ss 17:25 0:00 /usr/sbin/apache2 -k start
www-data 14896 0.0 0.2 223404 17324 ? S 17:25 0:00 /usr/sbin/apache2 -k start
www-data 14897 0.0 0.1 215896 7636 ? S 17:25 0:00 /usr/sbin/apache2 -k start
www-data 14898 0.0 0.1 218964 11460 ? S 17:25 0:00 /usr/sbin/apache2 -k start
www-data 14899 0.0 0.1 218956 11300 ? S 17:25 0:00 /usr/sbin/apache2 -k start
www-data 14901 0.0 0.1 216020 7680 ? S 17:25 0:00 /usr/sbin/apache2 -k start
www-data 14902 0.0 0.2 220268 13632 ? S 17:25 0:00 /usr/sbin/apache2 -k start
www-data 14903 0.0 0.1 216412 8988 ? S 17:25 0:00 /usr/sbin/apache2 -k start
www-data 14904 0.0 0.2 219756 13268 ? S 17:25 0:00 /usr/sbin/apache2 -k start
www-data 14905 0.0 0.2 223396 16840 ? S 17:25 0:00 /usr/sbin/apache2 -k start
www-data 15161 0.0 0.1 216008 7588 ? S 17:49 0:00 /usr/sbin/apache2 -k start
root 16184 0.0 0.0 7640 928 pts/1 S+ 18:55 0:00 grep --color=auto apache
Usually if apache is not given the root privilege, this sort of issue might occur, but here the privilege is root. I am not sure where am I messing up the configuration part.
Any suggestion will be appreciated.
Set:
$config['base_url'] = '';
And let us know if it changes anything in the output.
Also, if you're using cookies, set the $config['cookie_path'] = "/project";

Run php-cgi process

Today earlier my nginx server was 100% CPU usage, the process using all CPU was php-cgi.
I login and kill all php-cgi with this command.
kill -s 9 PID
Now after restarting my server is not working, I see the message "No input file specified.". I google this message, but nothing works, I suppose I have just to start php-cgi again, but can't find how start it.
UPDATE
If I run top command, I can see php-cgi running
1049 root 20 0 336m 20m 10m S 0.0 0.3 0:00.37 httpd
1051 apache 20 0 219m 5472 608 S 0.0 0.1 0:00.55 httpd
1080 root 20 0 20888 1180 592 S 0.0 0.0 0:00.02 crond
1182 root 20 0 19256 976 384 S 0.0 0.0 0:00.00 nginx
1183 nginx 20 0 19856 3176 1364 S 0.0 0.1 0:05.65 nginx
2326 apache 20 0 337m 13m 2512 S 0.0 0.2 0:02.07 httpd
2331 apache 20 0 337m 13m 2564 S 0.0 0.2 0:02.10 httpd
2696 root 20 0 96656 3820 2944 S 0.0 0.1 0:00.18 sshd
2701 root 20 0 12084 1696 1336 S 0.0 0.0 0:00.03 bash
2808 apache 20 0 337m 12m 1988 S 0.0 0.2 0:00.22 httpd
2864 root 20 0 12632 1228 948 R 0.0 0.0 0:00.29 top
2908 ulisses 20 0 183m 11m 6704 S 0.0 0.2 0:00.07 php-cgi
Run ps aux command, also show cgi-php
root 1049 0.0 0.3 344532 20700 ? Ss 14:39 0:00 /usr/sbin/httpd
apache 1051 0.0 0.0 224920 5472 ? S 14:39 0:00 /usr/sbin/httpd
root 1080 0.0 0.0 20888 1180 ? Ss 14:39 0:00 crond
root 1182 0.0 0.0 19256 976 ? Ss 14:43 0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx 1183 0.0 0.0 19856 3176 ? S 14:43 0:05 nginx: worker process
apache 2326 0.0 0.2 345492 13900 ? S 16:56 0:02 /usr/sbin/httpd
apache 2331 0.0 0.2 345480 13944 ? S 16:57 0:02 /usr/sbin/httpd
root 2696 0.0 0.0 96656 3820 ? Ss 17:41 0:00 sshd: root#pts/0
root 2701 0.0 0.0 12084 1696 pts/0 Ss 17:42 0:00 -bash
apache 2808 0.0 0.2 345164 12848 ? S 17:52 0:00 /usr/sbin/httpd
ulisses 2929 0.8 0.1 187732 11976 ? S 18:06 0:00 /usr/bin/php-cgi -c /var/www/vhosts/teclasap.com.br/etc/php.ini
root 2932 0.0 0.0 10480 932 pts/0 R+ 18:06 0:00 ps aux
You can kill all php-cgi by
sudo killall -9 php-cgi

php sessions saved in ramdisk

I'm trying to save my php session on ramdisk. I have a permission problem but i can't see what where it's the problem.
I have the ramdisk:
/dev/ram0 407M 2.4M 404M 1% /var/lib/php/session/ramd
I have the permissions:
drwxrwx---. 3 root apache 1024 Mar 24 01:53 ramd
My error:
Warning: session_start(): open(/var/lib/php/session/ramd/sess_b0ko6hl3p6ojj2ot3qfqvm9km1, O_RDWR) failed: Permission denied (13) in /var/www/html/index.php on line 3 Warning: Unknown: open(/var/lib/php/session/ramd/sess_b0ko6hl3p6ojj2ot3qfqvm9km1, O_RDWR) failed: Permission denied (13) in Unknown on line 0 Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php/session/ramd) in Unknown on line 0
In php.ini, session.save_path variable it's set to "/var/lib/php/session"
In my script i set session.save_path to "var/lib/php/session/ramd"
If i umont the ramdisk that i created, i can save my sessions in /rand folder. It i mount.. i can't. I tried also chmod root:root / apache:apache with chmod 0777 1777. now it's 0770.
I using: CentOS 6.4, PHP 5.3.3, Apache/2.2.15
Can anybody help me with this problem??
LE:
[root#localhost ~]# ps aux | grep apache
apache 2355 0.0 0.4 394868 7840 ? S 01:53 0:00 /usr/sbin/httpd
apache 2356 0.0 0.4 394876 7844 ? S 01:53 0:00 /usr/sbin/httpd
apache 2357 0.0 0.4 394876 7824 ? S 01:53 0:00 /usr/sbin/httpd
apache 2358 0.0 0.4 394876 7816 ? S 01:53 0:00 /usr/sbin/httpd
apache 2360 0.0 0.4 394876 7900 ? S 01:53 0:00 /usr/sbin/httpd
apache 2361 0.0 0.4 394876 7800 ? S 01:53 0:00 /usr/sbin/httpd
apache 2362 0.0 0.4 394876 7844 ? S 01:53 0:00 /usr/sbin/httpd
apache 2363 0.0 0.4 394868 7716 ? S 01:53 0:00 /usr/sbin/httpd
root 3119 0.0 0.0 103248 868 pts/0 S+ 02:52 0:00 grep apache
[root#localhost ~]# ps aux | grep php
root 3132 0.0 0.0 103244 868 pts/0 S+ 02:54 0:00 grep php
Execute the following to see if SELinux is in enforcing mode:
# sestatus
If so, you may want to try disabling SELinux by running the following as root (or with sudo):
# setenforce 0
This will make SELinux stop enforcing any policies. If this solves the issue, you will have to either leave SELinux off or augment the policy to allow this new path to work out correctly. If it does get to that point, reference https://serverfault.com/a/323528/165777 for some information on how to perform that step!
Also, if that didn't make an impact and/or you want to re-enable SELinux, execute:
# setenforce 1

Categories