O @reboot do crontab só funciona como root?

64

man 5 crontab é bastante claro sobre como usar o crontab para executar um script na inicialização:

   These special time specification "nicknames" are supported, which replace the 5 initial time and date
   fields, and are prefixed by the `@` character:
   @reboot    :    Run once after reboot.

Então, felizmente, adicionei uma única linha ao meu crontab (na minha conta de usuário, não no root):

@reboot     /home/me/myscript.sh

Mas, por alguma razão, o myscript.sh não seria executado na reinicialização da máquina. (ele funciona bem se eu o chamar na linha de comando, portanto, não é um problema de permissão)

o que estou perdendo?


Atualize para responder às perguntas do @ Anthon:

  1. Versão do Oracle-linux: 5.8 (uname: 2.6.32-300.39.2.el5uek # 1 SMP)
  2. Versão do Cron: vixie-cron-4.1-81.el5.x86_64
  3. Sim, /home é uma partição montada. Parece que este é o problema. Como faço para solucionar isso?
  4. Atualmente, myscript.shapenas faz eco de uma mensagem de texto em um arquivo /home/me.
Retido
fonte
2
seu usuário crontab não suporta a opção @reboot, existem alguns layouts de crontab quando você começa a bisbilhotar.
X Tian
@XTian Obrigado. Qual é a maneira recomendada de executar um script na reinicialização como um usuário que não seja root?
Retido
2
O que está faltando não está claro, mas o que está faltando são os detalhes. Qual versão do oracle-linux você está executando? Qual versão do cron você possui? É /homeuma partição montada? Qual é o conteúdo do seu /home/me/myscript.sh?
Anthon
11
Se você estiver usando o Lin da Oracle. ver. 5 existe esse registro de alterações sobre problemas com o vixie-cron + @reboot. oss.oracle.com/pipermail/el-errata/2012-March/002655.html
slm
11
@Daniel - é myscript.shexecutável? chmod +x myscript.sh.
slm

Respostas:

47

Isso pode ser um tópico um pouco confuso, porque existem diferentes implementações do cron. Também houve vários bugs que quebraram esse recurso e também existem alguns casos de uso em que ele simplesmente não funciona, especificamente se você fizer um desligamento / inicialização versus uma reinicialização.

Insetos

ponto de dados # 1

Um desses erros no Debian é abordado aqui, intitulado: cron: @reboot jobs não são executados . Isso parece ter entrado no Ubuntu também, o que não posso confirmar diretamente.

ponto de dados # 2

A evidência do bug no Ubuntu parece estar confirmada aqui nesta sessão de perguntas e respostas, intitulada: @reboot cronjob não em execução .

excerto

comment # 1: .... 3) sua versão do crond pode não suportar @reboot você está usando o crix do vix? ... mostrar resultados do usuário crontab -l -u

comment # 2: ... Pode ser uma boa ideia configurá-lo como um script init em vez de confiar em uma versão específica do @reboot do cron.

comentário # 3: ... @MarkRoberts removeu a reinicialização e modificou o 1 * * * *, para * / 1 * * * *, o problema foi resolvido! Para onde envio os representantes Mark? Obrigado!

A resposta aceita nas perguntas e respostas também teve este comentário:

Parece-me que o Lubuntu não suporta a sintaxe @Reboot Cron.

Evidência adicional

ponto de dados # 3

Como evidência adicional, havia esse tópico de que alguém estava tentando a mesma coisa e ficava frustrado por não ter funcionado. O título é: Tópico: Cron - os trabalhos do @reboot não estão funcionando .

excerto

Re: Cron - os trabalhos @reboot não funcionam

Citação Postado originalmente por ceallred Ver Post Isso está me matando ... Tentei o script do wrapper. A execução manual gera o arquivo de log ... reinicializando e o trabalho não é executado ou cria um arquivo de log.

O Syslog mostra que o CRON executou o trabalho ... mas, novamente, nenhuma saída e o processo não está sendo executado. 15 de julho 20:07:45 RavenWing cron [1026]: (CRON) INFO (executando trabalhos do @reboot) 15 de julho 20:07:45 RavenWing CRON [1053]: (ceallred) CMD (/ home / ceallred / Scripts / run_spideroak). sh> /home/ceallred/Scripts/SpiderOak.log 2> & 1 &)

Parece que o cron não gosta do comando @reboot .... Alguma outra idéia?

Ok ... parcialmente resolvido. Vou marcar este como resolvido e iniciar um novo tópico com o novo problema .....

