O que está causando o comando Copiar para entrar no estado de suspensão?

Question

Estou tentando copiar recursivamente um diretório enorme de instaláveis acima de 25G e quero preservar o ID do proprietário e do grupo, os modos de permissão e assim por diante.

Então eu corri os comandos abaixo:

bash-3.2$ date; cp -rpP /source/path/Oracle /target/path/Oracle;date;
Tue Jun  4 09:44:54 EDT 2013

...

Algumas observações:

• Hoje (quarta-feira 5 de junho 12:09:25 EDT 2013) noto que ainda não foi concluído e parece estar preso em algum lugar. Eu comecei a analisar o processo e parece estar dormindo:

  bash-3.2$ truss -p 09431;
  read(10, 0xFFBEF288, 32768)     (sleeping...)
  

• A última entrada também mostra que está dormindo.

  bash-3.2$ pflags 09431
  9431:   cp -rpP /source/path/Oracle /target/path/Oracle
          data model = _ILP32  flags = RLC|ASYNC|MSACCT|MSFORK
          flttrace = 0xfffffbff
          sigtrace = 0xfffffeff 0xffffffff
          HUP|INT|QUIT|ILL|TRAP|ABRT|EMT|FPE|BUS|SEGV|SYS|PIPE|ALRM|TERM|USR1|USR2|CLD|PWR|WINCH|URG|POLL|STOP|TSTP|CONT|TTIN|TTOU|VTALRM|PROF|XCPU|XFSZ|WAITING|LWP|FREEZE|THAW|CANCEL|LOST|XRES|JVM1|JVM2|RTMIN|RTMIN+1|RTMIN+2|RTMIN+3|RTMAX-3|RTMAX-2|RTMAX-1|RTMAX
      entryset = 0x00000401 0x04000000 0x00000000 0x00000028
                 0x80000000 0x00000000 0x00000000 0x00000000
      exitset  = 0xfffffffe 0xffffffff 0xffffffff 0xffffffd7
                 0x7fffffff 0xffffffff 0xffffffff 0xffffffff
   /1:    flags = ASLEEP  read(0xa,0xffbef288,0x8000)
  

• Finalmente, tentei pfiles

  bash-3.2$ pfiles -F 09431
  9431:   cp -rpP /source/path/Oracle /target/path/Oracle
  Current rlimit: 256 file descriptors
  0: S_IFCHR mode:0620 dev:363,0 ino:12582922 uid:502012187 gid:7 rdev:24,3
    O_RDWR|O_NOCTTY|O_LARGEFILE
    /devices/pseudo/pts@0:3
  1: S_IFCHR mode:0620 dev:363,0 ino:12582922 uid:502012187 gid:7 rdev:24,3
    O_RDWR|O_NOCTTY|O_LARGEFILE
    /devices/pseudo/pts@0:3
  2: S_IFCHR mode:0620 dev:363,0 ino:12582922 uid:502012187 gid:7 rdev:24,3
    O_RDWR|O_NOCTTY|O_LARGEFILE
    /devices/pseudo/pts@0:3
  3: S_IFDIR mode:0750 dev:377,1 ino:1135681 uid:502012187 gid:502012187 size:4096
    O_RDONLY|O_NDELAY|O_LARGEFILE FD_CLOEXEC
    /source/path/Oracle
  4: S_IFDIR mode:0750 dev:377,1 ino:1135682 uid:502012187 gid:502012187 size:4096
    O_RDONLY|O_NDELAY|O_LARGEFILE FD_CLOEXEC
    /source/path/Oracle/Middleware
  5: S_IFDIR mode:0750 dev:377,1 ino:14640507 uid:502012187 gid:502012187 size:4096
    O_RDONLY|O_NDELAY|O_LARGEFILE FD_CLOEXEC
    /source/path/Oracle/Middleware/user_projects
  6: S_IFDIR mode:0750 dev:377,1 ino:14640508 uid:502012187 gid:502012187 size:4096
    O_RDONLY|O_NDELAY|O_LARGEFILE FD_CLOEXEC
    /source/path/Oracle/Middleware/user_projects/epmsystem2
  7: S_IFDIR mode:0750 dev:377,1 ino:6480147 uid:502012187 gid:502012187 size:4096
    O_RDONLY|O_NDELAY|O_LARGEFILE FD_CLOEXEC
    /source/path/Oracle/Middleware/user_projects/epmsystem2/EssbaseServer
  8: S_IFDIR mode:0750 dev:377,1 ino:6480149 uid:502012187 gid:502012187 size:4096
    O_RDONLY|O_NDELAY|O_LARGEFILE FD_CLOEXEC
    /source/path/Oracle/Middleware/user_projects/epmsystem2/EssbaseServer/essbaseserver1
  9: S_IFDIR mode:0750 dev:377,1 ino:6480151 uid:502012187 gid:502012187 size:4096
    O_RDONLY|O_NDELAY|O_LARGEFILE FD_CLOEXEC
    /source/path/Oracle/Middleware/user_projects/epmsystem2/EssbaseServer/essbaseserver1/bin
  10: S_IFIFO mode:0660 dev:377,1 ino:9088704 uid:502012187 gid:502012187 size:0
    O_RDONLY|O_LARGEFILE
    /source/path/Oracle/Middleware/user_projects/epmsystem2/EssbaseServer/essbaseserver1/bin/ESSBASE1_1
  11: S_IFREG mode:0660 dev:326,22000 ino:128325 uid:502012187 gid:502012187 size:0
    O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE
    /target/path/Oracle/Middleware/user_projects/epmsystem2/EssbaseServer/essbaseserver1/bin/ESSBASE1_1
  

