pipes encadeados em arremessos de bash 'Operação não permitida'

Question

O sintoma é muito simples. Por exemplo:

ls | grep a | grep b | grep c | grep d

lança

-bash: child setpgid (8948 to 8943): Operation not permitted
-bash: child setpgid (8950 to 8943): Operation not permitted
-bash: child setpgid (8952 to 8943): Operation not permitted
-bash: child setpgid (8953 to 8943): Operation not permitted
-bash: child setpgid (8954 to 8943): Operation not permitted
-bash: child setpgid (8955 to 8943): Operation not permitted
-bash: child setpgid (8962 to 8957): Operation not permitted
-bash: child setpgid (8964 to 8957): Operation not permitted
-bash: child setpgid (8966 to 8957): Operation not permitted
-bash: child setpgid (8967 to 8957): Operation not permitted
-bash: child setpgid (8968 to 8957): Operation not permitted
-bash: child setpgid (8969 to 8957): Operation not permitted
-bash: child setpgid (8976 to 8971): Operation not permitted
-bash: child setpgid (8978 to 8971): Operation not permitted
-bash: child setpgid (8980 to 8971): Operation not permitted
-bash: child setpgid (8981 to 8971): Operation not permitted
-bash: child setpgid (8982 to 8971): Operation not permitted
-bash: child setpgid (8983 to 8971): Operation not permitted
-bash: child setpgid (8990 to 8985): Operation not permitted
-bash: child setpgid (8992 to 8985): Operation not permitted
-bash: child setpgid (8994 to 8985): Operation not permitted
-bash: child setpgid (8995 to 8985): Operation not permitted
-bash: child setpgid (8996 to 8985): Operation not permitted
-bash: child setpgid (8997 to 8985): Operation not permitted

O número de grep s e os pipes usados não importam. Às vezes, ls | grep a também gera o erro.

AFAIK, ls anad grep não requer privilégios de root. Assim, estou querendo saber como resolver esse problema.

A máquina atual é o Cent OS 5 (kernel 2.6.18). Se você precisar de informações mais detalhadas, por favor me avise.

Adicionado: rastreio de ls e grep

type ls
ls is aliased to 'ls -hF --color=auto'
which ls
/bin/ls
type grep
grep is /bin/grep
which grep
/bin/grep

Adicionado 2

Neste momento, descobri que isso não está limitado a ls e grep. Parece que se aplica a todos os comandos usando pipes. por exemplo, echo 'Hello' | tee outfile gera o mesmo erro.

Adicionado 3: em resposta a @Argonauts '

Como os registros são muito longos, consulte o link .

Em suma,

• %código%
  • tamanho do tubo (512 bytes, -p) 8
  • max user processes (-u) 129094
• ulimit -a diz type log : OK
• -bash: type: log: not found : trap -p . Isso causaria problemas?
• Teste com ambiente limpo: às vezes sem erro, mas às vezes com erro.
• Precisa ser investigado
  • Saída de depuração do Bash
  • Strace

Answer 1

Aqui estão algumas coisas para tentar, que devem ajudar, na melhor das hipóteses, a resolver o seu problema, na pior das hipóteses, para descobrir o que "não é". Em alguns casos, você pode combinar as etapas (por exemplo, strace e 'try with cleared environment').

Ulimit

Verifique se você tem algum limite excepcionalmente baixo definido para o número de processos permitidos em seu tamanho máximo de shell ou pipeline com o seguinte comando: ulimit -a

Se puder, acrescente a saída desse comando à sua pergunta.

Registrando

Em versões mais antigas de pipelines bash poderia quebrar devido a funções de log sendo ativadas (bash < 4.1).

type log
Isso deve retornar algo como 'log: not found'. Se, em vez disso, retornar uma definição de função, limpe-a com o comando unset log .

Armadilha de depuração

trap -p

Veja se alguma saída é vinculada a DEBUG ou logging. Se eles são e / ou uma função de log é definida, você precisa descobrir onde eles estão definidos e (pelo menos temporariamente) removê-los.

Eles podem ser definidos em .bashrc, .bash_profile e qualquer outro arquivo de inicialização relacionado. Como parece afetar também o root, é mais provável que ele seja encontrado em um arquivo no nível do sistema, como / etc / bashrc ou / etc / profile .

No mínimo, você pode limpar a função de captura e registro do seu ambiente atual e ver se isso resolve o problema.

Tente com o ambiente limpo

Outro método para verificar isso é executando os comandos canalizados usando (fixo)

env -i ls | env -i grep a | env -i grep b | env -i grep c | env -i grep d

para limpar o ambiente (para essa sequência de comandos). Você pode precisar alterar seus comandos para incluir caminhos completos. Vale a pena ver se os valores de ulimit -a são diferentes neste ambiente também.

Saída de depuração do Bash

Antes de executar sua sequência de cmd canalizada, digite set -x na linha de comando, que ativará a depuração bash - todos os comandos "nos bastidores" serão impressos na tela. É possível que você veja algo estranho - um gancho para outra função sendo chamada semelhante ao problema de log discutido acima - ou outra coisa estranha.

Strace

Execute o comando com strace:% strace ls | grep a | grep b | grep c | grep d

e veja exatamente o que está acontecendo. Se você quiser postar estes resultados, você provavelmente precisará colocá-los em pastebin ou site similar e postar um link. Essa é a abordagem mais provável para resolver o problema, mas a saída pode ser difícil de decodificar.

Atualizar

Depois de analisar seus registros:

1. Ao usar o env -i, cada estágio do pipe precisa usá-lo - cada estágio é efetivamente uma instância de shell separada. Meu erro. env -i ls | env -i grep a | env -i grep b | env -i grep c | env -i grep d

2. A função de registro que é chamada entre cada chamada combinada com a interceptação DEBUG é quase definitivamente o bug ao qual eu estava me referindo. Infelizmente, o bug não está disponível para visualização, mesmo com minha assinatura RHEL. É link

Esse bug resultou em uma condição de corrida quando o registro ocorreu em conjunto com as traps de depuração, que é exatamente o que você está fazendo - o set -x mostra claramente o log bastante extenso (para syslog) de todos os comandos emitidos.

Como um pipe cria sub-shells, você não pode simplesmente limpá-lo no shell de nível superior e emitir comandos canalizados. O próximo estágio canalizado será definido. O novo teste com a mudança no item 1 acima mostrará que ele funciona sem esses ganchos.

O relatório de erros indica que não há porta de retorno da correção. Eu coloquei alguns detalhes de rhel aqui: link

Você precisa limpar a armadilha e ou remover a definição da função de registro histórico_to_syslog Se você tem acesso root, você pode definitivamente remover isso permanentemente. Eu dei algumas dicas na minha resposta original sobre onde procurar.

Você pode tentar verificar se há uma atualização para bash for centos 5, mas as informações que eu coloquei acima não declararam nenhuma porta de retorno para rhel 5 foi criada, então é improvável que uma seja para centos 5.

Atualização breve:

Para esclarecer um pouco o empate entre o bug e o modo de falha - o que acontece é que as chamadas para interagir com IDs de processo associadas à função de registro e gancho DEBUG ocorrem fora de sequência - a condição de corrida - resultando em chamadas como getppid os processos de referência que acabaram de ser fechados, resultando no erro que você vê.

Em uma nota lateral - essa é uma capacidade de registro agressiva. O sysadmin claramente não acredita no círculo de confiança.