Acho que a resposta foi que meu diretório pessoal criptografado não foi montado quando o CRON estava tentando executar o script (armazenado em / home / nome de usuário / scripts). Movido para / usr / scripts e o trabalho é executado conforme o esperado.

Então agora parece ser um problema de aranha-aranha. O processo é iniciado, mas quando o processo de inicialização é concluído, ele se foi. Estou adivinhando um acidente por algum motivo .... Nova discussão para perguntar sobre isso.

Obrigado por toda a ajuda!

Depois que o usuário acima descobriu seu problema, ele conseguiu @reboottrabalhar com a entrada crontab de um usuário.

Não tenho certeza de qual versão do cron é usada no Ubuntu, mas isso parece indicar que o usuário também pode usar @rebootou que o bug foi corrigido em algum momento nas versões subseqüentes do cron.

ponto de dados # 4

Eu testei no CentOS 6 o seguinte e funcionou.

Exemplo

$ crontab -l
@reboot echo "hi" > /home/sam/reboot.txt 2>&1

Eu então reiniciei o sistema.

$ sudo reboot

Após a reinicialização.

$ cat reboot.txt 
hi

Aprendizado

  1. Esse recurso parece ser suportado para entradas do sistema e do usuário crontab.
  2. Você precisa garantir que ele seja suportado / funcione em sua distribuição específica e / ou versão do pacote cron.

Para saber mais sobre como o mecanismo real funciona, @rebootme deparei com este post do blog que discute as entranhas. É intitulado: @reboot - explicando a mágica simples do cron .

Crond de depuração

Você pode aumentar a verbosidade crondadicionando o seguinte a este arquivo de configuração nas distros baseadas em RHEL / CentOS / Fedora.

$ more crond 
# Settings for the CRON daemon.
# CRONDARGS= :  any extra command-line startup arguments for crond
CRONDARGS="-L 2"

Os níveis válidos são 0, 1 ou 2. Para reverter esse arquivo para o nível de log padrão, remova-o "-L 2"quando terminar de depurar a situação.

