☰

¿Adónde van los datos escritos en el descriptor de archivo que nunca se abrió?

tag-icon • tag-icon file-descriptors strace ipc
¿Adónde van los datos escritos en el descriptor de archivo que nunca se abrió?

Tengo salida capturada por el siguiente comando:

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

es un poco largo así que lo he subidoaquí. Ahora quiero hacer un análisis de este archivo.

El siguiente resultado muestra procesos/hilos generados usando clonesyscall:

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

El siguiente resultado muestra que la mayoría de las veces los datos estaban writeen un descriptor de archivo con 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

El siguiente resultado muestra que el 4descriptor nunca se abrió usando opensyscall (1 es STDOUT, por lo que supongo que no es necesario 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

Dos preguntas:

I. Si 4no se openeditó el descriptor, ¿a dónde van esos datos y cómo es posible que rsynchaya funcionado como se esperaba?:

$ 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. ¿Puedo de alguna manera obtener también datos (líneas correspondientes) que se transfirieron entre procesos, por ejemplo: desde 1399hacia 1400o desde 1399hacia 1401, etc. (si los hay)?

Gracias

Respuesta1

Los datos escritos en un descriptor de archivo que nunca se abrió no van a ninguna parte. La writellamada al sistema falla con EBADF(descriptor de archivo incorrecto).

Pero comomeuh comentó, openno es la única forma de abrir un archivo. También hay pipeque crear un par de extremos de tubería, socketpaircrear un par de sockets que se comuniquen entre sí sockety acceptcrear sockets que se comuniquen con una dirección remota, etc. (Sin mencionar los tipos de archivos que no se pueden writecomunicar, como directorios, notificar colas de eventos, etc.)

información relacionada