O script inicial não inicia

Ubuntu 10.04

Eu criei este script inicial ( /etc/init/pure-ftpd.conf ):

# pure-ftpd - FTP server

description "Pure-FTPd server"

start on filesystem
stop on runlevel S

respawn
respawn limit 10 5
pid file /var/run/pure-ftpd.pid
console output

pre-start script
    test -x /usr/local/sbin/pure-ftpd || { stop; exit 0; }
end script

exec /usr/local/sbin/pure-ftpd --maxclientsnumber 2 --maxclientsperip 10 --prohibitdotfileswrite --prohibitdotfilesread --noanonymous --chrooteveryone --dontresolve --nochmod --pidfile /var/run/pure-ftpd.pid

Mas...

# start pure-ftpd
start: Unknown job: pure-ftpd

e

# service pure-ftpd start
start: Unknown job: pure-ftpd

Qual é o problema?
É necessário fazer algo mais?
É necessário criar um script no /etc/init.d também?

Geralmente significa que você tem um erro no .confarquivo - por exemplo, não tenho certeza de que a pidestrofe seja suportada na versão 10.04, stopnão possa ser usada no script etc.

Eu tentaria iniciar o arquivo do zero (apenas start, stopetc) e, em seguida, construí-lo lentamente, adicionando mais e mais linhas e testando-o via start pure-ftpd.

Por exemplo:

# cat pure-ftpd.conf 
start on filesystem
stop on runlevel S

respawn
respawn limit 10 5

# start pure-ftpd
pure-ftpd start/running

# cat pure-ftpd.conf 
start on filesystem
stop on runlevel S

respawn
respawn limit 10 5
pid file /var/run/pure-ftpd.pid

# start pure-ftpd
start: Unknown job: pure-ftpd

Você também pode executar init-checkconfpara verificar a sintaxe

init-checkconf /etc/init/job.conf
File /etc/init/job.conf: syntax ok

Primeiro, você pode verificar se seu trabalho é realmente conhecido como inicial:

sudo initctl list | grep your_job_name

... onde your_job_nameestá o nome do seu script inicial, menos a .confextensão.

Se não for encontrado, tente recarregar a configuração e verifique novamente:

sudo initctl reload-configuration

# re-check
sudo initctl list | grep your_job_name

Em seguida, tente novamente para iniciar seu trabalho:

sudo start your_job_name

Se você não estava conseguindo fazer login /var/log/daemon.logou /var/log/syslogantes, talvez já tenha um.

A referência mais relevante para a sintaxe do arquivo de trabalho estará disponível quando você executar o comando:

man 5 init

no seu sistema. Para o Ubuntu 10.04, como você encontrou na resposta anterior, a sintaxe do arquivo pid está incorreta.

Sempre que você receber o erro 'tarefa desconhecida' de volta, é uma boa ideia verificar os logs (antes de 11.04, /var/log/daemon.log, 11.04 e superior, tudo acontece em / var / log / syslog)

Você pode ver um erro como este:

init: /etc/init/test.conf:2: Unknown stanza

Enfim, estou aqui porque tive o mesmo problema, mas minha sintaxe estava 100% correta.

Após alguma depuração, descobri outro problema que pode causar o erro " Trabalho desconhecido" :

O upstarts usa o inotify para monitorar as alterações do arquivo .conf e os trabalhos de instalação automática, isso é muito legal (por isso você não precisa de algo como update.rc com o upstart!), mas pode não ser perfeito se você (como eu nesse caso) usar Em algum programa da GUI de FTP / SCP para carregar e editar configurações em servidores remotos, o trabalho pode ser desinstalado silenciosamente pelo iniciante quando você editar o arquivo dessa maneira.

para corrigir basta fazer isso (que me salvou)

touch /etc/init/*

ele gerará eventos inotify para atualizar todos os confs iniciais.

Eu tive o mesmo problema nos meus contêineres do Ubuntu 14.04 Docker. Como se vê, a imagem do Ubuntu 14.04 (se não houver outras) para o Docker não suporta o Upstart da mesma maneira que uma máquina virtual completa.

Para responder a essa pergunta, por que o serviço não inicia, é porque o initctl não é um programa Upstart real: ele é mapeado para / bin / true.

Para verificar, execute o seguinte em um contêiner do Ubuntu 14.04 Docker vs. Vagrant e vs. um droplet DigitalOcean

$ ls -al /sbin/initctl

Você verá que initctl não é o mesmo no Docker vs. os outros.

Um link que pode aprofundar sua compreensão. Https://github.com/docker/docker/issues/1024