Using "ipsec start|stop|restart" confuses upstart/systemd

[Simon Déziel]

When using "ipsec start|stop" directly it confuses the upstrart job that cannot track the status of the daemon.

To reproduce:

 start strongswan
 ipsec stop
 status strongswan

The status command will report strongswan is running while it isn't. Attempting to start it will then fail: "Job is already running: strongswan"

$ lsb_release -rd
Description: Ubuntu Trusty Tahr (development branch)
Release: 14.04
$ apt-cache policy strongswan-starter
strongswan-starter:
  Installed: 5.1.2-0ubuntu1
  Candidate: 5.1.2-0ubuntu1
  Version table:
 *** 5.1.2-0ubuntu1 0
        500 http://archive.ubuntu.com/ubuntu/ trusty/universe amd64 Packages
        100 /var/lib/dpkg/status

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: strongswan-starter 5.1.2-0ubuntu1
ProcVersionSignature: Ubuntu 3.13.0-14.34-generic 3.13.5
Uname: Linux 3.13.0-14-generic x86_64
ApportVersion: 2.13.2-0ubuntu5
Architecture: amd64
CurrentDesktop: Unity
Date: Mon Mar 3 14:43:37 2014
InstallationDate: Installed on 2014-01-26 (35 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140124)
SourcePackage: strongswan
UpgradeStatus: No upgrade log present (probably fresh install)
modified.conffile..etc.ipsec.conf: [modified]
modified.conffile..etc.ipsec.secrets: [inaccessible: [Errno 13] Permission denied: '/etc/ipsec.secrets']
mtime.conffile..etc.ipsec.conf: 2014-03-03T14:34:41.038549

[Jonathan Davies (jpds)]

This is a known issue. Unfortunately, because of the way strongSwan forks, and the way that Upstart handles forks, there is no clean way around this:

- http://upstart.ubuntu.com/cookbook/#how-to-establish-fork-count

[Alberto Salvia Novella (es20490446e)]

It renders essential functionality of the package (or a dependent one) broken.

[Simon Déziel (sdeziel)]

With Strongswan 5.1.2-0ubuntu8 on Ubuntu Xenial, things have improved slightly. systemd will notice if one runs "ipsec stop". Previously, upstart was unable to figure it out and would re-spawn the service.

One problem remains with systemd: If you "ipsec start" while the systemd service is not running, the resulting daemons will not be tracked by systemd.

[Christian Ehrhardt  (paelzer)]

Hi Simon,
I'm working through dormant bugs, and I think this one the chance working on is rather low (as the long time proves).
Also the fact that the "impact" is better since the systemd service makes it less severe.
That said I'm unsubscribing ubuntu-server to let us better focus on the remaining important issues.

[Simon Déziel (sdeziel)]

tl;dr: do not use "ipsec restart" even with systemd.

If the strongswan service is running and one calls "ipsec restart", systemd will lose track of the service:

 # make sure strongswan is running
 sudo service strongswan start

 # restart ipsec the "wrong" way
 sudo ipsec restart

 # notice that systemd saw ipsec stopping but not restarting
 sudo journalctl -o cat -u strongswan | tail
12[CFG] left nor right host is our side, assuming left=local
12[CFG] added configuration 'passthrough-rw'
14[CFG] received stroke: route 'passthrough-rw'
16[CFG] received stroke: add connection 'xelerance-sdeziel'
16[CFG] added configuration 'xelerance-sdeziel'
00[DMN] signal of type SIGINT received. Shutting down
charon stopped after 200 ms
charon stopped after 200 ms
ipsec starter stopped
ipsec starter stopped

 # confirm ipsec is still functioning otherwise
 sudo ipsec status
Shunted Connections:
passthrough-rw: 172.24.27.0/24 192.168.29.6/32 === 172.24.27.0/24 192.168.29.6/32 PASS
Security Associations (0 up, 0 connecting):
  none

 # ask systemd to stop it (unsuccessfully)
 sudo service strongswan stop

 # confirm ipsec is still functioning otherwise
 sudo ipsec status
Shunted Connections:
passthrough-rw: 172.24.27.0/24 192.168.29.6/32 === 172.24.27.0/24 192.168.29.6/32 PASS
Security Associations (0 up, 0 connecting):
  none