Pular para o conteúdo principal

Como colocar script para iniciar com Linux


Para um programa/script específico ser executado na inicialização do sistema, pode-se editar o arquivo “/etc/rc.local”. Nele, deve-se colocar o caminho completo do script e finalizar a linha com & (e comercial), para executar em background, logo antes do “exit 0”.
Existem formas diferentes conforme o sistema de inicialização utilizado: Systemd ou System V (ou Sysvinit). Uma variação. Uma das principais razões para o Debian mudar do SysV para o systemd é a popularização de computadores com mais de um núcleo, de modo aproveitar melhor o paralelismo do que a tentativa realizada pelo Upstart (da Canonical, que mantém o Ubuntu).
O systemd é compatível com o SysV e Scripts de init LSB (Linux Standard Base), mas possui padrões diferentes para conter basicamente a mesma informação. O comando service é uma ferramenta de “compatibilidade” para ajudar as pessoas a migrar de sysvinit para systemd. É um programa que tenta descobrir seu sistema de inicialização atual e chamará as chamadas sysvinit, upstart ou systemd, conforme necessário.
Systemd (systemctl)
É baseado na notação de sete tipos diferentes de unidades (ou units), cujo nome é composto de uma identificação e o seu tipo como sufixo (se não for especificado, o systemctl assumirá .service):
  • service – daemons que podem ser iniciados, parados, reiniciados e recarregados.
  • socket – encapsula um socket no sistema de arquivos ou na Internet; sockets são programas responsaveis pela comunicação ou interligação de outros programas que atuam na camada de transporte, como os “Stream Sockets” (usado no telnet) e os “Datagram Sockets” (usam UDP em vez de TCP).
  • device – encapsula um dispositivo na árvore de dispositivos do Linux; se é marcado através de regras no udev, ele será exposto a um dispositivo de unidade no systemd.
  • mount – encapsula um ponto de montagem na hierarquia do sistema de arquivos.
  • automount – encapsula um ponto de montagem automático na hierarquia do sistema de arquivos; cada unidade automount, tem uma unidade mount correspondente, que é iniciada(montada) assim que o diretório automount é acessado.
  • target – usada para agrupamento lógico de unidades, referenciando outras unidades que podem ser controladas então de forma conjunta (por exemplo, “multi-user.target” é uma unidade que basicamente equivale a regra do run-level 5 no clássico SysV).
  • snapshot – similar a unidade target, a unidade snapshot não faz nada por si so a não ser referenciar outras unidades.
O arquivo do exemplo a seguir deve ser colocado dentro de /etc/systemd/system/ (preferencialmente) ou /usr/lib/systemd/system/ e ter a extensão .service, com o seguinte formato:
Depois de editado, torne o arquivo executável (chmod +x) e teste usando o seguinte comando:
Ela também pode ser parada (stop), reiniciada (restart) ou ter sua configuração recarregada (reload). O seguinte comando recarrega o systemd, scaneando por units novas e modificadas, além de habilitar a unit para ser iniciada na inicialização
Por fim, seu status pode ser verificado com “sudo systemctl status exemplo.service” e reiniciado com “sudo systemctl reload-or-restart exemplo.service”. Para estar funcionando, deve estar com status “loaded” e “active (running)”.
System V (SysV ou sysvinit)
Também é possível colocar o script diretamente no diretório “/etc/init.d” – lembrando de dar permissão de execução através do comando “sudo chmod 755 nome_do_script”. Nesse caso, executar “sudo update-rc.d nome_do_script defaults” para criar o link simbólico de modo a executá-lo na inicialização – para removê-lo, utilize “remove” em vez de “defaults”.
Um script LSB (Linux Standard Base) Init tem como principal finalidade a execução de comandos na inicialização do sistema operacional seguindo uma padronização. Para isso, ele deve ter suporte para as seguintes ações: start, stop, restart, force-reload, e status. Além disso, deve retornar uma saída de erros apropriada e ter as “run-time dependencies”: um cabeçalho padrão no início do script com as informações necessárias ao seu funcionamento. Cada linha tem sua função:
  • Provides: especifica qual é a facility executada por este script Init (o nome deve ser único);
  • Required-start: especifica o conjunto de facilities que deve ser iniciado antes de começar este serviço. Além de nomes “reais” de programas (postgresql, por exemplo), também existem alguns nomes para facilities “virtuais”, iniciados por cifrão: local_fs, remote_fs, network, named, portmap, syslog, time e all;
  • Required-Stop: especifica a lista de facilities que devem ser paradas depois de parar esta facility.
  • Default-Start e Default-Stop: definem os níveis de execução em que o serviço deve ser iniciado ou parado. Veja mais sobre o init e os runlevels no post sobre Linux Debian.
  • Short-Description e Description: apresentam a descrição do serviço.
