Public bug reported:

Hello,

Ubuntu ships a custom /lib/systemd/system/strongswan.service. I have
noticed if I start then stop strongswan without a delay, strongswan may
end in a running state. There is a small race condition in how ipsec is
started and the PID is written after forking while stop is using the PID
to kill the running instance.

Upstream ships a far simpler systemd file:

[Service]
ExecStart=@SBINDIR@/@IPSEC_SCRIPT@ start --nofork
StandardOutput=syslog

Stop action is handled directly by systemd. No PID file handling is
needed. However, since start is done with --nofork, the unit is ready
while strongSwan may not be started yet. However, looking at the source
code of strongSwan, I see it forks quite early, before charon is
started. I would suggest to keep upstream service file (or patch it like
Debian to add "reload" action).

** Affects: strongswan (Ubuntu)
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1734886

Title:
  strongswan service file should be upstream one

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/strongswan/+bug/1734886/+subscriptions

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to