Executando certos scripts / comandos trava como usuário, OK como root [closed]

Question

Eu tenho um usuário jenkins que está pendurado ao executar certos scripts ou comandos (este é um servidor de compilação android). Ao executar os mesmos scripts / comandos como root , eles estão executando OK.

Exemplo:

Como usuário jenkins :
> java
- trava -

Como usuário root :
> java
- Saída de ajuda de uso -

Isso acontece porque muitos comandos são executados como jenkins , como android e java , mas comandos como ps e cat funcionam bem.

Este é um desenvolvimento recente, por isso é provavelmente algum tipo de problema de permissões, mas não consigo defini-lo.

Atualização: Adicionar set -x ao início do script revela que ele trava ao chamar java , nesta linha: + exec /etc/alternatives/java_sdk_1.8.0/bin/java -Dorg.gradle.appname=gradlew -classpath /var/lib/jenkins/workspace/android-project/gradle/wrapper/gradle-wrapper.jar org.gradle.wrapper.GradleWrapperMain assembleDebug

A diferença entre executar strace -fo java em ambos os usuários root e root mostra uma divergência nas seguintes linhas:

5319  stat("/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-2.b16.e | 5302  stat("/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-2.b16.e
5319  open("/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-2.b16.e | 5302  open("/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-2.b16.e
5319  stat("/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-2.b16.e | 5302  stat("/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-2.b16.e
5319  open("/opt/glibc-2.14/lib/tls/x86_64/libpthread.so.0",  | 5302  open("/etc/ld.so.cache", O_RDONLY) = 3
5319  stat("/opt/glibc-2.14/lib/tls/x86_64", 0x7ffe601248c0)  | 5302  fstat(3, {st_mode=S_IFREG|0644, st_size=49448, ...}) =
5319  open("/opt/glibc-2.14/lib/tls/libpthread.so.0", O_RDONL | 5302  mmap(NULL, 49448, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fa
5319  stat("/opt/glibc-2.14/lib/tls", 0x7ffe601248c0) = -1 EN | 5302  close(3)                          = 0
5319  open("/opt/glibc-2.14/lib/x86_64/libpthread.so.0", O_RD | 5302  open("/lib64/libpthread.so.0", O_RDONLY) = 3
5319  stat("/opt/glibc-2.14/lib/x86_64", 0x7ffe601248c0) = -1 | 5302  read(3, "7ELF
5319  stat("/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-2.b16.e | 5302  stat("/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-2.b16.e
5319  open("/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-2.b16.e | 5302  open("/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-2.b16.e
5319  stat("/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-2.b16.e | 5302  stat("/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.141-2.b16.e
5319  open("/opt/glibc-2.14/lib/tls/x86_64/libpthread.so.0",  | 5302  open("/etc/ld.so.cache", O_RDONLY) = 3
5319  stat("/opt/glibc-2.14/lib/tls/x86_64", 0x7ffe601248c0)  | 5302  fstat(3, {st_mode=S_IFREG|0644, st_size=49448, ...}) =
5319  open("/opt/glibc-2.14/lib/tls/libpthread.so.0", O_RDONL | 5302  mmap(NULL, 49448, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fa
5319  stat("/opt/glibc-2.14/lib/tls", 0x7ffe601248c0) = -1 EN | 5302  close(3)                          = 0
5319  open("/opt/glibc-2.14/lib/x86_64/libpthread.so.0", O_RD | 5302  open("/lib64/libpthread.so.0", O_RDONLY) = 3
5319  stat("/opt/glibc-2.14/lib/x86_64", 0x7ffe601248c0) = -1 | 5302  read(3, "7ELF%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%>%pre%%pre%%pre%%pre%
5319  open("/opt/glibc-2.14/lib/libpthread.so.0", O_RDONLY) = | 5302  fstat(3, {st_mode=S_IFREG|0755, st_size=146592, ...}) =
%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%%pre%>%pre%%pre%%pre%%pre%
5319  open("/opt/glibc-2.14/lib/libpthread.so.0", O_RDONLY) = | 5302  fstat(3, {st_mode=S_IFREG|0755, st_size=146592, ...}) =

em que o lado esquerdo é o usuário jenkins . Parece estar falhando em uma área relativa a glibc-2.14, que é apontada via variável de ambiente LD_LIBRARY_PATH .

    

Answer 1

TL; DR: Alguns usuários tinham uma variável de ambiente definida para usar glibc-2.14 , o que faz com que a execução da VM Java falhe.

Olhando através do strace diff, existe essa linha em particular:

5319  open("/opt/glibc-2.14/lib/libpthread.so.0", O_RDONLY)

Isso indicou que alguns usuários estavam usando os glibc-2.14 binários, enquanto outros usavam o sistema glibc libs (que estão em 2.12).

A diferença é que alguns usuários tinham a variável de ambiente LD_LIBRARY_PATH definida para o diretório glibc-2.14 e outros não, com o padrão 2.12 do sistema. A limpeza de LD_LIBRARY_PATH permitiu que o comando java fosse executado com êxito para esses usuários.