upscart memcached

Question

Eu montei um script upstart para o memcached baseado no script init.d que vem com ele, pois não encontrei nenhum exemplo em lugar nenhum. O problema é que ele não reaparece automaticamente quando eu mato o processo.

env DAEMON=/usr/bin/memcached
env DAEMONBOOTSTRAP=/usr/share/memcached/scripts/start-memcached

start on started
stop on runlevel [!2345]

respawn

post-stop script
  start-stop-daemon --stop --pidfile /var/run/memcached.pid --name memcached --chuid nobody --user nobody --exec $DAEMON --signal TERM
end script

exec start-stop-daemon --start --quiet --exec $DAEMONBOOTSTRAP

    

Answer 1

Este é um bom começo, mas há algumas coisas que você pode ter entendido mal sobre upstart aqui:

start on started

O evento iniciado é emitido toda vez que qualquer trabalho no sistema é iniciado. Você provavelmente pretendia ter algo mais depois de iniciado, como start on started networking . Isso seria incorreto também, infelizmente, já que o trabalho em rede não é tão significativo quanto o seu nome implicaria. Para o memcached, ele pode ser executado praticamente a qualquer momento depois que o nível de execução 2 for atingido. Então

start on runlevel [2345]

Funciona e é necessário devido à sua parada na regra:

stop on runlevel [!2345]

Eu sei que é um pouco confuso, mas você realmente tem que usar '^' ao invés de '!' aqui, então você quer

stop on runlevel [^2345]

Também vale notar que isso irá parar no nível de execução 1, que é o "modo de manutenção de usuário único". Mas seu início original não iniciaria o backup no nível de execução 2. Isso seria um erro, portanto, certifique-se de que os níveis de execução sejam respeitados corretamente.

Seu pós-stop e exec ignoram o fato de que o upstart tentará rastrear esse pid, mas como o script start-memcached sai (porque ele permite que o memcached se autodesenha) o pid será perdido. Isso significa que o arrivista não pode reaparecer, porque não está ciente do pid em primeiro lugar e não sabe que ele morreu.

Se você quiser que ele seja recuperado, provavelmente você deseja:

expect daemon
exec $DAEMONBOOTSTRAP

Não há necessidade de usar start-stop-daemon nesta instância. O Upstart irá acompanhar o pid e quando você 'parar o memcached' ele irá enviar um SIGTERM. Além disso, o arquivo de configuração do memcached já roda o memcached como um usuário diferente de root (memcache na verdade) no Ubuntu 10.10 e posterior, então você provavelmente não precisa se preocupar em mudar o userid também.

    

Answer 2

Aqui está o script Upstart que estou usando para memcached . Isso é strongmente influenciado pela resposta do SpamapS, mas com um ajuste de chave para descartar o uso de start-memcached .

Usar start-memcached resulta em três forks de processo para criar o processo final daemon memcached . O Upstart parece suportar apenas zero a três garfos :

• Zero garfos sem cláusula expect ,
• Um garfo com a cláusula expect fork ou
• Dois garfos com a cláusula expect daemon .

No meu teste usando expect daemon com o start-memcached wrapper ocasionalmente resultou em Upstart rastreando o ID do processo errado, no qual o Upstart entra em um estado quebrado onde o Upstart trava ao tentar iniciar ou parar o processo. Situação chata que é difícil de corrigir sem uma reinicialização. A discussão que leva ao comentário número 47, aqui, tem alguns bons conselhos sobre o que fazer se isso ocorrer.

Como resultado, deixei de usar o start-memcached wrapper e simplesmente inline memcached configuration no script Upstart abaixo. Como o processo é executado diretamente pelo Upstart, não há necessidade de uma cláusula expect . Algumas outras notas estão incluídas na linha.

description "memcached"

env MEMCACHED=/usr/bin/memcached

start on runlevel [2345]
# Not sure why it was recommended to use ^ rather than !.  I'm sticking with !.
stop on runlevel [!2345]

# This test is completely optional, I'm just paranoid.
pre-start script
  test -x $MEMCACHED || { stop; exit 0; }
end script

respawn
exec $MEMCACHED -m 384 -p 11211 -u memcache -l 127.0.0.1