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";
Related
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.
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.
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
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
Environment
PHP -V output: PHP 5.3.5-1ubuntu7.2 with Suhosin-Patch (cli) (built: May 2 2011 23:00:17) Copyright (c) 1997-2009 The PHP Group Zend Engine v2.3.0, Copyright (c) 1998-2010 Zend Technologies
cat /etc/issue output: Ubuntu 11.04
Apache2 -V ouput: Server version: Apache/2.2.17 (Ubuntu) Server built: Sep 1 2011 09:31:14
Browser About output: Firefox 6.0.2
PS -AUX Ouput
root 2943 0.0 0.3 206420 12428 ? Ss Sep19 0:20 /usr/sbin/apache2 -k start
www-data 18658 0.0 0.2 208552 11096 ? S Sep25 0:00 /usr/sbin/apache2 -k start
www-data 18659 0.0 0.3 208976 12036 ? S Sep25 0:00 /usr/sbin/apache2 -k start
www-data 18660 0.0 0.3 210532 12476 ? S Sep25 0:00 /usr/sbin/apache2 -k start
www-data 18661 0.0 0.3 210276 11820 ? S Sep25 0:00 /usr/sbin/apache2 -k start
www-data 18662 0.0 0.2 206948 10236 ? S Sep25 0:00 /usr/sbin/apache2 -k start
www-data 20037 0.0 0.3 208976 12128 ? S 08:22 0:00 /usr/sbin/apache2 -k start
www-data 20039 0.0 0.3 209132 11748 ? S 08:23 0:00 /usr/sbin/apache2 -k start
www-data 20120 0.0 0.3 209004 12000 ? S 09:04 0:00 /usr/sbin/apache2 -k start
File Permissions
drwxr-xr-x 2 www-data www-data 4096 2011-09-26 15:24 .
drwxr-xr-x 4 www-data www-data 4096 2011-08-26 11:31 ..
-rw-r--r-- 1 root root 161976 2011-08-26 16:26 market.txt
-rw-r--r-- 1 root root 0 2011-09-26 14:55 test1.txt
-rw-r--r-- 1 root root 0 2011-09-26 14:55 test2.txt
-rw-r--r-- 1 root root 0 2011-09-26 14:55 test3.txt
-rw-r--r-- 1 root root 0 2011-09-26 14:55 test4.txt
-rw-r--r-- 1 root root 0 2011-09-26 15:02 test5.txt
Code
rename($file, "$dest/$file");
Question
When I run the above code on the files listed in the File Permissions section above, it properly moves the file from its current location to a new location and removes the original. How is this possible when apache2 is running as www-data and the files are owned by root and only have read access for non-root users? On the PHP documentation it says:
Warnings may be generated if the destination filesystem doesn't permit chown() or chmod() system calls to be made on files — for example, if the destination filesystem is a FAT filesystem.
Does rename() call either of those system functions during the process? If so, why? Not that it matters anyway as www-data should not be able to chown/chmod a file owned by root anyway.
Can anyone explain to me how this is occuring?
Additional Information
I have tried this with the PHP script owned by root and by www-data and it works.
I tried to provide as much pertinent info as possible but let me know if you need anything else.
Moves don't "remove" originals, unless the move takes place across filesystem boundaries. Within a single filesystem, a move simply rewrites the relevant directory entries so it APPEARS that you've copied/deleted the file, but all you've done is a bit of housekeeping. Since www-data owns the directories in question, it can rewrite the directory entries representing those files all it wants, and never touch the actual files.
When moving files you are not editing the files themselves, but rather the directory they are part of. In your case that directory is owned by www-data (the apache process)