Ubuntu
ipsec-tools package

setkey is not run automatically on system start

Bug #1574833 reported by MegaBrutal
40
This bug affects 6 people
Affects Status Importance Assigned to Milestone
ipsec-tools (Ubuntu)
Triaged
Critical
Unassigned

Bug Description

The „setkey” service should run at system startup to add keys defined in /etc/ipsec-tools.conf.

However, no keys are defined after system boot:

root@ReThinkCentre:~# setkey -D
No SAD entries.

After inquiring systemd, I learn this:

root@ReThinkCentre:~# systemctl status setkey
● setkey.service - LSB: option to manually manipulate the IPsec SA/SP database
   Loaded: loaded (/etc/init.d/setkey; bad; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:systemd-sysv-generator(8)

ápr 25 21:15:28 ReThinkCentre systemd[1]: setkey.service: Job setkey.service/start deleted to break ordering cycle starting with sysinit.target/start

Upon manually calling „systemctl start setkey” after the system booted up, the keys are added properly – but it is not feasible to do after each reboot.

Moreover, I can't help to notice that /etc/init.d/setkey is a legacy SysV init script. No proper systemd service file seems to exist for setkey. I think it would be a great time to add one.

Tags: wily xenial
MegaBrutal (qbu6to)
tags: added: wily xenial
Martin Pitt (pitti)
no longer affects: systemd (Ubuntu)
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ipsec-tools (Ubuntu):
status: New → Confirmed
Alberto Salvia Novella (es20490446e)
Changed in ipsec-tools (Ubuntu):
importance: Undecided → Medium
Revision history for this message
Andy (andyrcook) wrote :

Hello,

I there any workaround for this issue?

Revision history for this message
Andy (andyrcook) wrote :

To answer my own question, I created a dirty fix by creating a new systemd service that just calls systemctl start setkey.

Revision history for this message
Steve Langasek (vorlon) wrote :

This problem is caused by ipsec-tools's /etc/init.d/setkey having a header that declares both runlevel S and a dependency on $remote_fs, which causes a dependency loop:

[ 23.730602] systemd[1]: basic.target: Found ordering cycle on basic.target/start
[ 23.730606] systemd[1]: basic.target: Found dependency on paths.target/start
[ 23.730607] systemd[1]: basic.target: Found dependency on acpid.path/start
[ 23.730609] systemd[1]: basic.target: Found dependency on sysinit.target/start
[ 23.730610] systemd[1]: basic.target: Found dependency on setkey.service/start
[ 23.730612] systemd[1]: basic.target: Found dependency on remote-fs.target/start
[ 23.730613] systemd[1]: basic.target: Found dependency on remote-fs-pre.target/start
[ 23.730614] systemd[1]: basic.target: Found dependency on open-iscsi.service/start
[ 23.730616] systemd[1]: basic.target: Found dependency on network-online.target/start
[ 23.730617] systemd[1]: basic.target: Found dependency on network.target/start
[ 23.730619] systemd[1]: basic.target: Found dependency on NetworkManager.service/start
[ 23.730620] systemd[1]: basic.target: Found dependency on basic.target/start
[ 23.730622] systemd[1]: basic.target: Breaking ordering cycle by deleting job paths.target/start

(With several other loops to follow)

In 16.04 and later, packages should not use init scripts with runlevel S, but instead should ship native systemd units to avoid such dependency problems.

Changed in ipsec-tools (Ubuntu):
importance: Medium → Critical
status: Confirmed → Triaged
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.