enabled systemd unit does not start at boot

Question

I’ve a systemd-unit on my system that is enabled. The problem is, it doesn't restart after a reboot. It depends on two other services that are both started as expected.

The service is known, enabled and dead:

[centos@ansible-kube-4 ~]$ sudo systemctl status flanneld
flanneld.service - Flanneld overlay address etcd agent
   Loaded: loaded (/usr/lib/systemd/system/flanneld.service; enabled)
   Active: inactive (dead)

The unit file:

[centos@ansible-kube-4 ~]$ cat /usr/lib/systemd/system/flanneld.service
[Unit]
Description=Flanneld overlay address etcd agent
After=network.target
After=etcd.service

[Service]
Type=notify
Restart=always
RestartSec=3

EnvironmentFile=/etc/sysconfig/flanneld
EnvironmentFile=-/etc/sysconfig/docker-network
ExecStart=/usr/bin/flanneld -etcd-endpoints=${FLANNEL_ETCD} -etcd-prefix=${FLANNEL_ETCD_KEY} $FLANNEL_OPTIONS
ExecStartPost=/usr/libexec/flannel/mk-docker-opts.sh -k DOCKER_NETWORK_OPTIONS -d /run/flannel/docker

[Install]
WantedBy=multi-user.target

Update 1

Output of dmesg:

$ dmesg | grep systemd
[    1.312165] systemd[1]: systemd 208 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ)
[    1.317238] systemd[1]: Detected virtualization 'kvm'.
[    1.319597] systemd[1]: Running in initial RAM disk.
[    1.323489] systemd[1]: No hostname configured.
[    1.324874] systemd[1]: Set hostname to <localhost>.
[    1.327570] systemd[1]: Initializing machine ID from KVM UUID.
[    1.389047] systemd[1]: Expecting device dev-disk-by\x2duuid-a78bb152\x2de525\x2d4f0e\x2d961a\x2dbf6147ac7d3e.device...
[    1.394577] systemd[1]: Starting -.slice.
[    1.396820] systemd[1]: Created slice -.slice.
[    1.397990] systemd[1]: Starting System Slice.
[    1.400212] systemd[1]: Created slice System Slice.
[    1.401503] systemd[1]: Starting Slices.
[    1.403556] systemd[1]: Reached target Slices.
[    1.404756] systemd[1]: Starting Timers.
[    1.406834] systemd[1]: Reached target Timers.
[    1.408042] systemd[1]: Starting Dispatch Password Requests to Console Directory Watch.
[    1.410065] systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
[    1.413402] systemd[1]: Starting Paths.
[    1.415399] systemd[1]: Reached target Paths.
[    1.416574] systemd[1]: Starting Journal Socket.
[    1.418894] systemd[1]: Listening on Journal Socket.
[    1.420242] systemd[1]: Started dracut ask for additional cmdline parameters.
[    1.422150] systemd[1]: Starting dracut cmdline hook...
[    1.424870] systemd[1]: Started Load Kernel Modules.
[    1.426124] systemd[1]: Starting Journal Service...
[    1.429731] systemd[1]: Started Journal Service.
[    1.692884] systemd-udevd[213]: starting version 208
[    2.621300] systemd-journald[90]: Received SIGTERM
[    2.968711] systemd[1]: Successfully loaded SELinux policy in 274.569ms.
[    3.023076] systemd[1]: Relabelled /dev and /run in 20.031ms.
[    3.365195] systemd-udevd[382]: starting version 208
[    3.482910] systemd-journald[377]: Received request to flush runtime journal from PID 1

Update 2

Output of chkconfig:

sudo chkconfig

Note: This output shows SysV services only and does not include native
      systemd services. SysV configuration data might be overridden by native
      systemd configuration.

      If you want to list systemd services use 'systemctl list-unit-files'.
      To see services enabled on particular target use
      'systemctl list-dependencies [target]'.

netconsole      0:off   1:off   2:off   3:off   4:off   5:off   6:off
network         0:off   1:off   2:on    3:on    4:on    5:on    6:off

Output of systemctl list-dependencies flanneld:

