soc pai processo morto por falha de conexão

2

Pergunta curta

Tentativas de conexão com falha em um processo forking socat parecem estar eliminando o processo pai. Isso é um inseto? Qual é a melhor solução para isso?

Longa Pergunta

Estou executando um socat server (versões socat 1.7.3.1 e 1.7.3.2) com criptografia OpenSSL (para verificação do servidor). Estou usando o seguinte comando para iniciar o servidor:

socat -d -d -d -d -U \
-lf /var/log/socat.log \
openssl-listen:8888,fork,reuseaddr,cert=server.pem,dhparam=dhparam.pem,verify=0 \
gopen:"file.txt" &

Estou usando a opção fork , para que cada conexão com o servidor seja executada em um processo filho separado. Eu posso conectar com sucesso ao servidor usando o seguinte comando do cliente:

socat - openssl-connect:hostname:8888,cafile=server.crt

Eu também tentei me conectar sem fornecer o certificado do servidor, por exemplo:

socat - openssl-connect:hostname:8888

Quando fiz isso, recebi o seguinte erro (como esperado):

YYYY/mm/dd HH:MM:SS socat[3464] E SSL_connect(): error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed

Mas o processo do servidor também termina. Isso foi inesperado. Recebo resultados semelhantes com outras tentativas de conexão malsucedidas, por exemplo tentando se conectar com o netcat:

nc hostname 8888

Nesse caso, a conexão é interrompida até que eu a mate. No entanto, como antes, isso não apenas mata a tentativa de conexão atual (o processo filho), mas também mata o servidor (o processo pai).

Eu tentei verificar o arquivo de log. Durante a tentativa de conexão, as seguintes mensagens são gravadas no arquivo de log:

 1  YYYY/mm/dd HH:MM:SS socat[PPID] D select -> (, 0x40, 0x0, 0x0, NULL/0.000000), 1
 2  YYYY/mm/dd HH:MM:SS socat[PPID] D accept(6, 0xbedc0224, 0xbedc020c)
 3  YYYY/mm/dd HH:MM:SS socat[PPID] I accept(6, {2, AF=2 127.0.0.1:54862}, 16) -> 7
 4  YYYY/mm/dd HH:MM:SS socat[PPID] D fcntl(7, 2, 1)
 5  YYYY/mm/dd HH:MM:SS socat[PPID] D fcntl() -> 0
 6  YYYY/mm/dd HH:MM:SS socat[PPID] D getpeername(7, 0xbedc0234, 0xbedc021c{16})
 7  YYYY/mm/dd HH:MM:SS socat[PPID] D getpeername(, {AF=2 127.0.0.1:54862}, {16}) -> 0
 8  YYYY/mm/dd HH:MM:SS socat[PPID] D getsockname(7, 0xbedc02a4, 0xbedc0220{16})
 9  YYYY/mm/dd HH:MM:SS socat[PPID] D getsockname(, {AF=2 127.0.1.1:8888}, {16}) -> 0
