strongSwan

Started some load-test initators using multiple "ipsec load-tester initiate" commands: "ipsec load-tester initiate 10 100"

I would then terminate the tunnels using
"swanctl -t -i load-test" or "swanctl -t -i load-test --force"

After the tunnels all terminate, I would repeat by running additonal ipsec load-test commands. I started looking at the jobs/threads after seeing performance struggles on repeated tests.
I noticed that in the output of the "swanctl -S" command, the "jobs scheduled" field would not drop back to 0. The number of jobs would accumulate as I would run additional load-test commands.

Restarting the ipsec service does reset everything as expected. I don't have a need to be able to keep bringing test tunnels up and then down. Restarting ipsec is fine and I am expecting that is how this plugin may have been designed to be used, which is fine. However, I wanted to open a ticket in case there is a potential underlying issue outside the scope of the load-tester or if this isn't your expected behavior.

Below is some example out of the swanctl -S commands show the jobs scheduled not dropping to 0. Also included snippets from the load-tester and charon conf files.

03:37:05
worker threads: 32 total, 27 idle, working: 4/0/1/0
job queues: 0/0/0/0
jobs scheduled: 0
IKE_SAs: 0 total, 0 half-open

03:39:05
worker threads: 32 total, 27 idle, working: 4/0/1/0
job queues: 0/0/0/0
jobs scheduled: 30
IKE_SAs: 10 total, 0 half-open

03:40:35
worker threads: 32 total, 27 idle, working: 4/0/1/0
job queues: 0/0/0/0
jobs scheduled: 30
IKE_SAs: 0 total, 0 half-open

03:42:15
worker threads: 32 total, 27 idle, working: 4/0/1/0
job queues: 0/0/0/0
jobs scheduled: 320
IKE_SAs: 100 total, 0 half-open

03:43:55
worker threads: 32 total, 27 idle, working: 4/0/1/0
job queues: 0/0/0/0
jobs scheduled: 220
IKE_SAs: 0 total, 0 half-open

load-tester.conf

load-tester {
    load = yes
    enable = yes
    addrs_keep = no
    version = 2
    initiators = 0
    iterations = 0
    delay = 1000
    init_limit = 0
    ca_dir = /usr/local/etc/swanctl/x509ca
    issuer_cert = /usr/local/etc/swanctl/x509ca/enb-signing.crt
    issuer_key = /usr/local/etc/swanctl/private/enb-signing.key
    ike_rekey = 3600
    child_rekey = 1800
    crl = http://test/crl/enb/signing.crl.pem
    addrs
    {
    ens33 = 2001a:b:4001:f::2/64
    }
    addrs_keep = yes
    addrs_prefix = 64
    #initiator = 2001a:b:4001:f::1
    responder = 2001a:b:7001:1::1
    initiator_auth = pubkey
    responder_auth = pubkey
    responder_id = C=US, CN=site1pair1
    initiator_id = CN=conn-%d, OU=load-test, O=strongSwan
    initiator_tsi = ::/0
    initiator_tsr = ::/0
    delete_after_established = no
    digest = sha256
    mode = tunnel
    proposal = aes256gcm16-sha256-modp2048
    esp = aes256gcm16-sha256
    request_virtual_ip = yes
    dpd_delay = 30
    shutdown_when_complete = no
}

charon.conf (only configured parms shown, everything else is default)

charon {
     dos_protection = no
     ikesa_table_segments = 128
     ikesa_table_size = 1024
     initiator_only = yes
     install_routes = no
     install_virtual_ip = yes
     interfaces_use = ens33
     reuse_ikesa = no
     threads = 32   
}