Não consigo encontrar a maneira correta de executar alguns scripts locais (ou comandos muito locais) no systemd, já sei que não devo criar um serviço (no systemd uma unidade) para esse tipo de script (ou devo?) ....

A solução alternativa que encontrei é criar o rc.local e conceder permissões de execução.

printf '#!/bin/bash \n\nexit 0' >/etc/rc.local 
chmod +x /etc/rc.local

Por exemplo, se eu receber um servidor legado com um rc.local simples configurado por você, vou saber o que você fez e quanto vai doer para atualizar ou instalar algo novo na distribuição, pois o rc.local foi respeitado por fontes externas. pacotes, mas por outro lado, se eu instalar um servidor e criar uma unidade systemd ou dois ou três (ou até serviços sysvinit), apenas para executar uma tarefa simples, isso pode às vezes dificultar sua vida e muito mais do que isso minhas unidades algum dia os nomes podem entrar em conflito com os nomes dos novos serviços criados pelo desenvolvimento da distribuição e talvez instalados em uma atualização, causando problemas para meus scripts!

Vejo outra pergunta perguntando onde está o rc.local e a resposta foi criá-lo e conceder permissões de execução. Acho que minha pergunta não é realmente uma duplicata , porque não quero saber onde ela está - acredite, só quero para aceitar que está obsoleto , mas não consigo encontrar a maneira correta de fazer esse tipo de coisa, devo criar uma unidade apenas para coisas simples como essa?

Como salientado em outro lugar, torna-se moderadamente impuro para usar rc-local.servicesob systemd.

1. É teoricamente possível que sua distribuição não a habilite. (Eu acho que isso não é comum, por exemplo, porque desabilitar a mesma opção de compilação também remove poweroff/ rebootcomanda que muitas pessoas usam).
2. A semântica não é totalmente clara. O Systemd define rc-local.serviceuma maneira, mas o Debian fornece um arquivo drop-in que altera pelo menos uma configuração importante.

rc-local.servicemuitas vezes pode funcionar bem. Se você está preocupado com o exposto, tudo o que você precisa fazer é fazer sua própria cópia! Aqui está a mágica:

# /etc/systemd/system/my-startup.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/libexec/my-startup-script

[Install]
WantedBy=multi-user.target

Eu não acho que você precise entender todos os detalhes [*], mas há duas coisas que você precisa saber aqui.

1. Você precisa habilitar isso com systemctl enable my-startup.service.

2. Se o seu script depende de qualquer outro serviço, inclusive network-online.target, você deve declará-lo. Por exemplo, adicione uma [Unit]seção, com as linhas Wants=network-online.targete After=network-online.target.

   Você não precisa se preocupar com dependências nos serviços de "inicialização antecipada" - especificamente, serviços que já foram solicitados anteriormente basic.target. Serviços como my-startup.servicesão pedidos automaticamente depois basic.target, a menos que sejam definidos DefaultDependencies=no.

   Se você não tiver certeza se uma de suas dependências é um serviço de "inicialização antecipada", uma abordagem é listar os serviços encomendados antes basic.target, executando systemctl list-dependencies --after basic.target. (Observe que --afternão --before).

Há algumas considerações que eu acho que também se aplicavam ao pré-systemd rc.local:

1. Você precisa garantir que seus comandos não estejam em conflito com outro programa que tenta controlar a mesma coisa.
2. É melhor não iniciar programas de longa duração, também conhecidos como daemons rc.local.

[*] Eu usei Type=oneshot+ RemainAfterExit=yesporque faz mais sentido para a maioria dos scripts únicos. Ele formaliza que você executará uma série de comandos, que my-startupserão mostrados como "ativos" após a conclusão e que você não iniciará um daemon.

Esqueça rc.local.

Como eu disse sobre CentOS 7 e sobre o Debian 8 e sobre o Ubuntu 15 :

Você está usando um sistema operacional systemd + Linux. /etc/rc.localé um mecanismo de compatibilidade com versões anteriores duplas no systemd, porque é um mecanismo de compatibilidade com versões anteriores de um mecanismo que por si só era um mecanismo de compatibilidade no rcclone van Smoorenburg System 5 .

Usar /etc/rc.localpode dar terrivelmente errado. As pessoas ficaram surpresas com o fato de o systemd não funcionar rc.localda mesma maneira, no mesmo local do bootstrap, como estão acostumados. (Ou, erroneamente, espera: na verdade, ele não foi executado por último no sistema antigo, como o manual do OpenBSD ainda aponta.) Outros se surpreenderam com o fato de que o que eles criaram rc.localesperando as velhas formas de fazer as coisas é então completamente desfeita pelos gostos de novas udevregras, o NetworkManager, systemd-logind, systemd-resolved, ou vários "kit" s.

