Я отлаживаю проблему, в которой MoinMoin
в CentOS выдает ошибку разрешений, но я не могу отследить, где находится проблемный файл / каталог.
Я побежал strace -vp <pid>
на apache pid; когда у меня есть проблема, я вижу это:
epoll_wait(10, {{EPOLLIN, {u32=3487534344, u64=140367313734920}}}, 2, 10000) = 1
accept4(6, {sa_family=AF_INET6, sin6_port=htons(52621), inet_pton
(AF_INET6, "::ffff:105.193.30.91", &sin6_addr), sin6_flowinfo=0,
sin6_scope_id=0}, [28], SOCK_CLOEXEC) = 11
## Later on...
read(7, 0x7fffa658ad7f, 1) = -1 EAGAIN (Resource temporarily
unavailable)
Однако, поскольку apache уже запущен, я не вижу соответствующего open()
в файле, называемом 7
; поэтому я вижу проблему с разрешениями, но я все еще не знаю который файл проблема.
Я знаю, что могу попытаться поймать все открывающиеся файлы, когда возрожу apache, но я надеюсь, что есть способ сопоставить файл 7
к реальному имени файла ... есть ли способ сделать это?
РЕДАКТИРОВАТЬ 1:
Воспользовавшись руководством @lain, я побежал lsof | grep 266474069
, но результаты неясны ...
[root@lnxlmf moin]# ls -la /proc/9707/fd/7
lr-x------. 1 root root 64 Aug 28 15:39 /proc/9707/fd/7 -> pipe:[266474069]
[root@lnxlmf moin]#
[root@lnxlmf moin]# lsof | grep 266474069
httpd 9703 root 7r FIFO 0,8 0t0 266474069 pipe
httpd 9703 root 8w FIFO 0,8 0t0 266474069 pipe
httpd 9705 apache 7r FIFO 0,8 0t0 266474069 pipe
httpd 9705 apache 8w FIFO 0,8 0t0 266474069 pipe
httpd 9706 apache 7r FIFO 0,8 0t0 266474069 pipe
httpd 9706 apache 8w FIFO 0,8 0t0 266474069 pipe
httpd 9707 apache 7r FIFO 0,8 0t0 266474069 pipe
httpd 9707 apache 8w FIFO 0,8 0t0 266474069 pipe
httpd 9733 apache 7r FIFO 0,8 0t0 266474069 pipe
httpd 9733 apache 8w FIFO 0,8 0t0 266474069 pipe
[root@lnxlmf moin]#
Я вижу, что это канал FIFO, но что это означает для моей конфигурации системы? Как я могу отследить первопричину EAGAIN
проблема?
РЕДАКТИРОВАТЬ 2:
Спасибо @Alan Curry, бегу strace -fp <pid_of_wsgi_proc>
кажется, уводит меня немного дальше ...
[pid 9731] stat("/opt/moin/share/moin/wikiconfig.py", {st_mode=S_IFREG|0770, st_size=6463, ...}) = 0
[pid 9731] stat("/opt/moin/share/moin/data/pages", {st_mode=S_IFDIR|0770, st_size=4096, ...}) = 0
[pid 9731] access("/opt/moin/share/moin/data/pages", R_OK|W_OK|X_OK) = -1 EACCES (Permission denied)
Однако и apache, и wsgi
бежать как apache
пользователь ...
[root@lnxlmf moin]# ps auxw | grep -E "apache|wsgi"
apache 10187 0.0 0.1 373488 5884 ? Sl 17:18 0:00 moin_http_wsgi
apache 10188 0.0 0.1 373488 5884 ? Sl 17:18 0:00 moin_https_wsgi
apache 10189 0.0 0.1 185096 5824 ? S 17:18 0:00 /usr/sbin/httpd
root 10243 0.0 0.0 103240 848 pts/1 S+ 17:21 0:00 grep -E apache|wsgi
[root@lnxlmf moin]#
Тем не менее, когда я запускаю следующие команды и перезапускаю apache, я все еще не могу решить проблему ...
[root@lnxlmf moin]# pwd
/opt/moin/share/moin
[root@lnxlmf moin]# chown -R apache:apache data/
[root@lnxlmf moin]# sudo chmod -R ug+rwx data/
[root@lnxlmf moin]# sudo chmod -R o-rwx data/
Я использую это в своей вики-конфигурации http:
<VirtualHost *:443>
ServerName netwiki.foo.com
DocumentRoot /opt/moin/share/moin
WSGIScriptAlias / /opt/moin/share/moin/server/moin.wsgi
WSGIDaemonProcess moin_https display-name=moin_https_wsgi \
user=apache group=apache \
processes=1 threads=10 maximum-requests=1000 umask=0007
WSGIProcessGroup moin_https
WSGIApplicationGroup %{GLOBAL}
# Generate with...
# openssl req -new -x509 -days 365 -nodes -out netwiki.pem -keyout netwiki.key
SSLEngine on
SSLCertificateFile /etc/httpd/ssl/netwiki.pem
SSLCertificateKeyFile /etc/httpd/ssl/netwiki.key
</VirtualHost>
Взгляните в /proc/<PID>/fd
в котором должны быть перечислены все открытые файлы, PID
открыл.
В моей системе CentOS fd 7
lrwx------. 1 root root 64 Aug 28 22:01 7 -> socket:[1872522]
Тогда я могу использовать netstat -ane | grep 1872522
получить
tcp 0 0 :::443 :::* LISTEN 0 1872522
Ты можешь использовать
lsof | grep 266474069
получить информацию о трубе.
Глядя на свой маленький VPS, я могу определить номер fd следующим образом:
ll /proc/17684/fd/ |colrm 1 46
0 -> /dev/null
1 -> /dev/null
10 -> /var/www/vhosts/censored.xenuser.org/statistics/logs/error_log
11 -> /var/www/vhosts/censored.de/statistics/logs/error_log
12 -> /var/www/vhosts/censored.org/statistics/logs/error_log
13 -> /var/www/vhosts/xenuser.org/statistics/logs/error_log
14 -> /var/log/apache2/access.log
[и так далее, где 17684 - это PID процесса, который я использовал ранее]
Проблема была в том, что у меня SELINUX=enforcing
в /etc/selinux/config
.
После того, как я установил SELINUX=permissive
, SELINUXTYPE=targeted
, и перезагрузился wsgi
может получить доступ ко всем файлам правильно.