10  YYYY/mm/dd HH:MM:SS socat[PPID] N accepting connection from AF=2 127.0.0.1:54862 on AF=2 127.0.1.1:8888
11  YYYY/mm/dd HH:MM:SS socat[PPID] I permitting connection from AF=2 127.0.0.1:54862
12  YYYY/mm/dd HH:MM:SS socat[PPID] D sigprocmask(0, 0xbedc0314, 0x0)
13  YYYY/mm/dd HH:MM:SS socat[PPID] D sigprocmask() -> 0
14  YYYY/mm/dd HH:MM:SS socat[PPID] D fork()
15  YYYY/mm/dd HH:MM:SS socat[PPID] D fork() -> PID
16  YYYY/mm/dd HH:MM:SS socat[PPID] N forked off child process PID
17  YYYY/mm/dd HH:MM:SS socat[PPID] I close(7)
18  YYYY/mm/dd HH:MM:SS socat[PPID] D close()  -> 0
19  YYYY/mm/dd HH:MM:SS socat[PPID] D sigprocmask(1, 0xbedc0314, 0x0)
20  YYYY/mm/dd HH:MM:SS socat[PPID] D sigprocmask() -> 0
21  YYYY/mm/dd HH:MM:SS socat[PPID] I still listening
22  YYYY/mm/dd HH:MM:SS socat[PPID] N listening on AF=2 0.0.0.0:8888
23  YYYY/mm/dd HH:MM:SS socat[PPID] D select(7, &0x48, &0x0, &0x0, NULL/0.000000)
24  YYYY/mm/dd HH:MM:SS socat[PID] D fork() -> 0
25  YYYY/mm/dd HH:MM:SS socat[PID] D getpid()
26  YYYY/mm/dd HH:MM:SS socat[PID] D getpid() -> PID
27  YYYY/mm/dd HH:MM:SS socat[PID] I just born: child process PID
28  YYYY/mm/dd HH:MM:SS socat[PID] D setenv("SOCAT_PID", "0", 1)
29  YYYY/mm/dd HH:MM:SS socat[PID] D setenv() -> 0
30  YYYY/mm/dd HH:MM:SS socat[PID] D getpid()
31  YYYY/mm/dd HH:MM:SS socat[PID] D getpid() -> PID
32  YYYY/mm/dd HH:MM:SS socat[PID] D sigprocmask(1, 0xbedc0314, 0x0)
33  YYYY/mm/dd HH:MM:SS socat[PID] D sigprocmask() -> 0
34  YYYY/mm/dd HH:MM:SS socat[PID] I just born: child process PID
35  YYYY/mm/dd HH:MM:SS socat[PID] D setenv("SOCAT_PID", "PID", 1)
36  YYYY/mm/dd HH:MM:SS socat[PID] D setenv() -> 0
37  YYYY/mm/dd HH:MM:SS socat[PID] I close(6)
38  YYYY/mm/dd HH:MM:SS socat[PID] D close()  -> 0
39  YYYY/mm/dd HH:MM:SS socat[PID] D setenv("SOCAT_SOCKADDR", "127.0.1.1", 1)
40  YYYY/mm/dd HH:MM:SS socat[PID] D setenv() -> 0
41  YYYY/mm/dd HH:MM:SS socat[PID] D setenv("SOCAT_SOCKPORT", "8888", 1)
42  YYYY/mm/dd HH:MM:SS socat[PID] D setenv() -> 0
43  YYYY/mm/dd HH:MM:SS socat[PID] D setenv("SOCAT_PEERADDR", "127.0.0.1", 1)
44  YYYY/mm/dd HH:MM:SS socat[PID] D setenv() -> 0
45  YYYY/mm/dd HH:MM:SS socat[PID] D setenv("SOCAT_PEERPORT", "54862", 1)
46  YYYY/mm/dd HH:MM:SS socat[PID] D setenv() -> 0
47  YYYY/mm/dd HH:MM:SS socat[PID] D SSL_new(0x231f868)
48  YYYY/mm/dd HH:MM:SS socat[PID] D SSL_new() -> 0x2320f00
49  YYYY/mm/dd HH:MM:SS socat[PID] D SSL_set_fd(0x2320f00, 7)
50  YYYY/mm/dd HH:MM:SS socat[PID] D SSL_set_fd() -> 1
51  YYYY/mm/dd HH:MM:SS socat[PID] D SSL_accept(0x2320f00)
52  YYYY/mm/dd HH:MM:SS socat[PID] D SSL_accept() -> -1
53  YYYY/mm/dd HH:MM:SS socat[PID] E SSL_accept(): Success
54  YYYY/mm/dd HH:MM:SS socat[PID] N exit(1)
55  YYYY/mm/dd HH:MM:SS socat[PID] D starting xioexit()
56  YYYY/mm/dd HH:MM:SS socat[PID] D SSL_shutdown(0x2320f00)
57  YYYY/mm/dd HH:MM:SS socat[PPID] N socat_signal(): handling signal 11
58  YYYY/mm/dd HH:MM:SS socat[PPID] D select -> (, 0x8, 0x0, 0x0, NULL/0.000000), 1
59  YYYY/mm/dd HH:MM:SS socat[PPID] D select(7, &0x48, &0x0, &0x0, NULL/0.000000)
60  YYYY/mm/dd HH:MM:SS socat[PPID] E exiting on signal 11
61  YYYY/mm/dd HH:MM:SS socat[PPID] N exit(139)
62  YYYY/mm/dd HH:MM:SS socat[PPID] D starting xioexit()
63  YYYY/mm/dd HH:MM:SS socat[PPID] I close(6)
64  YYYY/mm/dd HH:MM:SS socat[PPID] D close()  -> 0
65  YYYY/mm/dd HH:MM:SS socat[PPID] D finished xioexit()

Portanto, parece que há uma falha de segmentação (sinal 11) no processo filho, e isso faz com que o processo pai termine. Minha solução atual é executar o comando socat em um loop, por exemplo:

while true; do
socat -d -d -d -d -U \
-lf /var/log/socat.log \
openssl-listen:8888,fork,reuseaddr,cert=server.pem,dhparam=dhparam.pem,verify=0 \
gopen:"file.txt" &
done

Mas isso parece deselegante - certamente deve haver uma solução melhor.

    
por igal 08.10.2018 / 22:37

0 respostas