Encontrei este arquivo de serviço systemd para iniciar o autossh e manter um túnel ssh: https://gist.github.com/thomasfr/9707568

[Unit]
Description=Keeps a tunnel to 'remote.example.com' open
After=network.target

[Service]
User=autossh
# -p [PORT]
# -l [user]
# -M 0 --> no monitoring
# -N Just open the connection and do nothing (not interactive)
# LOCALPORT:IP_ON_EXAMPLE_COM:PORT_ON_EXAMPLE_COM
ExecStart=/usr/bin/autossh -M 0 -N -q -o "ServerAliveInterval 60" -o "ServerAliveCountMax 3" -p 22 -l autossh remote.example.com -L 7474:127.0.0.1:7474 -i /home/autossh/.ssh/id_rsa

[Install]
WantedBy=multi-user.target

Existe uma maneira de configurar o systemd para iniciar vários túneis em um serviço.

Não quero criar arquivos de serviço do sistema N, pois quero evitar copiar e colar.

Todos os arquivos de serviço seriam idênticos, exceto que "remote.example.com" seria substituído por outros nomes de host.

1,5 ano depois ...

Eu fiz essa pergunta aproximadamente 1,5 ano atrás.

Minha mente mudou um pouco. Sim, é bom que você possa fazer isso com o systemd (eu ainda o uso), mas usarei o gerenciamento de configurações no futuro.

Por que o systemd deve implementar uma linguagem de modelo e substituir% h?

Vários meses depois, acho que esse loop e modelagem devem ser resolvidos com uma ferramenta que automatiza a configuração. Eu uso uma ferramenta desta lista na wikipedia agora.

Bem, assumindo que a única coisa que muda por arquivo de unidade é a remote.example.comparte, você pode usar um Serviço Instanciado .

Na systemd.unitpágina do manual:

Opcionalmente, as unidades podem ser instanciadas a partir de um arquivo de modelo em tempo de execução. Isso permite a criação de várias unidades a partir de um único arquivo de configuração. Se o systemd procurar um arquivo de configuração da unidade, ele primeiro procurará o nome da unidade literal no sistema de arquivos. Se isso não der certo e o nome da unidade contiver um caractere "@", o systemd procurará um modelo de unidade que compartilhe o mesmo nome, mas com a cadeia de instância (ou seja, a parte entre o caractere "@" e o sufixo) removida. Exemplo: se um serviço getty@tty3.service for solicitado e nenhum arquivo com esse nome for encontrado, o systemd procurará getty @ .service e instanciará um serviço desse arquivo de configuração, se for encontrado.

Basicamente, você cria um único arquivo de unidade, que contém uma variável (geralmente %i) onde as diferenças ocorrem e, em seguida, elas são vinculadas quando você "ativa" esse serviço.

Por exemplo, eu tenho um arquivo de unidade chamado /etc/systemd/system/autossh@.serviceque se parece com isso:

[Unit]
Description=AutoSSH service for ServiceABC on %i
After=network.target

[Service]
Environment=AUTOSSH_GATETIME=30 AUTOSSH_LOGFILE=/var/log/autossh/%i.log AUTOSSH_PIDFILE=/var/run/autossh.%i.pid
PIDFile=/var/run/autossh.%i.pid
#Type=forking
ExecStart=/usr/bin/autossh -M 40000 -NR 5000:127.0.0.1:5000 -i /opt/ServiceABC/.ssh/id_rsa_ServiceABC -l ServiceABC %i

[Install]
WantedBy=multi-user.target

Que eu habilitei

[user@anotherhost ~]$ sudo systemctl enable autossh@somehost.example.com
ln -s '/etc/systemd/system/autossh@.service' '/etc/systemd/system/multi-user.target.wants/autossh@somehost.example.com.service'

E pode interagir com

[user@anotherhost ~]$ sudo systemctl start autossh@somehost.example.com
[user@anotherhost ~]$ sudo systemctl status autossh@somehost.example.com
autossh@somehost.example.service - AutoSSH service for ServiceABC on somehost.example
   Loaded: loaded (/etc/systemd/system/autossh@.service; enabled)
   Active: active (running) since Tue 2015-10-20 13:19:01 EDT; 17s ago
 Main PID: 32524 (autossh)
   CGroup: /system.slice/system-autossh.slice/autossh@somehost.example.com.service
           ├─32524 /usr/bin/autossh -M 40000 -NR 5000:127.0.0.1:5000 -i /opt/ServiceABC/.ssh/id_rsa_ServiceABC -l ServiceABC somehost.example.com
           └─32525 /usr/bin/ssh -L 40000:127.0.0.1:40000 -R 40000:127.0.0.1:40001 -NR 5000:127.0.0.1:5000 -i /opt/ServiceABC/.ssh/id_rsa_ServiceABC -l ServiceABC somehost.example.com

