setkey is not run automatically on system start

Bug #1574833 reported by MegaBrutal on 2016-04-25
34
This bug affects 5 people
Affects Status Importance Assigned to Milestone
ipsec-tools (Ubuntu)
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.

MegaBrutal (qbu6to) on 2016-04-25
tags: added: wily xenial
Martin Pitt (pitti) on 2016-04-26
no longer affects: systemd (Ubuntu)
Launchpad Janitor (janitor) wrote :

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

Changed in ipsec-tools (Ubuntu):
status: New → Confirmed
Changed in ipsec-tools (Ubuntu):
importance: Undecided → Medium
Andy (andyrcook) wrote :

Hello,

I there any workaround for this issue?

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.

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  Edit
Everyone can see this information.

Other bug subscribers

Related questions