la unidad systemd habilitada no se inicia en el arranque

35

Tengo un systemd-uniten mi sistema que está habilitado. El problema es que no se reinicia después de un reinicio. Depende de otros dos servicios que se inician como se esperaba.

El servicio es conocido, habilitado y muerto:

[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)

El archivo de la unidad:

[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

Actualización 1

Salida de 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

Actualización 2

Salida de 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

Salida de 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
maklemenz
fuente

Respuestas:

32

El archivo de la unidad fue modificado:

Antes de:

[Install]
RequiredBy=docker.service

Después:

[Install]
WantedBy=multi-user.target

Después de esa modificación, no volví a habilitar la Unidad. Resultó que esto es necesario para que systemd 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'
maklemenz
fuente
2
También encontré que esto ayudó y no sé por qué. Tal vez reenablecorrigió algo que no había hecho o que había fallado y que no podía ver porque no estaba entrecerrando los ojos lo suficiente. De todos modos, de dos hosts idénticos en los que estaba configurando para que mi servicio apareciera después del reinicio, uno funcionó y el otro no hasta que le hice esto.
Russ Bateman el
1
¿Es posible que haya sido deshabilitado por una actualización? Tuve un servidor sospechoso donde se desactivó después de una actualización ... sudo systemctl reenable rails-puma.service resolvió el problema
Dave Collins
1
tal vez relevante: unix.stackexchange.com/questions/193714/…
ThorSummoner
9

No encuentro evidencia en su configuración de que este servicio deba iniciarse en el momento del arranque. systemdpermite dos formas de habilitar un servicio para que se inicie en el momento del arranque:

chkconfig flanneld on

O:

systemctl enable flanneld

De hecho, la primera es una forma heredada de llamar a la segunda, y no estoy seguro de si el chkconfigpaquete está instalado de manera predeterminada, pero puede instalarlo usando apt-geto yum.

nKn
fuente
El servicio está habilitado. Solía sudo systemctl enable flanneldhabilitarlo.
maklemenz
Después de ejecutarlo, ¿todavía no comienza al inicio?
nKn
Tengo que iniciar el servicio manualmente después de cada reinicio. Comienza en el primer intento y sin ningún mensaje de error o advertencia.
maklemenz
1
Debe haber algo más fallando. Oficialmente, la forma de habilitar un servicio al inicio en systemd es systemctl enable servicename. La mayoría de los ejemplos también incluyen la .serviceterminación en el comando, pero no estoy seguro de que esto haga alguna diferencia.
nKn
El sufijo .service se agrega automáticamente cuando el usuario lo omite.
mrg2k8