Como exemplificado por " Por que o` init 0` resulta em "Excesso de Argumentos" na instalação do Arch? ", Alguns sistemas operacionais já fornecem systemd sem os recursos de compatibilidade com versões anteriores , como o systemd-rc-local-generatorgerador . Enquanto o Debian ainda mantém os recursos de compatibilidade com versões anteriores , o Arch Linux constrói o systemd com eles desativados . Assim, no Arch e nos sistemas operacionais como ele esperam /etc/rc.local ser totalmente ignorados .

Esqueça rc.local. Não é o caminho a percorrer. Você tem um sistema operacional systemd + Linux. Portanto, faça uma unidade de serviço do sistema adequada e não comece a partir de um ponto que esteja a dois níveis de compatibilidade com versões anteriores. (No Ubuntu e no Fedora, ele é removido três vezes, o rcclone van Smoorenburg System 5 que se seguiu rc.localfoi substituído por duas vezes , há mais de uma década, primeiro pelo iniciante e depois pelo systemd.)

Lembre-se também da primeira regra para migrar para o systemd .

Essa nem é uma idéia nova, específica do systemd. Nos rcsistemas van Smoorenburg e Upstart, a coisa a fazer era criar um rcscript van Smoorenburg ou arquivo de trabalho Upstart adequado, em vez de usá-lo rc.local. Até o manual do FreeBSD observa que hoje em dia se cria um rcscript Mewburn adequado em vez de usar /etc/rc.local. Mewburn rcfoi introduzido pelo NetBSD 1.5 em 2000.

/etc/rc.localdata da época da sétima edição Unix e antes. Foi substituído por /etc/inittabum nível de execução rcno AT&T Unix System 3 (com um pouco diferente /etc/inittabno AT&T Unix System 5) em 1983 . Até isso agora é história.

Crie definições de serviço nativas apropriadas para o seu sistema de gerenciamento de serviços, seja um pacote configurável para os conjuntos de ferramentas nosh service-managere system-control, um /etc/rc.d/script para Mewburn rc, um arquivo de unidade de serviço para systemd, um arquivo de tarefa para Upstart, um diretório de serviço para runit / s6 / daemontools -core, ou mesmo um /etc/init.d/script para van Smoorenburg rc.

No systemd, esses arquivos de unidades de serviço adicionadas pelo administrador entram /etc/systemd/system/normalmente (ou /usr/local/lib/systemd/system/raramente). Com o nosh service manager, /var/local/sv/é um local convencional para pacotes de serviços locais. Mewburn rcnos usos do FreeBSD /usr/local/etc/rc.d/. Arquivos de unidades de serviço empacotados e pacotes de serviços, se você os estiver criando, vão para lugares diferentes.

Leitura adicional

• Lennart Poettering et al. (2014). systemd-rc-local-generator . páginas de manual do systemd. Freedesktop.org.
• rc.local. Manual do Gerente de Sistema FreeBSD . 23-04-2016.
• /unix//a/233581/5132
• Lennart Poettering (29/08/2011). Plese remover /etc/rc.localou chmod -xele . Redhat bug # 734268.
• /unix//a/211927/5132
• Dirk Schmitt (19/12/2017). rc.localestá começando cedo . systemd bug # 7703
• https://wiki.archlinux.org/index.php?title=Systemd&diff=378926&oldid=378924
• Benjamin Cane (30-12-2011). Quando está ok e não está ok para usarrc.local . bencane.com.
• /unix//a/49636/5132
• Lennart Poettering (01/10/2010). Como converter um script de inicialização do SysV em um arquivo de serviço systemd? . 0pointer.de.
• /ubuntu/523369/
• Jonathan de Boyne Pollard (2015). /etc/inittabé uma coisa do passado. . Respostas dadas com freqüência.
• Jonathan de Boyne Pollard (2014). Uma visão lado a lado dos scripts de execução e das unidades de serviço. . Respostas dadas com freqüência.
• Jonathan de Boyne Pollard (2014). Um exemplo prático do mundo real de configurar e executar um serviço com nosh . Softwares.
• Jonathan de Boyne Pollard (2016). " Faltando caminhos de pesquisa do sistema na systemd.unitpágina de manual ". Errata para o systemd doco . Respostas dadas com freqüência.

Resumo de https://www.linuxbabe.com/linux-server/how-to-enable-etcrc-local-with-systemd

Crie /etc/systemd/system/rc-local.service:

# /etc/systemd/system/rc-local.service
[Unit]
 Description=/etc/rc.local Compatibility
 ConditionPathExists=/etc/rc.local

[Service]
 Type=forking
 ExecStart=/etc/rc.local start
 TimeoutSec=0
 StandardOutput=tty
 RemainAfterExit=yes
 SysVStartPriority=99

[Install]
 WantedBy=multi-user.target

Então:

sudo touch /etc/rc.local
sudo chmod +x /etc/rc.local
sudo systemctl enable rc-local

Verificar com:

sudo systemctl start rc-local.service
sudo systemctl status rc-local.service