flanneld.service
├─system.slice
└─basic.target
  ├─microcode.service
  ├─rhel-autorelabel-mark.service
  ├─rhel-autorelabel.service
  ├─rhel-configure.service
  ├─rhel-dmesg.service
  ├─rhel-loadmodules.service
  ├─paths.target
  ├─slices.target
  │ ├─-.slice
  │ └─system.slice
  ├─sockets.target
  │ ├─dbus.socket
  │ ├─rpcbind.socket
  │ ├─systemd-initctl.socket
  │ ├─systemd-journald.socket
  │ ├─systemd-shutdownd.socket
  │ ├─systemd-udevd-control.socket
  │ └─systemd-udevd-kernel.socket
  ├─sysinit.target
  │ ├─dev-hugepages.mount
  │ ├─dev-mqueue.mount
  │ ├─kmod-static-nodes.service
  │ ├─proc-sys-fs-binfmt_misc.automount
  │ ├─sys-fs-fuse-connections.mount
  │ ├─sys-kernel-config.mount
  │ ├─sys-kernel-debug.mount
  │ ├─systemd-ask-password-console.path
  │ ├─systemd-binfmt.service
  │ ├─systemd-journal-flush.service
  │ ├─systemd-journald.service
  │ ├─systemd-modules-load.service
  │ ├─systemd-random-seed.service
  │ ├─systemd-sysctl.service
  │ ├─systemd-tmpfiles-setup-dev.service
  │ ├─systemd-tmpfiles-setup.service
  │ ├─systemd-udev-trigger.service
  │ ├─systemd-udevd.service
  │ ├─systemd-update-utmp.service
  │ ├─systemd-vconsole-setup.service
  │ ├─cryptsetup.target
  │ ├─local-fs.target
  │ │ ├─-.mount
  │ │ ├─rhel-import-state.service
  │ │ ├─rhel-readonly.service
  │ │ ├─systemd-fsck-root.service
  │ │ └─systemd-remount-fs.service
  │ └─swap.target
  └─timers.target
    └─systemd-tmpfiles-clean.timer

score 33 · Accepted Answer · answered Sep 16 '15 at 11:21

33

The unit file was modified:

Before:

[Install]
RequiredBy=docker.service

After:

[Install]
WantedBy=multi-user.target

After that modification I did not reenable the Unit. Turned out that this is needed for systemd to reconfigure:

$ sudo systemctl reenable flanneld
rm '/etc/systemd/system/docker.service.requires/flanneld.service'
ln -s '/usr/lib/systemd/system/flanneld.service' '/etc/systemd/system/multi-user.target.wants/flanneld.service'

answered Sep 16 '15 at 11:21

maklemenz

741
1
6
10

2

I too found that this helped and I don't know why. Perhaps `reenable` corrected something I hadn't done or had botched and couldn't see because I wasn't squinting hard enough. Anyway, of two identical hosts on which I was configuring to make my service come up after reboot, one worked and the other did not until I did this to it. – Russ Bateman Jan 02 '18 at 19:38
1

Is it possible it got disabled by an upgrade? I had one suspicious server where it was disabled after an upgrade... **sudo systemctl reenable rails-puma.service** solved the issue – Dave Collins Apr 05 '18 at 11:43
1

maybe relevant: https://unix.stackexchange.com/questions/193714/generic-methodology-to-debug-ordering-cycles-in-systemd – ThorSummoner Feb 08 '19 at 19:10

score 9 · Answer 2 · edited Sep 06 '15 at 18:14

9

I find no evidence in your configuration that this service should be started at boot time. systemd allows two ways of enabling a service so it is started at boot time:

chkconfig flanneld on

Or:

systemctl enable flanneld

In fact, the first is a legacy way of calling the second one, and I'm not sure if the chkconfig package is installed by default, but you can install it using apt-get or yum.

edited Sep 06 '15 at 18:14

Giacomo1968

53,069
19
162
212

answered Aug 31 '15 at 19:07

nKn

5,549
6
32
38

1

The service is enabled. I used `sudo systemctl enable flanneld` to enable it. – maklemenz Sep 01 '15 at 07:17
After running it it still doesn't get started at startup? – nKn Sep 01 '15 at 07:23
I have to start the service manually after each reboot. It starts on first try and without any error messages or warnings. – maklemenz Sep 01 '15 at 07:54
1

There must be something else failing. Officially, the way to enable a service on startup in systemd is `systemctl enable servicename`. Most examples also include the `.service` termination in the command, but I'm not sure this should do any difference. – nKn Sep 01 '15 at 08:02
The .service suffix is automatically added when it is omitted by the user. – mrg2k8 Sep 01 '15 at 12:24
I would do a `dmesg` or `journalctl -xn`, or at least press a key during boot to see if there's some sort of output. – mrg2k8 Sep 01 '15 at 12:44
@mrg2k8 I've added the output of dmesg. journalctl doesn't tell me anything related to this service. The machine is virtualized using OpenStack. I can't press the keys during boot. – maklemenz Sep 01 '15 at 14:10
What is the output for `chkconfig | grep flanneld`? – nKn Sep 01 '15 at 20:41
@nKn The output of chkconfig is useless. I added it anyway together with the output of `systemctl list-dependencies flanneld` – maklemenz Sep 02 '15 at 08:19

score 0 · Answer 3 · edited Dec 09 '20 at 14:18

0

I had the same problem as described. In my case, with Ubuntu 19.10.

The problem was (I think) a bug in systemctl enable <service>. It created a symlink in:

/etc/systemd/system/mutli-user.target.wants

instead of:

/etc/systemd/system/multi-user.target.wants

Simply copying the link to the correct location solved my problem.

edited Dec 09 '20 at 14:18

Stephen Rauch

3,091
10
23
26

answered Dec 09 '20 at 13:46

Harald Weyrich

1

enabled systemd unit does not start at boot

3 Answers3