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