Script upstart vs. linha de comando: por que essa diferença de comportamento?

Question

Estou tentando configurar o Tomcat para começar com o upstart. Eu acho os seguintes trabalhos:

  description "Tomcat Server"

  start on runlevel [2345]
  stop on runlevel [!2345]
  respawn
  respawn limit 10 5

  setuid tomcat

  env JAVA_HOME=/usr/lib/jvm/default-java
  env CATALINA_HOME=/opt/apache-tomcat-7.0.34

  script
    chdir $CATALINA_HOME
    exec $CATALINA_HOME/bin/catalina.sh run
  end script

Mas se eu remover o chdir , o tomcat será iniciado, mas com muitas FileNotFound exceções quando meu .wars carregar. (Isto é: o .wars se carrega, mas eles lançam exceções na carga.)

Observe que esse comportamento é diferente do que eu vejo quando invoco catalina.sh da linha de comando. Invocando a partir da linha de comando, posso executar /opt/apache-tomcat-7.0.34/bin/catalina.sh run de qualquer diretório (sem chdiring) e está tudo bem.

Então, por que o chdir é necessário no meu script upstart? (Como o ambiente iniciante é diferente do meu ambiente de linha de comando?)

Exemplo dos erros que estou vendo com o upstart quando não participo:

Feb 22, 2013 3:00:11 AM org.apache.catalina.startup.HostConfig deployWAR
INFO: Deploying web application archive my-war.war
log4j:ERROR setFile(null,true) call failed.
java.io.FileNotFoundException: my-war.log (Permission denied)
    at java.io.FileOutputStream.open(Native Method)

    

Answer 1

Este é um problema de permissão de gravação. O usuário tomcat não tem permissão para criar um arquivo de log em um local onde ele tente criá-lo. O local em que ele tenta criar arquivos de log difere dependendo de como você inicia o tomcat.

Esta peça do seu log me chamou a atenção:

java.io.FileNotFoundException: my-war.log (Permission denied) at java.io.FileOutputStream.open(Native Method)

Ele diz que o usuário (tomcat) não tem permissão para criar o arquivo my-war.log. Aqui estão os diferentes cenários:

Upstart com chdir

Inicialize os primeiros pares para $ CATALINA_HOME. Usuário tomcat tem permissão para criar arquivos lá. Então tudo funciona.

Upstart sem chdir

O Upstart é executado como root, portanto, o diretório padrão é /. Usuário tomcat não tem permissão para criar arquivos lá. Então você tem permissão negada erros.

Execução do tomcat a partir do seu diretório home

Agora você executa o tomcat como você mesmo no diretório de sua casa. Você tem permissão de gravação para o seu próprio diretório. Então tudo funciona de novo.

    

Answer 2

Eu não tenho acesso a uma versão inicial com setuid support, mas é isso que eu faria no seu caso.

Parece um problema de discrepância no ambiente. O mais provável é que uma variável de ambiente não seja definida ao executar a partir do upstart. Pode ser que setuid não defina $USER ou $HOME ?

Portanto, recomendo que você compare os ambientes. Uma maneira fácil e simples seria modificar seu script de inicialização assim e reiniciar o trabalho.

  script
    env > /tmp/env-upstart.log
    chdir $CATALINA_HOME
    exec $CATALINA_HOME/bin/catalina.sh run
  end script

Em seguida, execute env > /tmp/env-console.log quando você normalmente o iniciaria no console (se você estiver usando sudo , faça isso com sudo env ).

Em seguida, compare os dois arquivos /tmp/env-upstart.log e /tmp/env-console.log (classifique-os e abra-os com vimdiff ) e será fácil descobrir qual variável em env-upstart está ausente do outro arquivo (ou está definida como algo que você não esperaria).

Atualização 1

E se você ainda estiver recebendo erros, eu verificaria o seguinte:

• Permissões de usuário : os IDs de usuário efetivos / reais podem ser diferentes. Compare a saída de id , id -r -u , id -r -g , id -r -G , id -u , id -g e id -G em ambos os casos.
• Limites de processo : pode ser que seus scripts iniciantes tenham limites mais rígidos. Tente colocar um ulimit -a para comparar.
• Ociosidade do shell : não é provável, mas o upstart usa sh , enquanto o shell do seu usuário provavelmente é bash ou zsh . Tente executar o comando bem-sucedido de sh .

• Depure o script : Se você ainda estiver realmente preso, execute catalina.sh no modo de depuração. Isso é tão fácil quanto executá-lo de upstart assim:

  exec /bin/sh -x $CATALINA_HOME/bin/catalina.sh run 2>/tmp/catalina-upstart.log
  

  Então você pode comparar os dois logs de depuração e talvez identificar onde os dois scripts fizeram algo diferente.

Answer 3

Sim, é sobre permissão. Mas não relacionado ao Upstart. Isso ocorre porque em 'catalina.sh start', ou seja, na parte 'start', o comando real é:

  ...
  -Djava.io.tmpdir="\"$CATALINA_TMPDIR\"" \
  org.apache.catalina.startup.Bootstrap "$@" start \
  >> "$CATALINA_OUT" 2>&1 "&"

Aqui, o log de saída é totalmente atribuído. Enquanto não houver "$ CATALINA_OUT" na parte RUN. Isso levará o problema de permissão de escrita mencionado acima. Nomeadamente, se nenhum caminho de arquivo de saída específico for designado, a saída irá para o arquivo de logs ou para fazer isso como seu.war codificado. Esse tipo de atribuição de registro pouco clara levará a problemas de permissão incertos.

    

Answer 4

Para obter um despejo completo de todos os elementos ambientais entre a execução do seu servidor na linha de comando, comparado à execução sob o Upstart, tente instalar minha ferramenta procenv, executá-lo nos dois ambientes e diferenciar os arquivos de saída:

• link
• link

Isso está disponível nos arquivos sid do ubuntu raring e debian (e FreeBSD).