Oct 20 13:19:01 anotherhost.example.com systemd[1]: Started AutoSSH service for ServiceABC on somehost.example.com.
[user@anotherhost ~]$ sudo systemctl status autossh@somehost.example.com
[user@anotherhost ~]$ sudo systemctl status autossh@somehost.example.com
autossh@somehost.example.com.service - AutoSSH service for ServiceABC on somehost.example.com
   Loaded: loaded (/etc/systemd/system/autossh@.service; enabled)
   Active: inactive (dead) since Tue 2015-10-20 13:24:10 EDT; 2s ago
  Process: 32524 ExecStart=/usr/bin/autossh -M 40000 -NR 5000:127.0.0.1:5000 -i /opt/ServiceABC/.ssh/id_rsa_ServiceABC -l ServiceABC %i (code=exited, status=0/SUCCESS)
 Main PID: 32524 (code=exited, status=0/SUCCESS)

Oct 20 13:19:01 anotherhost.example.com systemd[1]: Started AutoSSH service for ServiceABC on somehost.example.com.
Oct 20 13:24:10 anotherhost.example.com systemd[1]: Stopping AutoSSH service for ServiceABC on somehost.example.com...
Oct 20 13:24:10 anotherhost.example.com systemd[1]: Stopped AutoSSH service for ServiceABC on somehost.example.com.

Como você pode ver, todas as instâncias do %iarquivo de unidade são substituídas por somehost.example.com.

Porém, existem muitos outros especificadores que você pode usar em um arquivo de unidade, mas acho %ique funciona melhor em casos como este.

Aqui está um exemplo de python, que era o que eu estava procurando. O @nome do arquivo no serviço permite iniciar N processos:

$ cat /etc/systemd/system/my-worker@.service

[Unit]
Description=manages my worker service, instance %i
After=multi-user.target

[Service]
PermissionsStartOnly=true
Type=idle
User=root
ExecStart=/usr/local/virtualenvs/bin/python /path/to/my/script.py
Restart=always
TimeoutStartSec=10
RestartSec=10

Vários métodos para chamá-lo

Ativando várias contagens, por exemplo:

• Permita 30 trabalhadores:

  sudo systemctl enable my-worker\@{1..30}.service
  

• Habilite 2 trabalhadores:

  sudo systemctl enable my-worker\@{1..2}.service
  

Certifique-se de recarregar:

sudo systemctl daemon-reload

Agora você pode iniciar / parar de várias maneiras:

• Início 1:

  sudo systemctl start my-worker@2.service
  

• Iniciar vários:

  sudo systemctl start my-worker@{1..2}
  

• Parar vários:

  sudo systemctl stop my-worker@{1..2}
  

• Verificar status:

  sudo systemctl status my-worker@1
  

ATUALIZAÇÃO : para gerenciar instâncias como um serviço, você pode fazer algo assim:

/etc/systemd/system/some-worker@.service:

[Unit]
Description=manage worker instances as a service, instance %i
Requires=some-worker.service
Before=some-worker.service
BindsTo=some-worker.service

[Service]
PermissionsStartOnly=true
Type=idle
User=root
#EnvironmentFile=/etc/profile.d/optional_envvars.sh
ExecStart=/usr/local/virtualenvs/bin/python /path/to/my/script.py
TimeoutStartSec=10
RestartSec=10

[Install]
WantedBy=some-worker.service

/usr/bin/some-worker-start.sh:

#!/bin/bash
systemctl start some-worker@{1..10}

/etc/systemd/system/some-worker.service:

[Unit]
Description=manages some worker instances as a service, instance

[Service]
Type=oneshot
ExecStart=/usr/bin/sh /usr/bin/some-worker-start.sh
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

E agora você pode gerenciar todas as instâncias com sudo systemctl some-worker (start|restart|stop)

Aqui está um exemplo para o seu script.py:

#!/usr/bin/env python

import logging


def worker_loop():
    shutdown = False
    while True:

        try:
            if shutdown:
                break

            # Your execution logic here.
            # Common logic - i.e. consume from a queue, perform some work, ack message
            print("hello world")

        except (IOError, KeyboardInterrupt):
            shutdown = True
            logging.info("shutdown received - processing will halt when jobs complete")
        except Exception as e:
            logging.exception("unhandled exception on shutdown. {}".format(e))


if __name__ == '__main__':
    worker_loop()

A resposta de GregL me ajudou bastante. Aqui está um exemplo de um modelo de unidade que eu usei no meu código usando o exemplo acima para um servidor de tarefas gearman. Eu criei um script de shell que me permite criar uma quantidade X de "trabalhadores" usando este modelo.

[Unit]
Description=az gearman worker
After=gearman-job-server.service

[Service]
PIDFile=/var/run/gearman_worker_az%i.pid
Type=simple
User=www-data
WorkingDirectory=/var/www/mysite.com/jobs/
ExecStart=/usr/bin/php -f gearman_worker_az.php > /dev/null 2>&1
Restart=on-success
KillMode=process

[Install]
WantedBy=multi-user.target