Skip to content
This repository has been archived by the owner on Oct 16, 2020. It is now read-only.

Ignition silently fails to enable a nonexistent unit #2243

Closed
bgilbert opened this issue Nov 10, 2017 · 1 comment
Closed

Ignition silently fails to enable a nonexistent unit #2243

bgilbert opened this issue Nov 10, 2017 · 1 comment

Comments

@bgilbert
Copy link
Contributor

Issue Report

Bug

Container Linux Version

$ cat /etc/os-release
NAME="Container Linux by CoreOS"
ID=coreos
VERSION=1590.0.0
VERSION_ID=1590.0.0
BUILD_ID=2017-11-08-0831
PRETTY_NAME="Container Linux by CoreOS 1590.0.0 (Ladybug)"
ANSI_COLOR="38;5;75"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://issues.coreos.com"
COREOS_BOARD="amd64-usr"

Environment

Any

Expected Behavior

If Ignition is asked to enable a nonexistent unit, it fails the boot.

Actual Behavior

Ignition claims to have enabled the unit, but nothing happens.

Reproduction Steps

  1. Boot the following CLC:
systemd:
  units:
    - name: blargh.service
      enabled: true
  1. Check journalctl -t ignition and systemctl status.

Other Information

This happens because Ignition configures systemd units via presets, and presets are allowed to reference nonexistent units.

journalctl says:

Nov 10 01:19:32 localhost ignition[439]: files: op(8): [started]  processing unit "blargh.service"
Nov 10 01:19:32 localhost ignition[439]: files: op(8): [finished] processing unit "blargh.service"
Nov 10 01:19:32 localhost ignition[439]: files: op(9): [started]  enabling unit "blargh.service"
Nov 10 01:19:32 localhost ignition[439]: files: op(9): [finished] enabling unit "blargh.service"
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants