☰

para onde vão os dados gravados no descritor de arquivo que nunca foi aberto

tag-icon • tag-icon file-descriptors strace ipc
para onde vão os dados gravados no descritor de arquivo que nunca foi aberto

Eu tenho a saída capturada pelo seguinte comando:

$ strace -f -e trace=process,socketpair,open,close,dup,dup2,read,write -o rsync.log rsync -avcz --progress src/ dst/

é um pouco longo, então eu carregueiaqui. Agora quero fazer algumas análises neste arquivo.

A saída a seguir mostra processos/threads gerados usando clonesyscall:

# SPAWNED PROCESSES/THREADS
$ grep 'clone(' rsync.log | awk '{print $1 " -> " $NF}'
1399 -> 1400
1400 -> 1401

A saída a seguir mostra que na maioria das vezes os dados eram writen para o descritor de arquivo com número 4:

# PID, FD, NO OF CALLING WRITE SYSCALL
$ cat <(grep 'write(' rsync.log | egrep -v 'unfinished|resumed') <(paste <(grep write rsync.log | grep unfinished) <(grep write rsync.log | grep resumed)) | cut -d',' -f1 | sed 's%write(%%' | awk '{a[$0]++}END{print "PID  FD COUNT"; for(i in a){print i " " a[i]}}'
PID  FD COUNT
1399  4 1622
1400  1 7
1401  3 307
1401  4 7
1399  1 15

A saída a seguir mostra que o 4descritor nunca foi aberto usando opensyscall (1 é STDOUT, então presumo que não há necessidade de abrir este FD):

# LIST OF FILE DESCRIPTORS THAT WAS OPEN
$ grep 'open(' rsync.log | awk 'BEGIN {FS=" = "} {print $NF}' | grep '^[0-9]\+$' | sort | uniq
0
3
6

Duas questões:

I. Se 4o descritor não foi openeditado, para onde vão esses dados e como é possível que rsyncfuncionem conforme o esperado?:

$ grep 'write(4' rsync.log | head
1399  write(4, "\37\0\0\0", 4 <unfinished ...>
1399  write(4, "I\0\0\7\5(\1.\0\0\0W}%i\360\220\261\177\21\370A\0\0\0\203\347\6vbox"..., 77 <unfinished ...>
1401  write(4, "\4\0\0\7\376\377\377\377", 8) = 8
1399  write(4, "\177\301\0\7\3\n\200\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\177\377\354\226C\214.\0\260"..., 49539) = 49539
1399  write(4, "\2\301\0\7\177\377a\353\35\2433\1\332m\301\330\266\315\216\3557\352\330\266m\333\366\33\333\266;v"..., 49414) = 49414
1399  write(4, "\21\302\0\7\177\377\236mTNG\356\304\376u\237\214\275\310\300*\317\264\221W\372\340\307\36\345%\330"..., 49685 <unfinished ...>
1399  write(4, "\360\300\0\7\177\377\27W\357\24$\f\23,\v\216\355\371\306\266m\333\266m\333\266m\333\266m\333\266"..., 49396 <unfinished ...>
1399  write(4, "\223\301\0\7\177\377D\214# D\304\2\25xA\fY\310U\201Q*e\25\235\20\213\v\320~\331"..., 49559 <unfinished ...>
1399  write(4, "\370\300\0\7\177\377l\275cs.\0\27$\30\334\330\266}c\333\266m\333\266\235<\261m\333\266m"..., 49404 <unfinished ...>
1399  write(4, "\20\301\0\7\177\377\25\255\252Q\223\340\244w3\247\252\322Z\235\310\2424g\330\274\354\3150\237B\26"..., 49428) = 49428

II. De alguma forma, também posso obter dados (linhas correspondentes) que foram transferidos entre processos, por exemplo: de 1399para 1400ou de 1399para 1401etc. (se houver)?

Obrigado

Responder1

Os dados gravados em um descritor de arquivo que nunca foi aberto não vão a lugar nenhum. A writechamada do sistema falha com EBADF(descritor de arquivo inválido).

Mas comomeuh comentou, opennão é a única maneira de abrir um arquivo. Há também pipepara criar um par de extremidades de tubo, socketpairpara criar um par de soquetes que se comuniquem entre si sockete acceptpara criar soquetes que se comuniquem com um endereço remoto, etc. (sem mencionar os tipos de arquivo que você não pode write, como como diretórios, inotify filas de eventos, etc.)

informação relacionada