Voici un exemple en Python, qui correspond à ce que je cherchais. Les @ dans le nom du fichier de service permet de lancer N processus :

$ 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

Différentes méthodes pour l'appeler

Permettre divers décomptes, par exemple :

• Permettre à 30 travailleurs de travailler :

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

• Activer 2 travailleurs :

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

Veillez ensuite à recharger :

sudo systemctl daemon-reload

Désormais, vous pouvez démarrer/arrêter de différentes manières :

• Début 1 :

  sudo systemctl start my-worker@2.service

• Début Multiple :

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

• Stop Multiple :

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

• Vérifier l'état :

  sudo systemctl status my-worker@1

MISE À JOUR : Pour gérer les instances en tant que service unique, vous pouvez procéder comme suit :

/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

Vous pouvez désormais gérer toutes les instances à l'aide de sudo systemctl some-worker (start|restart|stop)

Voici un modèle de document pour votre 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()

La réponse de GregL m'a beaucoup aidé. Voici un exemple de modèle d'unité que j'ai utilisé dans mon code en utilisant l'exemple ci-dessus pour un serveur de travail gearman. J'ai créé un Shell Shell qui me permet de créer un nombre X de "travailleurs" en utilisant ce modèle.

[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

J'ai cherché une solution à une tâche similaire et j'en ai trouvé une, que je crois plus facile à réaliser, mais qui est censée être bidouillé . (et n'est pas mentionné ici)

J'avais besoin de créer plusieurs connexions ssh après que le vpn ait créé un tunnel, J'ai donc créé un service qui dépend de l'appareil tun et qui appelle Shell Shell avec les commandes appropriées.

Service /etc/systemd/system/ssh_tunnel.service :

[Unit]
Description=Reverse SSH Service to access hidden services
ConditionPathExists=|/usr/bin
Wants=sys-devices-virtual-net-tun0.device
After=network.target sys-devices-virtual-net-tun0.device

[Service]
Type=forking
ExecStart=/bin/sh /etc/openvpn/ssh_tunnels.sh 
RemainAfterExit=yes
TimeoutSec=0
GuessMainPID=no

[Install]
WantedBy=multi-user.target

/etc/openvpn/ssh_tunnels.sh :

!/bin/bash
#sleep 15

echo 'Tunelling some ports'
killall -HUP ssh

su - user -c 'ssh -f admin@172.171.1.1 -p 9999 -L :3690:svn.newbox.ru:3690 -L :8888:10.1.20.55:80 -L :8181:10.1.10.10:80 -N -vvv'

ssh -i /home/user/.ssh/id_rsa -f admin@172.171.1.1 -p 9999 -L :587:mail.domain.ru:587 -L :995:mail.newbox.ru:995 -L :22:10.1.2.1:22 -N -vvv &

exit 0

Résultat :

# systemctl status ssh_tunnel.service
 ssh_smartex.service - Reverse SSH Service to access hidden services
     Loaded: loaded (/etc/systemd/system/ssh_tunnel.service; enabled; vendor preset: disabled)
     Active: active (running) since Fri 2020-03-20 16:01:07 UTC; 22min ago
    Process: 156 ExecStart=/bin/sh /etc/openvpn/ssh_tunnel.sh (code=exited, status=0/SUC>
      Tasks: 2 (limit: 4915)
     Memory: 3.8M
     CGroup: /system.slice/ssh_tunnel.service
             166 ssh -f admin@172.171.1.1 -p 9999 -L :3690:svn.newbox.ru:3690 -L :8888:10.1.20.55:80 ->
             168 ssh -i /home/user/.ssh/id_rsa -f admin@172.171.1.1 -p 9999 -L :587:mail.newbox.ru:5>
...

Cependant, je n'ai pas encore vérifié comment il survit au redémarrage du vpn, mais c'est un autre sujet.