Estou tentando entender a diferença entre service restart [someservice] e service reload [someservice] . Eu entendo que "restart" reinicia o serviço enquanto "reload" recarrega a configuração, mas eu não entendo as implicações práticas disso bem o suficiente para determinar qual eu devo usar em um dado contexto.
Um exemplo: a maioria dos guias que eu li para configurar o PostgreSQL dizem que, depois de editar o postgresql.conf e o pg_hba.conf para permitir conexões remotas, eu devo emitir sudo service postgresql restart . No entanto, se eu estivesse adivinhando qual usar com base na descrição acima, eu escolheria "recarregar".
Caso isso seja importante, eu estou no Ubuntu 11.10 - embora eu esteja esperando uma explicação tão geral quanto possível.
O que você disse está correto, reload diz ao serviço para recarregar seus arquivos de configuração. Isso significa que deve ser suficiente para recarregar a configuração; no entanto, pode haver determinados serviços que "não seguem a regra" ou que não recarregarão os arquivos de configuração. Devido a isso você provavelmente está mais seguro com restart . Eu pessoalmente não uso postgresql , então não sei.
Nem todos os serviços suportam reload . Para aqueles que o fazem, geralmente é preferível reiniciar (ou seja, o recarregamento causa menos ou nenhum tempo de inatividade).
O Manual de Normas Debian especifica que todos os /etc/init.d/ script deve suportar uma ação force-reload , o que significa reload se o serviço oferecer suporte e restart se o serviço não oferecer suporte ao recarregamento.
Não tenho certeza de como isso se traduz no moderno mundo do Ubuntu.
Para expandir, responda com minha experiência com o systemd.
No systemd sempre que um processo é iniciado, ele é executado dentro do contexto systemd, o exemplo mais claro disso é com as variáveis de ambiente definidas em seu arquivo unitário.
Então, quando você envia um sinal systemctl reload [someservice] , ele envia um sinal para o serviço para recarregar-se normalmente, caso seja suportado. Caso contrário, o processo simplesmente ignorará o sinal. Isto é configurável embora.
Com o que quero dizer graciosamente? para iniciar novos trabalhadores com a nova configuração ou código e parar os antigos trabalhadores quando eles terminarem de atender aos pedidos atuais, se houver.
E se você fizer systemctl restart [someservice] ele dirá ao systemctl para dizer ao serviço para parar, destruir o contexto atual do systemd, criar um novo e executar o serviço novamente. Isso faz sentido, por exemplo, recarregar variáveis de ambiente em um contexto systemd ou se um recarregamento não for suportado.
Espero que isso esclareça um pouco e se eu estiver errado em algo, por favor me avise.
atualmente, se um serviço precisar ser chutado (por exemplo, um arquivo de configuração alterado), você poderá notificar o serviço, mas isso levará a uma reinicialização. Seria bom se uma recarga fosse feita se o serviço já estivesse em execução (embora eu suponha que haja alguns serviços que requerem reinicializações para alguns arquivos, recarregamentos para outros).
O exemplo mais complexo que posso imaginar é algo como o Apache. Normalmente você pode apenas pedir para recarregar, no entanto, às vezes você precisa solicitar uma reinicialização (se você adicionar / remover módulos, por exemplo).
postgres é um bom exemplo para grandes diferenças entre recarregar e reiniciar, porque o último tem que desconectar todos os clientes de banco de dados.
quando as conexões não devem reverter, você pode parar o serviço sem um "--force" primeiro usando pg_ctlcluster .
em / etc / postgres / {versão} / {dbname} /postgresql.conf e em link cada parâmetro tem uma observação como "Este parâmetro só pode ser definido no início do servidor".
Tags server services postgresql