
Estou depurando um problema ondeMoinMoin
no CentOS está gerando um erro de permissão, mas não consigo rastrear onde está o arquivo/diretório problemático.
Corri strace -vp <pid>
no apache pid; quando tenho o problema eu vejo isso:
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)
No entanto, como o Apache já está em execução, não vejo nenhuma correspondência open()
no arquivo referido como 7
; então vejo o problema de permissões, mas ainda não seiqualarquivo é o problema.
Eu sei que poderia tentar capturar todos os arquivos abertos quando eu reaparecer o Apache, mas espero que haja uma maneira de mapear o arquivo 7
para um nome de arquivo real... existe uma maneira de fazer isso?
EDITAR 1:
Usando a orientação de @lain, executei lsof | grep 266474069
, mas os resultados não são claros...
[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]#
Vejo que este é um canal FIFO, mas o que isso significa para a configuração do meu sistema? Como posso rastrear a causa raiz do EAGAIN
problema?
EDITAR 2:
Graças a @Alan Curry, correr strace -fp <pid_of_wsgi_proc>
parece me levar um pouco mais longe...
[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)
No entanto, tanto o apache quanto wsgi
o executado como apache
usuário ...
[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]#
No entanto, quando executo os seguintes comandos e reinicio o Apache, ainda não consigo resolver o problema...
[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/
Estou usando isso na configuração http do meu wiki:
<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>
Responder1
Dê uma olhada no /proc/<PID>/fd
que deve listar todos os arquivos abertos que PID
foram abertos.
No meu sistema CentOS fd 7 é
lrwx------. 1 root root 64 Aug 28 22:01 7 -> socket:[1872522]
Posso então usar netstat -ane | grep 1872522
para obter
tcp 0 0 :::443 :::* LISTEN 0 1872522
Você pode usar
lsof | grep 266474069
para obter informações sobre o tubo.
Responder2
Olhando para o meu pequeno VPS, posso determinar o número fd da seguinte maneira:
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
[e assim por diante, onde 17684 é o PID do processo que rastreei anteriormente]
Responder3
O problema é que eu tinha SELINUX=enforcing
em /etc/selinux/config
.
Depois de definir SELINUX=permissive
, SELINUXTYPE=targeted
e reinicializar, wsgi
posso acessar todos os arquivos corretamente.