Por que um script de desligamento NÃO é executado?

2

Eu instalei um script de desligamento em um sistema Ubuntu que não é executado. É uma instância do Amazon EC2. Eu não tenho certeza se isso tem a ver com esse fato, só queria mostrar isso.

O script deve enviar alguns arquivos de log para um bucket do Amazon S3 para que ele seja executado enquanto a rede estiver ativa.

Aqui está como eu instalei o script:

1) Criamos o arquivo em /etc/init.d/push-apache-logs-to-s3.sh com os comandos necessários.

2) Tornou executável com sudo chmod +x push-apache-logs-to-s3.sh

3) Executou sudo update-rc.d push-apache-logs-to-s3.sh start 0 0 .

A saída do acima foi:

update-rc.d: warning: /etc/init.d/push-apache-logs-to-s3.sh missing LSB information
update-rc.d: see <http://wiki.debian.org/LSBInitScripts>
 Adding system startup for /etc/init.d/push-apache-logs-to-s3.sh ...
   /etc/rc0.d/S00push-apache-logs-to-s3.sh -> ../init.d/push-apache-logs-to-s3.sh

O conteúdo de /etc/rc0.d/ é agora:

lrwxrwxrwx  1 root root   17 Jul 31  2012 K09apache2 -> ../init.d/apache2
lrwxrwxrwx  1 root root   29 Jun 16  2012 K10unattended-upgrades -> ../init.d/unattended-upgrades
lrwxrwxrwx  1 root root   26 Jun 16  2012 K15landscape-client -> ../init.d/landscape-client
lrwxrwxrwx  1 root root   19 Apr 10 11:11 K20memcached -> ../init.d/memcached
-rw-r--r--  1 root root  353 Jul 26  2012 README
lrwxrwxrwx  1 root root   35 Jul 10 12:01 S00push-apache-logs-to-s3.sh -> ../init.d/push-apache-logs-to-s3.sh
lrwxrwxrwx  1 root root   18 Jun 16  2012 S20sendsigs -> ../init.d/sendsigs
lrwxrwxrwx  1 root root   17 Jun 16  2012 S30urandom -> ../init.d/urandom
lrwxrwxrwx  1 root root   22 Jun 16  2012 S31umountnfs.sh -> ../init.d/umountnfs.sh
lrwxrwxrwx  1 root root   20 Jun 16  2012 S35networking -> ../init.d/networking
lrwxrwxrwx  1 root root   18 Jun 16  2012 S40umountfs -> ../init.d/umountfs
lrwxrwxrwx  1 root root   20 Jun 16  2012 S60umountroot -> ../init.d/umountroot
lrwxrwxrwx  1 root root   14 Jun 16  2012 S90halt -> ../init.d/halt

Quando eu executo manualmente o script com sudo ./push-apache-logs-to-s3.sh , ele faz o trabalho pretendido.

Esses scripts são executados por root ? O que estou perdendo?

    
por marekful 10.07.2013 / 14:35

3 respostas

1

Você deseja que o script seja executado no desligamento. Substitua start por stop da seguinte forma:

sudo update-rc.d push-apache-logs-to-s3.sh stop 0 0 .

Observe que ele terá um K prefixado, em vez de um S

    
por 10.07.2013 / 15:18
1

Qual é o comportamento esperado quando você define o script para ser executado em S00 ? Eu não tenho scripts com S00 no meu sistema, pode ser que um mínimo de 1 seja necessário? Você também não definiu explicitamente iniciar / parar, talvez isso esteja causando problemas. Apenas no caso, tente

sudo update-rc.d push-apache-logs-to-s3.sh start 01 2 3 4 5 . stop 01 0 1 6 .  

Se isso ainda não funcionar, atualize sua pergunta para quem seu script (ou pelo menos seus cabeçalhos), pode haver algo errado.

EDITAR

Depois de ver o script que você postou na sua outra pergunta , vejo dois possíveis problemas. Primeiro, você tem um espaço na sua linha de texto !# /bin/sh em vez de #!/bin/sh .

Mais importante, por que você está usando sh em vez de bash ? sh não suporta source , e muito menos . como um alias para a origem. Altere seu script para ser executado com bash , isso deve corrigi-lo. Na verdade, não entendo por que funciona quando você o executa manualmente, o . deve gerar um erro:

$ sh
$ source foo
sh: 1: source: not found
$ bash
$ source foo
bash: foo: No such file or directory

Raspe isso, eu estava errado, como @gnp apontou, dash realmente suporta . .

    
por 10.07.2013 / 15:08
0

A raiz do problema é que s3cmd não consegue ler seu arquivo de configuração. Por alguma razão desconhecida para mim, durante a mudança de nível de execução (0), quando init executa scripts init, aparentemente o usuário root que executa esses scripts não conta como um usuário "real", por isso não tem um diretório "home" de onde s3cmd tenta ler a configuração.

Especificando explicitamente a localização do arquivo de configuração usando o --config=... resolve esse problema.

Obrigado pela ajuda e contribuição de todos!

    
por 10.07.2013 / 17:48