Questão Como executar scripts no arranque?


Como posso executar scripts? automaticamente quando o Ubuntu inicia, então eu não tenho que executá-los manualmente após a inicialização?


456
2017-08-04 19:54


origem


Se alguém também pudesse mostrar WHEN e ONDE isso seria incrível. Digo isso porque sei que existem pelo menos duas maneiras de iniciar um script que será disparado antes que outros aplicativos tenham sido iniciados (como o X11) - Buttink
Todo este tópico de resposta é uma bagunça. O formato do Stack Exchange não parece ser mais adequado para esta questão - Gabriel Fair
Na verdade é muito divertido. Quantas maneiras diferentes poderiam existir? - devios1


Respostas:


Dependendo do tipo de scripts que você precisa executar .. Para serviços e afins, você deve usar arrivista. Mas para um script de usuário, eles devem ser iniciados como scripts de sessão pelo gnome! Dê uma olhada em Sistema> Preferências> Aplicativos de inicialização.

Se você precisar de alguns scripts para serem executados no login do terminal, você pode adicioná-los ao .bash_login arquivo no seu diretório home.

Para 14.04 e mais velhos

Um comando simples (que não precisa permanecer em execução) poderia usar um trabalho do Upstart como:

start on startup
task
exec /path/to/command

Salve isso em um .conf arquivo em /etc/init (se você precisar que ele seja executado como root quando o sistema for inicializado) ou ~/.config/upstart (se você precisar disso para executar como seu usuário quando você efetuar login).


191
2017-08-04 23:26



Considerando como o SO e o StackExchange são executados, você poderia dar um exemplo de um script upstart e onde ele seria colocado? Isso tornaria isso uma resposta muito melhor. Seu link diz que não está sendo mantido e para olhar para o livro de receitas do upstart, que é huuuge. Eu não tenho muita ideia de onde começar. - Ehtesh Choudhury
E se eu precisar executar o comando como root? - dopatraman
@dopatraman A resposta afirma que todos os processos com isso são executados como root. - cybermonkey
Por favor, atualize esta resposta para explicar o que fazer em sistemas rodando systemd ao invés de upstart (Ubuntu 15.04+).
Essa resposta não faz sentido para mim. As aplicações listadas no system->pref->startup applications não pode ser encontrado em /etc/init/ nem em ~/.config/upstart. assim onde os aplicativos de inicialização são definidos? - Blauhirn


Uma abordagem é adicionar um @reboot cron tarefa:

  1. Corrida crontab -e permitirá que você edite seu cron.
  2. Adicionando uma linha como esta:

    @reboot /path/to/script
    

    irá executar esse script assim que o seu computador inicializar.


476
2017-08-04 19:57



o @reboot A palavra-chave é uma boa dica porque não é amplamente conhecida. - jathanism
Agradável. Qualquer ideia exatamente quando isso desencadeia? - Oli♦
Então ... isso não funcionaria se eu perdesse a energia e o computador ligasse novamente quando a energia fosse restaurada? - Mike Wills
@siamii: man 5 crontab diz que @reboot é executado na inicialização (quando o daemon do cron é iniciado). - jfs
Isso é incrível. Até agora isso parece melhor do que rc.local já que o sistema parece mais configurado por este ponto (PATH, etc). É estranho que seja tão difícil chamar algo depois de inicialização do sistema .. - Karthik T


Que tal adicionar o comando para /etc/rc.local? você precisará usar o acesso sudo para editar esse arquivo.

sudo nano /etc/rc.local

135
2017-08-05 16:40



Isso responde mais diretamente à pergunta: como simplesmente executar alguns scripts quando o sistema é inicializado. O upstart faz uma tarefa mais complexa: inicia os processos do daemon. - Dogweather
Então, o upstart inicia os processos daemon enquanto o /etc/rc.local inicia os scripts bash? - Donato
Esta deve ser a resposta aceita ... - Android Dev
Deveria? Isso não funciona mais hoje em dia, certo? - DaVince
Doenst trabalha com o Ubuntu 17.04 systemd - qodeninja


Existem diferentes maneiras de executar comandos automaticamente:

  1. o arrivista sistema irá executar todos os scripts a partir dos quais ele encontra uma configuração no diretório /etc/init. Esses scripts serão executados durante a inicialização do sistema (ou em resposta a determinados eventos, por exemplo, uma solicitação de desligamento) e, portanto, são o local para executar comandos que não interagem com o usuário; Todos os servidores são iniciados usando esse mecanismo.

    Você pode encontrar uma introdução legível em: http://upstart.ubuntu.com/getting-started.html as páginas do homem man 5 init e man 8 init dar-lhe os detalhes completos.

  2. Um script de shell chamado .gnomerc em seu diretório pessoal é automaticamente originado cada vez que você efetua login em uma sessão do GNOME. Você pode colocar comandos arbitrários lá; variáveis ​​de ambiente que você definir nesse script serão vistas por qualquer programa executado em sua sessão.

    Observe que a sessão não inicia até que o .gnomerc script está terminado; portanto, se você quiser iniciar automaticamente algum programa de longa execução, é necessário anexar & para a invocação do programa, a fim de separá-lo do shell em execução.

  3. A opção de menu Sistema -> Preferências -> Aplicativos de Inicialização permite que você defina quais aplicativos devem ser iniciados quando sua sessão gráfica for iniciada (o Ubuntu predefina bastante) e adicione ou remova-os ao seu gosto. Isto tem quase o mesmo propósito e escopo do .gnomerc script, exceto que você não precisa saber sh sintaxe (mas você também não pode usar sh construção de programação).