A segunda parte do script deve conter um “case” para ações diferenciadas ao receber o argumento “start”, “stop” ou outros. Veja um exemplo do arquivo “/etc/init.d/firewall” para executar o shell script “firewall.sh”:
Por ser um shell script, o arquivo “firewall.sh” deve ter “#!/bin/bash” na primeira linha, indicando que será executado através do binário “/bin/bash”. Sua inicialização deve indicar o caminho completo do arquivo ou uma mudança para esse diretório. Aqui também inclui o redirecionando das saídas 1 (padrão) e 2 (erros) para um arquivo de log, além de ser executado em background (último “e comercial”). O comando “pkill -f” permite encerrar todos os processos que contenham o padrão “firewall” em seus nomes.
Execute o comando “update-rc.d firewall defaults”. Caso apareça uma mensagem do tipo “insserv: warning: current start runlevel(s) (2 3 4 5) of script”, execute “update-rc.d firewall remove” e “update-rc.d firewall defaults” depois.
Obs.: Caso o script executado imprima mensagens na tela (saída de uma comunicação serial, por exemplo), você também pode redirecionar a saída padrão para uma outra tela/console. Para isso, inclua “1> /dev/tty1”, por exemplo, na linha de execução do script para enviar o texto para outra tela, e assim não ficar imprimindo um monte de coisas na tela onde vocês está trabalhando. Caso tenha mais de um script, pode direcionar para outra tela (tty2, etc).
Para iniciar o serviço, execute o comando “/etc/init.d/firewall start” ou reinicie o computador.
Crontab
O serviço de agendamento de tarefas do Linux também pode ser usado para iniciar um script na inicialização. O texto a seguir pode ser incluído no crontab do usuário através do comando “crontab -e”:
Ao reiniciar o computador, deve aparecer o texto “Monolito Nimbus” escrito no arquivo “teste.txt” – ou alguma mensagem de erro, se for o caso. Veja mais sobre Agendamento de tarefas no crontab clicando no link.
Fontes

Comentários

Postagens mais visitadas deste blog

Upgrading Iomega ix2-200 to Cloud Edition

You just got your ix2-200 from eBay and there are no disks inside the NAS. Or you have a brand new ix2-200 -yet you could not afford Cloud Edition. No problem. With just a USB stick and a SATA adapter or desktop PC, you will easily upgrade your ix2-200 to ix2-200 Cloud Edition. Not only your ix2-200 will have a brand new interface and Cloud options, but also will become Mac OS X Lion compatible! What do we need? Decrypted! ix2-200 Cloud Edition Firmware 3.1.12.47838 S endSpace or RapidShare * USB Flash Drive with at least 2 GB capacity and LED indicator** SATA to USB adapter or desktop PC Toothpick or paperclip Preparing Hard Drives Preparing hard drives is the first step because you have to wipe all the data inside the hard drives and make them just like brand new. We used 2 x Seagate 2 TB 5900 RPM Drives. Backup any files if you have and then remove both disks from ix2-200 and attach them to SATA to USB adapter or your desktop PC's SATA port. Using ...

How to Fix sub-process /usr/bin/dpkg returned an error code (1)

Introduction The error message “Sub-process /usr/bin/dpkg returned an error code (1)” indicates a problem with the package installer. This can happen in Ubuntu after a failed software installation, or if the installer becomes corrupted. The key phrase in this error is /usr/bin/dpkg. This refers to the dpkg package installer for Linux. A package installer is an application that tracks software, updates, and dependencies. If it is damaged, any new software installation will cause this error message. We cover several possible solutions, from easily-solved and straightforward solutions to more complex processes. This guide will help you resolve the dpkg returned an error code 1 on an Ubuntu operating system. Prerequisites A user account with sudo privileges A terminal window/command-line ( Ctrl - Alt - T ) Options to Fix sub-process /usr/bin/dpkg returned an error code (1) Method 1: Reconfigure dpkg Database ...

How to Create Reports from Audit Logs Using ‘aureport’ on CentOS/RHEL

  What is aureport? aureport is a command line utility used for creating useful summary reports from the audit log files stored in /var/log/audit/ . Like ausearch , it also accepts raw log data from stdin. It is an easy-to-use utility; simply pass an option for a specific kind of report that you need, as shown in the examples below. Create Report Concerning Audit Rule Keys The aurepot command will produce a report about all keys you specified in audit rules, using the -k flag. # aureport -k Report Audit Rule Keys You can enable interpreting of numeric entities into text (for example convert UID to account name) using the -i option. # aureport -k -i Create Report About Attempted Authentications If you need a report about all events relating to attempted authentications for all users, use the -au option. # aureport -au OR # aureport -au -i   Summary of Login Authentication Produce Report Concerning Logins The -l option tells aureport to ge...