slm
fonte
Recebi um comentário ontem, olhou para a sua resposta e decidiu me responder depois de uma boa noite de sono. Configure uma VM, tentei novamente o @reboot, queria postar minha resposta e só então o vi 'reformular' sua resposta :-(
Anthon
@ Anthon - desculpe, eu respondi rapidamente ontem e depois continuei pesquisando e encontrei detalhes muito conflitantes. Quando encontrei o bug no Debian e no Ubuntu SO, percebi um pouco do que estava em jogo. Eu vi que funcionava no CentOS e o colocava @rebootem ordem em certos crons e, aparentemente, com erros / outros em outros. Daí a confusão.
slm
Além disso, o OP fornece poucos detalhes, você pode facilmente usar algo que ainda não funciona (no momento da inicialização) em seu script que o faz falhar ou que ele reside em um disco ainda não montado. Minha resposta, comentada pelo OP, também foi confirmada por terceiros. É o problema cisne negro ...
Anthon
@ Anthon - sim, um dos meus pontos de dados era exatamente isso. @rebootfuncionou quando você percebeu que estava tentando acessar uma unidade criptografada, que ainda não havia sido montada.
slm
3
Você pode querer salientar que o bug no Ubuntu é facilmente resolvido através da adição de um atraso: @reboot sleep 60; <your command>. Para citar o fio "meu palpite é que directiva @reboot do cron está em execução muito cedo no processo de inicialização"
PzKpfw
12

Descobri que, na minha máquina Ubuntu, ainda não tenho acesso aos serviços de DNS no momento do @reboot. Isso me impediu de montar volumes remotos. Essa solução brega, porém simples, funcionou:

@reboot sleep 60 && /home/me/bin/mount.sh 2>&1 >> /home/me/reboot.log

(no cron raiz; últimas partes apenas para depuração)

André
fonte
Esta é a única coisa que realmente funciona no ubuntu 16.04 para usuários não root!
Aleksandar Pavić
Não está funcionando no Debian 8 jessie (gnome 3). :(
Tadej
Isso funcionou para mim ao lidar com a montagem de pastas compartilhadas do VMWare em um local separado.
jgshawkey 25/07
3

Também tenho o mac osx e tive o mesmo problema em que meu script não estava sendo executado. mas quando eu corrigi meu script para gostar

@reboot   cd /home/me/  && sh myscript.sh

Funcionou bem para mim. certifique-se de tornar seu arquivo shell executável executando o comando

chmod +x myscript.sh
Kidane
fonte
2

Não sei se você já resolveu isso ou se alguma das opções acima foi a solução que você precisava, mas outra possibilidade é:

se você tiver seu diretório / home criptografado, ele poderá não estar disponível até você efetuar login, ou seja, não estará disponível na reinicialização.

Nesse cenário, você pode mover seus scripts para outro local como / srv ou / opt ou / usr / local / bin / etc.

fbas
fonte
1

Faça uma nova instalação do Ubuntu Gnome 13.10 (usuário padrão no meu caso: avanderneut).

avanderneut@uggo:~$ crontab -l
no crontab for avanderneut
avanderneut@uggo:~$ crontab -e
no crontab for avanderneut - using an empty one

Select an editor.  To change later, run 'select-editor'.
  1. /bin/ed
  2. /bin/nano        <---- easiest
  3. /usr/bin/vim.tiny

Choose 1-3 [2]: 3
crontab: installing new crontab
avanderneut@uggo:~$ crontab -l | tail -2
# m h  dom mon dow   command
@reboot /home/avanderneut/bin/on_reboot
avanderneut@uggo:~$ vi /home/avanderneut/bin/on_reboot
avanderneut@uggo:~$ more !$
more /home/avanderneut/bin/on_reboot
#! /bin/bash
echo "Reboot script" > /var/tmp/xxx
avanderneut@uggo:~$ chmod 755 /home/avanderneut/bin/on_reboot
avanderneut@uggo:~$ ls /var/tmp
avanderneut@uggo:~$ /home/avanderneut/bin/on_reboot
avanderneut@uggo:~$ ls /var/tmp
xxx
avanderneut@uggo:~$ rm /var/tmp/xxx
avanderneut@uggo:~$ sudo reboot
[sudo] password for avanderneut: 

E veja que, após a reinicialização, o arquivo /var/tmp/xxxexiste, embora não existisse antes da reinicialização.

Isso foi feito com o cron versão 3.0.

Você deve garantir que não sejam utilizados discos de serviços, etc., que talvez não estejam disponíveis no momento em que o script for executado. Comece com algo simples como o descrito acima e verifique se ele não possui saída de terminal, pois o e-mail provavelmente não está funcionando.

Você também pode precisar de um cron mais atualizado (ou uma atualização do oracle-linux) se isso não funcionar para você e você precisar desse recurso.

Anthon
fonte
Atualizei meu OP para responder às suas perguntas. Acontece que sua suspeita estava certa desde o início: o script a ser executado na reinicialização reside em uma /dev/mapper/VolGroup00-LogVol01partição montável .
Retido
@ Daniel Obrigado por me avisar, estou feliz que você encontrou o culpado. Não tenho certeza se você pode atrasar o início do cron até que as partições sejam montadas, parte dessa inicialização é feita em paralelo e você precisará alterar as dependências. Eu não gostaria de mexer com isso e possível quebra cron. Você deve IMHO seguir uma rota diferente da crontab & @reboot para executar algo uma vez na inicialização como usuário.
Anthon
0

Eu diria que sim para a pergunta. Só tive dificuldades com a execução do cron na reinicialização (Debian 3.10.70) e conseguiu resolver com:

@reboot root /usr/bin/python3 /path/to/script

E um caractere de nova linha '\ n' no final

Este é o conteúdo do arquivo:

/etc/cron.d/runOnReboot

Por fim, acho que vale a pena notar um resumo de man 5 crontab

... O formato de um comando cron é basicamente o padrão V7, com várias extensões compatíveis com versões anteriores. Cada linha possui cinco campos de hora e data, seguidos por um comando, seguido por um caractere de nova linha ('\ n'). O sistema crontab (/ etc / crontab) usa o mesmo formato, exceto que o nome de usuário para o comando é especificado após os campos de hora e data e antes do comando. Os campos podem ser separados por espaços ou tabulações. O comprimento máximo permitido para o campo de comando é 998 caracteres. ...

dmytro.poliarush
fonte
0

Primeiro de tudo, você deve fazer login como root:

sudo -i

Em seguida, abra o crontab:

crontab -e

Depois disso, adicione seu script ao crontab como root, como abaixo:

@reboot root / home / user1 / Desktop / meu_script

Como resultado, vi que meu script funcionava corretamente.

Nota: Se você editar o crontab com seu usuário atual, a reinicialização não poderá chamar seu script corretamente.

Mustafa Kemal
fonte
-1

prueba:

usuario @ ubuntu: ~ $ touch script.sh usuario @ ubuntu: ~ $ chmod + x script.sh

usuario @ ubuntu: ~ $ $ crontrab -e

@reboot /home/usuario/script.sh

salve e reinicie seu pc

gnuman
fonte