68
2017-08-05 14:02



3) "Isto tem quase o mesmo propósito e escopo do script .gnomerc", exceto .gnomerc aparentemente corre antes carregando Unity, e Startup Applications aparentemente corre depois de carregando Unity. Eu tive que executar um programa que fica na barra de menus do Unity e fez uma enorme diferença neste caso! - That Brazilian Guy
@ ruda.almeida Obrigado por apontar isso. A resposta foi escrita nos dias anteriores à Unity. - Riccardo Murri
sudo update-rc.d myscript.sh defaults, onde /etc/init.d/myscript.sh é o seu script, também o executa na inicialização. - Dan Dascalescu


Para 15.04 e posterior:

Para executar um (curta duração)1 comando na inicialização usando o systemd, você pode usar uma unidade do tipo systemd OneShot. Por exemplo, crie /etc/systemd/system/foo.service contendo:

[Unit]
Description=Job that runs your user script

[Service]
ExecStart=/some/command
Type=oneshot
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Então corra:

sudo systemctl daemon-reload
sudo systemctl enable foo.service

Essencialmente, isso é apenas converter um trabalho típico do Upstart para um sistema (ver Systemd para usuários do Upstart).

Você pode executar vários comandos do mesmo arquivo de serviço, usando vários ExecStart linhas:

[Service]
ExecStart=/some/command
ExecStart=/another/command some args
ExecStart=-/a/third/command ignore failure

O comando deve ser sempre dado com o caminho completo. Se algum comando falhar, o resto não será executado. UMA - antes que o caminho informe ao systemd para ignorar um status de saída diferente de zero (em vez de considerá-lo uma falha).

Relevante:


Para sessões de usuário, você pode criar a unidade systemd ~/.config/systemd em vez de. Isso deve funcionar com o 16.04 em diante, mas não com versões anteriores do Ubuntu com o systemd (já que elas ainda usam o Upstart para sessões de usuários). As unidades de sessão do usuário podem ser controladas com os mesmos comandos dos serviços do sistema, mas com o --user opção adicionada:

systemctl --user daemon-reload
systemctl --user status foo.service

1Ao contrário de daemons de vida longa.


53
2018-01-09 19:21



é possível definir uma prioridade no trabalho? ou especificar que depende de outro serviço ser iniciado primeiro? - r3wt
@ r3wt sim, existem maneiras diferentes de fazer isso. o WantedBy usado aqui, por exemplo, faz com que quando o multi-user.target é atingido. Você pode usar Before, After, Requires, etc. Ver man systemd.unit - muru
@PerlDuck não é a única coisa que faltava. Obrigado! - muru
Seja bem-vindo. - Btw, o RemainAfterExit depende do serviço que você inicia e do comportamento desejado. Por exemplo, /bin/df -h <s> </ s> deveria ter RemainAfterExit=no. - PerlDuck
@PerlDuck Não há nada inerente em df que precisa RemainAfterExit=no. A menos que você queira executar repetidamente o comando toda vez que executar systemctl start foo. - muru


$HOME/.config/autostart
  • Este local contém a lista de aplicativos de inicialização.
  • .desktop arquivo pode ser colocado aqui que será executado na inicialização.

Exemplo de exemplo para .desktop Arquivo:

Colocando o seguinte .desktop arquivo em $HOME/.config/autostart e dado chmod +x:

[Desktop Entry]
Type=Application
Exec="</path/to/script>"
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name=Startup Script

Aqui "</path/to/script>" é substituído por caminho para o seu script.sh
(geralmente recomendado para /usr/local/bin so-that pode ser executado por comando direto dizer myscript substituído por "</path/to/script>").

Exemplo de exemplo de script.sh:

#!/bin/bash
<commands to be executed>
exit

Resultado: .desktop arquivo será lançado a partir de $HOME/.config/autostart que executa script por Exec=

Portanto, você pode executar o script de shell desejado na inicialização!


22
2017-07-20 06:14





Para coisas simples, você pode adicionar um comando em Sistema-> Preferências-> Sessões apontando para a localização do seu script.

Alternativamente, você pode adicioná-lo ao /etc/init.d/rc.local ou fazer uma arrivista trabalho se é mais nível baixo coisa.

Dê uma olhada https://help.ubuntu.com/community/UbuntuBootupHowto para mais informações


18
2017-08-04 19:59





Você deveria usar arrivista por esta. O Upstart é usado para processos do Ubuntu que são iniciados automaticamente. É uma solução aprimorada como os antigos scripts init.d do System-V. Ele também permite colocar pré-requisitos no início do script (ou seja, você precisa da rede em execução? Etc.)