UPDATE: Observe que o processo cp acima foi eliminado. Então, as observações abaixo estão tentando reproduzir o problema.

• Arquivo que está sendo bloqueado:

  bash-3.2$ ls -l ESSBASE1_1
  prw-rw----   1 kent   kent         0 Nov 22  2011 ESSBASE1_1
  

• Quando tento copiar este arquivo individualmente:

  bash-3.2$ cp ESSBASE1_1 ESSBASE1_1kent  # PID = 08745
  
  ...
  

  ele trava também.

• Olhando para pflags , parece estar dormindo.

  bash-3.2$ pflags 08745
  8745:   cp ESSBASE1_1 ESSBASE1_1kent
          data model = _ILP32  flags = MSACCT|MSFORK
  /1:    flags = ASLEEP  read(0x3,0xffbf6bc8,0x8000)
  

• Procurando por todos os outros processos que usam esse arquivo

  bash-3.2$ fuser -f /source/path/Oracle/Middleware/user_projects/epmsystem2/EssbaseServer/essbaseserver1/bin/ESSBASE1_1
  /source/path/Oracle/Middleware/user_projects/epmsystem2/EssbaseServer/essbaseserver1/bin/ESSBASE1_1:     8745o   25057o
  

  Observe que o 'o' indica que o processo está usando o arquivo como um arquivo aberto.

• Encontrando nos processos:

  bash-3.2$ pstree | grep 8745
   | | |       |--- 09695 kent grep 8745
   | |         \--- 08745 kent cp ESSBASE1_1 ESSBASE1_1kent
  bash-3.2$ pstree | grep 25057
   | | |       \--- 09700 kent grep 25057
   | |   |-+- 25057 kent 86:43 /some/path/Oracle/Middlewa
  

  O processo com o PID 25057 é um processo do servidor.

• O arquivo aberto está em um ponto de montagem. É um disco NAS.

  bash-3.2$ cat /etc/mnttab | grep apps
  server1.com:/vol/server1_nec_nosnap0/dev_apps   /source/path/       nfs     rw,xattr,dev=5e40001    1362894854
  

• Alguém pode me ajudar a entender o que está causando o congelamento do comando de cópia?
• Eu posso adivinhar que o aplicativo está em execução e que pode estar, de alguma forma, impedindo que qualquer outro processo acesse um arquivo específico.
• Mas, em tal cenário, eu esperaria que cp abortasse e me desse um erro, em vez de ficar bloqueado indefinidamente.
• De acordo com a atualização, parece que o processo PID=25057 parece estar usando o arquivo como um arquivo aberto. Mas por que isso bloqueia o comando cp ?

Answer 1

Se você olhar sua pfiles output para o descritor de arquivo 10, você notará que o arquivo é um FIFO; isso também é evidenciado pelo tipo p na sua listagem ls . A natureza de um FIFO é que as leituras serão bloqueadas a menos que outro processo esteja gravando dados, e é por isso que o cp ficou preso ao tentar ler seu conteúdo.

Para contornar o problema, você pode usar rsync para copiar a árvore de diretórios.

rsync -a /source/path/Oracle /target/path

rsync é inteligente o suficiente para fazer um FIFO duplicado em vez de ler o original. Observe que você não especifica Oracle para o destino, pois rsync criará o diretório lá.