Systemd weirdness: Cannot add dependency, file exists

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












2















I have a Debian armel machine running wheezy, upgraded to Debian Testing today. As you can guess from the title, systemd is weird in two ways:



1) On boot, a swath of errors "Cannot add dependency X to Y.target, ignoring: File exists" appears, however the system appears to boot normally. The errors are:



Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency -.mount to local-fs.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-journald.service to sysinit.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency udev.service to basic.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-journald-dev-log.socket to sockets.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency udev-control.socket to sockets.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency udev-kernel.socket to sockets.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-journald.socket to sockets.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-journald-audit.socket to sockets.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-update-utmp-runlevel.service to graphical.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency rsyslog.service to multi-user.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency remote-fs.target to multi-user.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency dbus.service to multi-user.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-user-sessions.service to multi-user.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-update-utmp-runlevel.service to multi-user.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency org.freedesktop.login1.busname to busnames.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency rsyslog.service to multi-user.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency ssh.service to multi-user.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency remote-fs.target to multi-user.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency cron.service to multi-user.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency rc-local.service to multi-user.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency dbus.service to multi-user.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-user-sessions.service to multi-user.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-ask-password-wall.path to multi-user.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-logind.service to multi-user.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency getty.target to multi-user.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-update-utmp-runlevel.service to multi-user.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency rsyslog.service to multi-user.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency ssh.service to multi-user.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency remote-fs.target to multi-user.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency cron.service to multi-user.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency rc-local.service to multi-user.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency dbus.service to multi-user.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-user-sessions.service to multi-user.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-ask-password-wall.path to multi-user.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-logind.service to multi-user.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency getty.target to multi-user.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-update-utmp-runlevel.service to multi-user.target, ignoring: File exists
Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-update-utmp-runlevel.service to rescue.target, ignoring: File exists


2) watchdog is not started any more by default, which causes the HW watchdog, initialized by a bootloader I won't flash without JTAG access, to reset the system. Attempting to enable it with ´systemctl -f enable watchdog` yields this error:



Synchronizing state of watchdog.service with SysV init with /lib/systemd/systemd-sysv-install...
Executing /lib/systemd/systemd-sysv-install enable watchdog
insserv: warning: current start runlevel(s) (2 3 4 5 S) of script `watchdog' overrides LSB defaults (2 3 4 5).
[ 3269.248986] systemd[1]: Cannot add dependency cron.service to multi-user.target, ignoring: File exists
[ 3269.279002] systemd[1]: Cannot add dependency systemd-user-sessions.service to multi-user.target, ignoring: File exists
[ 3269.309118] systemd[1]: Cannot add dependency getty.target to multi-user.target, ignoring: File exists
insserv: warning: current start runlevel(s) (2 3 4 5 S) of script `watchdog' overrides LSB defaults (2 3 4 5).
[ 3273.549003] systemd[1]: Cannot add dependency rc-local.service to multi-user.target, ignoring: File exists
[ 3273.579012] systemd[1]: Cannot add dependency systemd-ask-password-wall.path to multi-user.target, ignoring: File exists
[ 3276.708974] systemd[1]: Cannot add dependency rc-local.service to multi-user.target, ignoring: File exists
[ 3276.738972] systemd[1]: Cannot add dependency systemd-ask-password-wall.path to multi-user.target, ignoring: File exists
[ 3276.768990] systemd[1]: Cannot add dependency systemd-update-utmp-runlevel.service to multi-user.target, ignoring: File exists
The unit files have no [Install] section. They are not meant to be enabled
using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).


3) Apparently something with the RTC is weird, too, because since the upgrade the process root 1 22.3 1.2 6372 3184 ? Ss 18:16 0:15 /sbin/init fixrtc stays launched, despite both RTC and ntpdate working properly.



How do I get rid of all the systemd warnings and make watchdog auto start? A simple service watchdog start works fine, so it is definitely a systemd problem.










share|improve this question













migrated from serverfault.com Oct 20 '15 at 16:51