5
2017-08-04 19:58





cron resposta implementada diferente do topo votou

Esta resposta ainda usa cron mas usa um método diferente do que a resposta mais votada. Isso funciona desde o Ubuntu 16.04, mas provavelmente suportado muito mais cedo. É só que eu comecei a usar cron para executar trabalhos quando o computador é inicializado a partir de 16.04.

Quando faz cron corre?

Nos comentários alguém perguntou "quando eles correm?". Você pode dizer no syslog / journalctl:

$ journalctl -b | grep cron
Jan 02 16:54:40 alien cron[919]: (CRON) INFO (pidfile fd = 3)
Jan 02 16:54:40 alien cron[919]: (CRON) INFO (Running @reboot jobs)
Jan 02 16:54:40 alien systemd[1]: Started Run anacron jobs.
Jan 02 16:54:40 alien anacron[949]: Anacron 2.3 started on 2018-01-02
Jan 02 16:54:40 alien anacron[949]: Normal exit (0 jobs run)
Jan 02 16:54:40 alien CRON[952]: pam_unix(cron:session): session opened for user root by (uid=0)
Jan 02 16:54:40 alien CRON[954]: pam_unix(cron:session): session opened for user root by (uid=0)
Jan 02 16:54:40 alien CRON[951]: pam_unix(cron:session): session opened for user root by (uid=0)
Jan 02 16:54:40 alien CRON[950]: pam_unix(cron:session): session opened for user root by (uid=0)
Jan 02 16:54:40 alien CRON[985]: (root) CMD (   /usr/local/bin/cron-reboot-cycle-grub-background)
Jan 02 16:54:40 alien CRON[954]: pam_unix(cron:session): session closed for user root
Jan 02 16:54:40 alien cron[919]: sendmail: Cannot open smtp.gmail.com:587
Jan 02 16:54:40 alien CRON[952]: pam_unix(cron:session): session closed for user root
Jan 02 16:54:40 alien cron[919]: sendmail: Cannot open smtp.gmail.com:587
Jan 02 16:54:40 alien CRON[950]: pam_unix(cron:session): session closed for user root

Uma coisa a notar é cron pode enviar um e-mail com o status dos trabalhos executados e @reboot empregos correm tão cedo gerente de rede e e-mail não será executado a menos que você coloque um sleep comando em seu (s) script (s).

Onde colocar seus scripts

Coloque seus scripts no diretório /etc/cron.d:

$ ll /etc/cron.d
total 44
drwxr-xr-x   2 root root  4096 Nov 26 19:53 ./
drwxr-xr-x 139 root root 12288 Dec 31 13:58 ../
-rw-r--r--   1 root root   244 Dec 28  2014 anacron
-rw-r--r--   1 root root   148 Feb 18  2017 cycle-grub-background
-rw-r--r--   1 root root   138 Mar  5  2017 display-auto-brightness
-rw-r--r--   1 root root   460 Nov 26 19:53 nvidia-hdmi-sound
-rw-r--r--   1 root root   102 Feb  9  2013 .placeholder
-rw-r--r--   1 root root   224 Nov 19  2016 touch-vmlinuz
-rw-r--r--   1 root root   700 Aug  5 11:15 turn-off-hyper-threading

Como é um script?

Aqui estão alguns scripts que eu configurei para executar cada inicialização:

$ cat /etc/cron.d/cycle-grub-background SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin 
@reboot   root    /usr/local/bin/cron-reboot-cycle-grub-background

$ cat /etc/cron.d/touch-vmlinuz
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
@reboot   root    touch "/boot/vmlinuz-"`uname -r`

3
2018-01-03 01:02



Existem muitas maneiras diferentes de adicionar cronjobs, mas o núcleo da resposta altamente votada e sua resposta ainda é a @reboot. - muru
Métodos alternativos para adicionar crontabs devem ser postados para askubuntu.com/q/2368/158442, que é explicitamente sobre como adicionar tarefas Cron. - muru
Eu peço desculpa mas não concordo. O núcleo da resposta em questão utiliza crontab -e que alguns consideram uma das artes negras devido a uma interface parecida com o vim. Por outro lado, essa resposta pode ser atraente para aqueles cujos cérebros estão ligados de certa maneira. Nós não somos todos lançados do mesmo molde. Então, novamente, esta resposta já tem um voto baixo, então vamos deixar a democracia seguir seu curso. - WinEunuuchs2Unix
Oh, por favor. Você e eu sabemos que o editor pode ser alterado. - muru
@muru Sim, provavelmente porque você me ensinou e eu aprendi a mudar de editor para algo como nano ou um par de outras CLI's. Mas eu estou no campo de gedit. Além disso crontab -e traz memórias de asteriscos ("*") por minutos, horas, etc., que eu sempre achei que precisava de instruções no google. Eu ainda acho usando /etc/cron.d e /etc/cron.daily minha escolha. Especialmente desde que espelha /etc/udev/rules.d e /etc/systemd/system-sleep métodos. Parece um bom ajuste. - WinEunuuchs2Unix