This question came from our site for system and network administrators.






















    2















    I have a Debian armel machine running wheezy, upgraded to Debian Testing today. As you can guess from the title, systemd is weird in two ways:



    1) On boot, a swath of errors "Cannot add dependency X to Y.target, ignoring: File exists" appears, however the system appears to boot normally. The errors are:



    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency -.mount to local-fs.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-journald.service to sysinit.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency udev.service to basic.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-journald-dev-log.socket to sockets.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency udev-control.socket to sockets.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency udev-kernel.socket to sockets.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-journald.socket to sockets.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-journald-audit.socket to sockets.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-update-utmp-runlevel.service to graphical.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency rsyslog.service to multi-user.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency remote-fs.target to multi-user.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency dbus.service to multi-user.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-user-sessions.service to multi-user.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-update-utmp-runlevel.service to multi-user.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency org.freedesktop.login1.busname to busnames.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency rsyslog.service to multi-user.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency ssh.service to multi-user.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency remote-fs.target to multi-user.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency cron.service to multi-user.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency rc-local.service to multi-user.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency dbus.service to multi-user.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-user-sessions.service to multi-user.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-ask-password-wall.path to multi-user.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-logind.service to multi-user.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency getty.target to multi-user.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-update-utmp-runlevel.service to multi-user.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency rsyslog.service to multi-user.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency ssh.service to multi-user.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency remote-fs.target to multi-user.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency cron.service to multi-user.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency rc-local.service to multi-user.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency dbus.service to multi-user.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-user-sessions.service to multi-user.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-ask-password-wall.path to multi-user.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-logind.service to multi-user.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency getty.target to multi-user.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-update-utmp-runlevel.service to multi-user.target, ignoring: File exists
    Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-update-utmp-runlevel.service to rescue.target, ignoring: File exists


    2) watchdog is not started any more by default, which causes the HW watchdog, initialized by a bootloader I won't flash without JTAG access, to reset the system. Attempting to enable it with ´systemctl -f enable watchdog` yields this error:



    Synchronizing state of watchdog.service with SysV init with /lib/systemd/systemd-sysv-install...
    Executing /lib/systemd/systemd-sysv-install enable watchdog
    insserv: warning: current start runlevel(s) (2 3 4 5 S) of script `watchdog' overrides LSB defaults (2 3 4 5).
    [ 3269.248986] systemd[1]: Cannot add dependency cron.service to multi-user.target, ignoring: File exists
    [ 3269.279002] systemd[1]: Cannot add dependency systemd-user-sessions.service to multi-user.target, ignoring: File exists
    [ 3269.309118] systemd[1]: Cannot add dependency getty.target to multi-user.target, ignoring: File exists
    insserv: warning: current start runlevel(s) (2 3 4 5 S) of script `watchdog' overrides LSB defaults (2 3 4 5).
    [ 3273.549003] systemd[1]: Cannot add dependency rc-local.service to multi-user.target, ignoring: File exists
    [ 3273.579012] systemd[1]: Cannot add dependency systemd-ask-password-wall.path to multi-user.target, ignoring: File exists
    [ 3276.708974] systemd[1]: Cannot add dependency rc-local.service to multi-user.target, ignoring: File exists
    [ 3276.738972] systemd[1]: Cannot add dependency systemd-ask-password-wall.path to multi-user.target, ignoring: File exists
    [ 3276.768990] systemd[1]: Cannot add dependency systemd-update-utmp-runlevel.service to multi-user.target, ignoring: File exists
    The unit files have no [Install] section. They are not meant to be enabled
    using systemctl.
    Possible reasons for having this kind of units are:
    1) A unit may be statically enabled by being symlinked from another unit's
    .wants/ or .requires/ directory.
    2) A unit's purpose may be to act as a helper for some other unit which has
    a requirement dependency on it.
    3) A unit may be started when needed via activation (socket, path, timer,
    D-Bus, udev, scripted systemctl call, ...).


    3) Apparently something with the RTC is weird, too, because since the upgrade the process root 1 22.3 1.2 6372 3184 ? Ss 18:16 0:15 /sbin/init fixrtc stays launched, despite both RTC and ntpdate working properly.



    How do I get rid of all the systemd warnings and make watchdog auto start? A simple service watchdog start works fine, so it is definitely a systemd problem.










    share|improve this question













    migrated from serverfault.com Oct 20 '15 at 16:51


    This question came from our site for system and network administrators.




















      2












      2








      2








      I have a Debian armel machine running wheezy, upgraded to Debian Testing today. As you can guess from the title, systemd is weird in two ways:



      1) On boot, a swath of errors "Cannot add dependency X to Y.target, ignoring: File exists" appears, however the system appears to boot normally. The errors are:



      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency -.mount to local-fs.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-journald.service to sysinit.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency udev.service to basic.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-journald-dev-log.socket to sockets.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency udev-control.socket to sockets.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency udev-kernel.socket to sockets.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-journald.socket to sockets.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-journald-audit.socket to sockets.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-update-utmp-runlevel.service to graphical.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency rsyslog.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency remote-fs.target to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency dbus.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-user-sessions.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-update-utmp-runlevel.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency org.freedesktop.login1.busname to busnames.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency rsyslog.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency ssh.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency remote-fs.target to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency cron.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency rc-local.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency dbus.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-user-sessions.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-ask-password-wall.path to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-logind.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency getty.target to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-update-utmp-runlevel.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency rsyslog.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency ssh.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency remote-fs.target to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency cron.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency rc-local.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency dbus.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-user-sessions.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-ask-password-wall.path to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-logind.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency getty.target to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-update-utmp-runlevel.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-update-utmp-runlevel.service to rescue.target, ignoring: File exists


      2) watchdog is not started any more by default, which causes the HW watchdog, initialized by a bootloader I won't flash without JTAG access, to reset the system. Attempting to enable it with ´systemctl -f enable watchdog` yields this error:



      Synchronizing state of watchdog.service with SysV init with /lib/systemd/systemd-sysv-install...
      Executing /lib/systemd/systemd-sysv-install enable watchdog
      insserv: warning: current start runlevel(s) (2 3 4 5 S) of script `watchdog' overrides LSB defaults (2 3 4 5).
      [ 3269.248986] systemd[1]: Cannot add dependency cron.service to multi-user.target, ignoring: File exists
      [ 3269.279002] systemd[1]: Cannot add dependency systemd-user-sessions.service to multi-user.target, ignoring: File exists
      [ 3269.309118] systemd[1]: Cannot add dependency getty.target to multi-user.target, ignoring: File exists
      insserv: warning: current start runlevel(s) (2 3 4 5 S) of script `watchdog' overrides LSB defaults (2 3 4 5).
      [ 3273.549003] systemd[1]: Cannot add dependency rc-local.service to multi-user.target, ignoring: File exists
      [ 3273.579012] systemd[1]: Cannot add dependency systemd-ask-password-wall.path to multi-user.target, ignoring: File exists
      [ 3276.708974] systemd[1]: Cannot add dependency rc-local.service to multi-user.target, ignoring: File exists
      [ 3276.738972] systemd[1]: Cannot add dependency systemd-ask-password-wall.path to multi-user.target, ignoring: File exists
      [ 3276.768990] systemd[1]: Cannot add dependency systemd-update-utmp-runlevel.service to multi-user.target, ignoring: File exists
      The unit files have no [Install] section. They are not meant to be enabled
      using systemctl.
      Possible reasons for having this kind of units are:
      1) A unit may be statically enabled by being symlinked from another unit's
      .wants/ or .requires/ directory.
      2) A unit's purpose may be to act as a helper for some other unit which has
      a requirement dependency on it.
      3) A unit may be started when needed via activation (socket, path, timer,
      D-Bus, udev, scripted systemctl call, ...).


      3) Apparently something with the RTC is weird, too, because since the upgrade the process root 1 22.3 1.2 6372 3184 ? Ss 18:16 0:15 /sbin/init fixrtc stays launched, despite both RTC and ntpdate working properly.



      How do I get rid of all the systemd warnings and make watchdog auto start? A simple service watchdog start works fine, so it is definitely a systemd problem.










      share|improve this question














      I have a Debian armel machine running wheezy, upgraded to Debian Testing today. As you can guess from the title, systemd is weird in two ways:



      1) On boot, a swath of errors "Cannot add dependency X to Y.target, ignoring: File exists" appears, however the system appears to boot normally. The errors are:



      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency -.mount to local-fs.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-journald.service to sysinit.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency udev.service to basic.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-journald-dev-log.socket to sockets.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency udev-control.socket to sockets.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency udev-kernel.socket to sockets.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-journald.socket to sockets.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-journald-audit.socket to sockets.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-update-utmp-runlevel.service to graphical.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency rsyslog.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency remote-fs.target to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency dbus.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-user-sessions.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-update-utmp-runlevel.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency org.freedesktop.login1.busname to busnames.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency rsyslog.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency ssh.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency remote-fs.target to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency cron.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency rc-local.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency dbus.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-user-sessions.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-ask-password-wall.path to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-logind.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency getty.target to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-update-utmp-runlevel.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency rsyslog.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency ssh.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency remote-fs.target to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency cron.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency rc-local.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency dbus.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-user-sessions.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-ask-password-wall.path to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-logind.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency getty.target to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-update-utmp-runlevel.service to multi-user.target, ignoring: File exists
      Oct 20 17:19:42 gw-16b1 systemd[1]: Cannot add dependency systemd-update-utmp-runlevel.service to rescue.target, ignoring: File exists


      2) watchdog is not started any more by default, which causes the HW watchdog, initialized by a bootloader I won't flash without JTAG access, to reset the system. Attempting to enable it with ´systemctl -f enable watchdog` yields this error:



      Synchronizing state of watchdog.service with SysV init with /lib/systemd/systemd-sysv-install...
      Executing /lib/systemd/systemd-sysv-install enable watchdog
      insserv: warning: current start runlevel(s) (2 3 4 5 S) of script `watchdog' overrides LSB defaults (2 3 4 5).
      [ 3269.248986] systemd[1]: Cannot add dependency cron.service to multi-user.target, ignoring: File exists
      [ 3269.279002] systemd[1]: Cannot add dependency systemd-user-sessions.service to multi-user.target, ignoring: File exists
      [ 3269.309118] systemd[1]: Cannot add dependency getty.target to multi-user.target, ignoring: File exists
      insserv: warning: current start runlevel(s) (2 3 4 5 S) of script `watchdog' overrides LSB defaults (2 3 4 5).
      [ 3273.549003] systemd[1]: Cannot add dependency rc-local.service to multi-user.target, ignoring: File exists
      [ 3273.579012] systemd[1]: Cannot add dependency systemd-ask-password-wall.path to multi-user.target, ignoring: File exists
      [ 3276.708974] systemd[1]: Cannot add dependency rc-local.service to multi-user.target, ignoring: File exists
      [ 3276.738972] systemd[1]: Cannot add dependency systemd-ask-password-wall.path to multi-user.target, ignoring: File exists
      [ 3276.768990] systemd[1]: Cannot add dependency systemd-update-utmp-runlevel.service to multi-user.target, ignoring: File exists
      The unit files have no [Install] section. They are not meant to be enabled
      using systemctl.
      Possible reasons for having this kind of units are:
      1) A unit may be statically enabled by being symlinked from another unit's
      .wants/ or .requires/ directory.
      2) A unit's purpose may be to act as a helper for some other unit which has
      a requirement dependency on it.
      3) A unit may be started when needed via activation (socket, path, timer,
      D-Bus, udev, scripted systemctl call, ...).


      3) Apparently something with the RTC is weird, too, because since the upgrade the process root 1 22.3 1.2 6372 3184 ? Ss 18:16 0:15 /sbin/init fixrtc stays launched, despite both RTC and ntpdate working properly.



      How do I get rid of all the systemd warnings and make watchdog auto start? A simple service watchdog start works fine, so it is definitely a systemd problem.







      debian systemd






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Oct 20 '15 at 16:19









      user1933738user1933738

      16317




      16317




      migrated from serverfault.com Oct 20 '15 at 16:51


      This question came from our site for system and network administrators.









      migrated from serverfault.com Oct 20 '15 at 16:51


      This question came from our site for system and network administrators.






















          1 Answer
          1






          active

          oldest

          votes


















          0














          It means the systemd service files for all of listed tools/packages are missing. You need to find toolname.dervice file and place it into /lib/systemd/system.



          In poor words, your systemd service commands are not going to work for the tools that the systems warns during the boot. I suggest you to backup your data and perform a clean install since upgrade messed up.






          share|improve this answer























          • Nope, the files exist (e.g. -rw-r--r-- 1 root root 251 May 14 09:44 /lib/systemd/system/cron.service)...

            – user1933738
            Oct 21 '15 at 7:46











          • yes, the files are there but they are symlinked, as your logs suggest as well sysmlinks may be messed. That is why I said you need to find them and place them correctly. Doing a distro upgrade from stable to testing is never been recommended so I am not surprised at all that this happened. you should be aware of the risks. Go for clean install.

            – ostendali
            Oct 21 '15 at 10:14










          Your Answer








          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "106"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader:
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          ,
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );













          draft saved

          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f237446%2fsystemd-weirdness-cannot-add-dependency-file-exists%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          0














          It means the systemd service files for all of listed tools/packages are missing. You need to find toolname.dervice file and place it into /lib/systemd/system.



          In poor words, your systemd service commands are not going to work for the tools that the systems warns during the boot. I suggest you to backup your data and perform a clean install since upgrade messed up.






          share|improve this answer























          • Nope, the files exist (e.g. -rw-r--r-- 1 root root 251 May 14 09:44 /lib/systemd/system/cron.service)...

            – user1933738
            Oct 21 '15 at 7:46











          • yes, the files are there but they are symlinked, as your logs suggest as well sysmlinks may be messed. That is why I said you need to find them and place them correctly. Doing a distro upgrade from stable to testing is never been recommended so I am not surprised at all that this happened. you should be aware of the risks. Go for clean install.

            – ostendali
            Oct 21 '15 at 10:14















          0














          It means the systemd service files for all of listed tools/packages are missing. You need to find toolname.dervice file and place it into /lib/systemd/system.



          In poor words, your systemd service commands are not going to work for the tools that the systems warns during the boot. I suggest you to backup your data and perform a clean install since upgrade messed up.






          share|improve this answer























          • Nope, the files exist (e.g. -rw-r--r-- 1 root root 251 May 14 09:44 /lib/systemd/system/cron.service)...

            – user1933738
            Oct 21 '15 at 7:46











          • yes, the files are there but they are symlinked, as your logs suggest as well sysmlinks may be messed. That is why I said you need to find them and place them correctly. Doing a distro upgrade from stable to testing is never been recommended so I am not surprised at all that this happened. you should be aware of the risks. Go for clean install.

            – ostendali
            Oct 21 '15 at 10:14













          0












          0








          0







          It means the systemd service files for all of listed tools/packages are missing. You need to find toolname.dervice file and place it into /lib/systemd/system.



          In poor words, your systemd service commands are not going to work for the tools that the systems warns during the boot. I suggest you to backup your data and perform a clean install since upgrade messed up.






          share|improve this answer













          It means the systemd service files for all of listed tools/packages are missing. You need to find toolname.dervice file and place it into /lib/systemd/system.



          In poor words, your systemd service commands are not going to work for the tools that the systems warns during the boot. I suggest you to backup your data and perform a clean install since upgrade messed up.







          share|improve this answer












          share|improve this answer



          share|improve this answer










          answered Oct 20 '15 at 16:46









          ostendaliostendali

          1495




          1495












          • Nope, the files exist (e.g. -rw-r--r-- 1 root root 251 May 14 09:44 /lib/systemd/system/cron.service)...

            – user1933738
            Oct 21 '15 at 7:46











          • yes, the files are there but they are symlinked, as your logs suggest as well sysmlinks may be messed. That is why I said you need to find them and place them correctly. Doing a distro upgrade from stable to testing is never been recommended so I am not surprised at all that this happened. you should be aware of the risks. Go for clean install.

            – ostendali
            Oct 21 '15 at 10:14

















          • Nope, the files exist (e.g. -rw-r--r-- 1 root root 251 May 14 09:44 /lib/systemd/system/cron.service)...

            – user1933738
            Oct 21 '15 at 7:46











          • yes, the files are there but they are symlinked, as your logs suggest as well sysmlinks may be messed. That is why I said you need to find them and place them correctly. Doing a distro upgrade from stable to testing is never been recommended so I am not surprised at all that this happened. you should be aware of the risks. Go for clean install.

            – ostendali
            Oct 21 '15 at 10:14
















          Nope, the files exist (e.g. -rw-r--r-- 1 root root 251 May 14 09:44 /lib/systemd/system/cron.service)...

          – user1933738
          Oct 21 '15 at 7:46





          Nope, the files exist (e.g. -rw-r--r-- 1 root root 251 May 14 09:44 /lib/systemd/system/cron.service)...

          – user1933738
          Oct 21 '15 at 7:46













          yes, the files are there but they are symlinked, as your logs suggest as well sysmlinks may be messed. That is why I said you need to find them and place them correctly. Doing a distro upgrade from stable to testing is never been recommended so I am not surprised at all that this happened. you should be aware of the risks. Go for clean install.

          – ostendali
          Oct 21 '15 at 10:14





          yes, the files are there but they are symlinked, as your logs suggest as well sysmlinks may be messed. That is why I said you need to find them and place them correctly. Doing a distro upgrade from stable to testing is never been recommended so I am not surprised at all that this happened. you should be aware of the risks. Go for clean install.

          – ostendali
          Oct 21 '15 at 10:14

















          draft saved

          draft discarded
















































          Thanks for contributing an answer to Unix & Linux Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid


          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.

          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f237446%2fsystemd-weirdness-cannot-add-dependency-file-exists%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown






          Popular posts from this blog

          How to check contact read email or not when send email to Individual?

          Displaying single band from multi-band raster using QGIS

          How many registers does an x86_64 CPU actually have?