Bug#768168: watchdog does not start at boot
On Nov 11, Michael Biebl wrote: Please boot with systemd.log_level=debug on the kernel command line, the attach the output of journalctl -alb I guess these are the relevant lines: Found ordering cycle on graphical.target/start Found dependency on multi-user.target/start Found dependency on watchdog.service/start Found dependency on graphical.target/start Breaking ordering cycle by deleting job watchdog.service/start The part of the journal after hardware initialization is attached. Regards Uwe Nov 12 14:02:21 grappa kernel: EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) Nov 12 14:02:21 grappa systemd[1]: Mounting cgroup to /sys/fs/cgroup/cpuset of type cgroup with options cpuset. Nov 12 14:02:21 grappa systemd[1]: Mounting cgroup to /sys/fs/cgroup/cpu,cpuacct of type cgroup with options cpu,cpuacct. Nov 12 14:02:21 grappa systemd[1]: Mounting cgroup to /sys/fs/cgroup/devices of type cgroup with options devices. Nov 12 14:02:21 grappa systemd[1]: Mounting cgroup to /sys/fs/cgroup/freezer of type cgroup with options freezer. Nov 12 14:02:21 grappa systemd[1]: Mounting cgroup to /sys/fs/cgroup/net_cls,net_prio of type cgroup with options net_cls,net_prio. Nov 12 14:02:21 grappa systemd[1]: Mounting cgroup to /sys/fs/cgroup/blkio of type cgroup with options blkio. Nov 12 14:02:21 grappa systemd[1]: Mounting cgroup to /sys/fs/cgroup/perf_event of type cgroup with options perf_event. Nov 12 14:02:21 grappa systemd[1]: systemd 215 running in system mode. (+PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP -APPARMOR) Nov 12 14:02:21 grappa systemd[1]: Detected architecture 'x86-64'. Nov 12 14:02:21 grappa systemd[1]: Your kernel apparently lacks built-in autofs4 support. Might be a good idea to compile it in. We'll now try to work around this by loading the module... Nov 12 14:02:21 grappa kernel: Switched to clocksource tsc Nov 12 14:02:21 grappa systemd[1]: Inserted module 'autofs4' Nov 12 14:02:21 grappa systemd[1]: Set hostname to grappa. Nov 12 14:02:21 grappa systemd[1]: /usr appears to be on its own filesytem and is not already mounted. This is not a supported setup. Some things will probably break (sometimes even silently) in mysterious ways. Consult http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken for more information. Nov 12 14:02:21 grappa systemd[1]: Using cgroup controller name=systemd. File system hierarchy is at /sys/fs/cgroup/systemd. Nov 12 14:02:21 grappa systemd[1]: Installed release agent. Nov 12 14:02:21 grappa systemd[1]: Set up TFD_TIMER_CANCEL_ON_SET timerfd. Nov 12 14:02:21 grappa systemd[145]: Spawned /lib/systemd/system-generators/systemd-sysv-generator as 146. Nov 12 14:02:21 grappa systemd[145]: Spawned /lib/systemd/system-generators/systemd-cryptsetup-generator as 147. Nov 12 14:02:21 grappa systemd[145]: Spawned /lib/systemd/system-generators/systemd-insserv-generator as 148. Nov 12 14:02:21 grappa systemd[145]: Spawned /lib/systemd/system-generators/systemd-getty-generator as 149. Nov 12 14:02:21 grappa systemd[145]: Spawned /lib/systemd/system-generators/systemd-rc-local-generator as 150. Nov 12 14:02:21 grappa systemd[145]: Spawned /lib/systemd/system-generators/systemd-fstab-generator as 151. Nov 12 14:02:21 grappa systemd[145]: Spawned /lib/systemd/system-generators/systemd-gpt-auto-generator as 152. Nov 12 14:02:21 grappa systemd[145]: Spawned /lib/systemd/system-generators/systemd-system-update-generator as 153. Nov 12 14:02:21 grappa systemd[145]: Spawned /lib/systemd/system-generators/systemd-debug-generator as 154. Nov 12 14:02:21 grappa kernel: random: nonblocking pool is initialized Nov 12 14:02:21 grappa systemd[145]: /lib/systemd/system-generators/systemd-sysv-generator succeeded. Nov 12 14:02:21 grappa systemd[145]: /lib/systemd/system-generators/systemd-cryptsetup-generator succeeded. Nov 12 14:02:21 grappa systemd[145]: /lib/systemd/system-generators/systemd-insserv-generator succeeded. Nov 12 14:02:21 grappa systemd[145]: /lib/systemd/system-generators/systemd-getty-generator succeeded. Nov 12 14:02:21 grappa systemd[145]: /lib/systemd/system-generators/systemd-rc-local-generator succeeded. Nov 12 14:02:21 grappa systemd[145]: /lib/systemd/system-generators/systemd-fstab-generator succeeded. Nov 12 14:02:21 grappa systemd[145]: /lib/systemd/system-generators/systemd-gpt-auto-generator succeeded. Nov 12 14:02:21 grappa systemd[145]: /lib/systemd/system-generators/systemd-system-update-generator succeeded. Nov 12 14:02:21 grappa systemd[145]: /lib/systemd/system-generators/systemd-debug-generator succeeded. Nov 12 14:02:21 grappa systemd[1]: /lib/systemd/system-generators succeeded. Nov 12 14:02:21 grappa systemd[1]: Looking for unit files in (higher priority first): Nov 12 14:02:21 grappa systemd[1]: /etc/systemd/system Nov 12 14:02:21 grappa systemd[1]: /run/systemd/system Nov 12 14:02:21 grappa systemd[1]: /run/systemd/generator
Bug#768168: watchdog does not start at boot
Am 12.11.2014 um 14:29 schrieb Uwe Storbeck:
On Nov 11, Michael Biebl wrote:
Please boot with systemd.log_level=debug on the kernel command line, the
attach the output of journalctl -alb
I guess these are the relevant lines:
Found ordering cycle on graphical.target/start
Found dependency on multi-user.target/start
Found dependency on watchdog.service/start
Found dependency on graphical.target/start
Breaking ordering cycle by deleting job watchdog.service/start
The part of the journal after hardware initialization is attached.
Yeah, it shows that watchdog.service is involved in dependency cycle and
systemd therefore removes it from the transaction.
Here's the service file:
[Unit]
Description=watchdog daemon
After=systemd-update-utmp.service
Since the service uses DefaultDependencies=yes (the default), this
explicit after is not necessary.
After=runlevel1.target runlevel2.target runlevel3.target runlevel4.target
runlevel5.target
I don't think this does and please don't use that in a service file. We
don't really want to drag that legacy concept of SysV runlevels into
native .service files.
[Service]
Type=forking
EnvironmentFile=/etc/default/watchdog
ExecStartPre=/bin/sh -c '[ -z ${watchdog_module} ] || [
${watchdog_module} = none ] || echo /sbin/modprobe $watchdog_module'
Couldn't you just run ExecStartPre=-/sbin/modprobe $watchdog_module?
The - would ignore any errors
ExecStartPre=/bin/systemctl stop wd_keepalive
Calling systemctl from service files is highly discouraged, I'd go as
far as say forbidden unless you know exactly what you're doing.
Can you elaborate why this is necessary?
ExecStart=/usr/sbin/watchdog $watchdog_options
ExecStopPost=/bin/systemctl start wd_keepalive
Same here. Does that mean, on shutdown, when all services are about to
be stopped, you start wd_keepalive? Why?
[Install]
WantedBy=multi-user.target
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
Bug#768168: watchdog does not start at boot
Am 12.11.2014 um 14:44 schrieb Michael Biebl:
Am 12.11.2014 um 14:29 schrieb Uwe Storbeck:
On Nov 11, Michael Biebl wrote:
Please boot with systemd.log_level=debug on the kernel command line, the
attach the output of journalctl -alb
I guess these are the relevant lines:
Found ordering cycle on graphical.target/start
Found dependency on multi-user.target/start
Found dependency on watchdog.service/start
Found dependency on graphical.target/start
Breaking ordering cycle by deleting job watchdog.service/start
The part of the journal after hardware initialization is attached.
Yeah, it shows that watchdog.service is involved in dependency cycle and
systemd therefore removes it from the transaction.
Here's the service file:
[Unit]
Description=watchdog daemon
After=systemd-update-utmp.service
Since the service uses DefaultDependencies=yes (the default), this
explicit after is not necessary.
After=runlevel1.target runlevel2.target runlevel3.target runlevel4.target
runlevel5.target
I don't think this does and please don't use that in a service file. We
don't really want to drag that legacy concept of SysV runlevels into
native .service files.
To be sure: what are you trying to do here and why? Maybe we can find a
better solution
[Service]
Type=forking
EnvironmentFile=/etc/default/watchdog
ExecStartPre=/bin/sh -c '[ -z ${watchdog_module} ] || [
${watchdog_module} = none ] || echo /sbin/modprobe $watchdog_module'
Couldn't you just run ExecStartPre=-/sbin/modprobe $watchdog_module?
The - would ignore any errors
Btw, is echo /sbin/modprobe $watchdog_module really intended? that
will just output the module name.
Since we already have kernel module autoloading and /etc/modules, is
there a good reason to do it manually in the .service file?
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
Bug#768168: watchdog does not start at boot
Am 12.11.2014 um 14:44 schrieb Michael Biebl: Am 12.11.2014 um 14:29 schrieb Uwe Storbeck: On Nov 11, Michael Biebl wrote: Please boot with systemd.log_level=debug on the kernel command line, the attach the output of journalctl -alb I guess these are the relevant lines: Found ordering cycle on graphical.target/start Found dependency on multi-user.target/start Found dependency on watchdog.service/start Found dependency on graphical.target/start Breaking ordering cycle by deleting job watchdog.service/start [Unit] After=runlevel1.target runlevel2.target runlevel3.target runlevel4.target runlevel5.target [..] [Install] WantedBy=multi-user.target That's the part that causes the dep cycle afaics. By being hooked into multi-user.target, watchdog.service will have an explicit Before=multi-user.target dependency. multi-user.target on the other hand is an alias of runlevel2.target, runlevel3.target and runlevel4.target and you explicitly requested After=runlevel1.target runlevel2.target runlevel3.target runlevel4.target runlevel5.target Those are conflicting requirements, so systemd will drop the unit. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#768168: watchdog does not start at boot
On Wed, Nov 12, 2014 at 02:44:53PM +0100, Michael Biebl wrote: Yeah, it shows that watchdog.service is involved in dependency cycle and systemd therefore removes it from the transaction. Why doesn't it show the same reaction on my system then? Uwe's system doesn't seem to have any changes out of the ordinary. Any idea? After=runlevel1.target runlevel2.target runlevel3.target runlevel4.target runlevel5.target I don't think this does and please don't use that in a service file. We don't really want to drag that legacy concept of SysV runlevels into native .service files. I'm fine with any other solution. Problem is that this piece of systemd doesn't seem to be very well documented or I just didn't find anything. Couldn't you just run ExecStartPre=-/sbin/modprobe $watchdog_module? The - would ignore any errors Should do, just never occured to me. ExecStartPre=/bin/systemctl stop wd_keepalive Calling systemctl from service files is highly discouraged, I'd go as far as say forbidden unless you know exactly what you're doing. Can you elaborate why this is necessary? Sure, wd_keepalive is supposed to run whenever watchdog is not. But they cannot run at the same time, so wd_keepalive has to be stopped for watchdog to be started. ExecStart=/usr/sbin/watchdog $watchdog_options ExecStopPost=/bin/systemctl start wd_keepalive Same here. Does that mean, on shutdown, when all services are about to be stopped, you start wd_keepalive? Why? Yes, indeed that is what we need. Watchdog triggers a special device to tell the hardware watchdog that everything is well. When it is stopped it closes the device and obviously stops triggering it. Normally that means the hardware watchdog is disabled. However, there is a kernel setting called CONFIG_WATCHDOG_NOWAYOUT or somesuch that makes the kernel not accept the closing, meaning the hardware watchdog stays on alert and triggers a reset after a while. With watchdog having to be stopped early (it could be monitoring other services) the system might run into a reset by the watchdog before its shutdown has been finished. Therefore we need a small program doing nothing but triggering the device, which is wd_keepalive. Hopefully this very brief explanation makes sense. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768168: watchdog does not start at boot
To be sure: what are you trying to do here and why? Maybe we can find a better solution Watchdog should be started as late as possible during the boot process and stopped as early as possible during shutdown. Btw, is echo /sbin/modprobe $watchdog_module really intended? that will just output the module name. Na, that's an oversight. I forgot removing it after using it for debugging. Since we already have kernel module autoloading and /etc/modules, is there a good reason to do it manually in the .service file? At least it is needed for backward compatibility. That option has been there for ages and who knows how many systems still depend on it. This close to a release I don't want to risk breaking anything. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768168: watchdog does not start at boot
On Wed, Nov 12, 2014 at 03:17:22PM +0100, Michael Biebl wrote: That's the part that causes the dep cycle afaics. By being hooked into multi-user.target, watchdog.service will have an explicit Before=multi-user.target dependency. multi-user.target on the other hand is an alias of runlevel2.target, runlevel3.target and runlevel4.target and you explicitly requested After=runlevel1.target runlevel2.target runlevel3.target runlevel4.target runlevel5.target Those are conflicting requirements, so systemd will drop the unit. But that'd mean the same should happen on all systems, no matter which other packages are installed, right? Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768168: watchdog does not start at boot
On Nov 10, Michael Meskes wrote: Could you run 'ls /lib/systemd/system/graphical.target.wants/' please? # ls /lib/systemd/system/graphical.target.wants/ systemd-update-utmp-runlevel.service # cat /lib/systemd/system/graphical.target.wants/systemd-update-utmp-runlevel.service # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version. [Unit] Description=Update UTMP about System Runlevel Changes Documentation=man:systemd-update-utmp.service(8) man:utmp(5) DefaultDependencies=no RequiresMountsFor=/var/log/wtmp Conflicts=shutdown.target Requisite=systemd-update-utmp.service After=systemd-update-utmp.service After=runlevel1.target runlevel2.target runlevel3.target runlevel4.target runlevel5.target Before=shutdown.target [Service] Type=oneshot ExecStart=/lib/systemd/systemd-update-utmp runlevel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768168: watchdog does not start at boot
# ls /lib/systemd/system/graphical.target.wants/ systemd-update-utmp-runlevel.service Exactly the same on my system, no idea where the difference can be. I guess we need help from somebody who knows systemd much better. :) Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768168: watchdog does not start at boot
Am 11.11.2014 um 13:50 schrieb Michael Meskes: # ls /lib/systemd/system/graphical.target.wants/ systemd-update-utmp-runlevel.service Exactly the same on my system, no idea where the difference can be. I guess we need help from somebody who knows systemd much better. :) Please boot with systemd.log_level=debug on the kernel command line, the attach the output of journalctl -alb -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#768168: watchdog does not start at boot
On Wed, Nov 05, 2014 at 05:22:34PM +0100, Uwe Storbeck wrote: Package: watchdog Version: 5.14-1 Severity: important Dear Maintainer, since the last upgrade watchdog does not get started at boot time: Nov 05 16:42:52 grappa systemd[1]: Found ordering cycle on graphical.target/start Nov 05 16:42:52 grappa systemd[1]: Breaking ordering cycle by deleting job watchdog.service/start Nov 05 16:42:52 grappa systemd[1]: Job watchdog.service/start deleted to break ordering cycle starting with graphical.target/start Could you tell me which other services you have included in graphical.target? On my system the current setup works flawlessly. Could very well be that I made a mistake when setting the After: fields. @systemd maintainers: The reason for the current setting is that watchdog is supposed to start as late as possible to be able to check other services. Any hint how to find out how to accomblish that would be greatly appreciated. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768168: watchdog does not start at boot
On Nov 10, Michael Meskes wrote: Could you tell me which other services you have included in graphical.target? On my system the current setup works flawlessly. Could very well be that I made a mistake when setting the After: fields. It's the standard file from the systemd installation, no manual changes. /lib/systemd/system/graphical.target: # This file is part of systemd. # # systemd is free software; you can redistribute it and/or # modify it # under the terms of the GNU Lesser General Public License as # published by # the Free Software Foundation; either version 2.1 of the # License, or # (at your option) any later version. [Unit] Description=Graphical Interface Documentation=man:systemd.special(7) Requires=multi-user.target After=multi-user.target Conflicts=rescue.target Wants=display-manager.service AllowIsolate=yes There's no graphical display manager installed on the system though, in case that matters. The according line from the log is: systemd[1]: Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory. Regards Uwe -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768168: watchdog does not start at boot
On Mon, Nov 10, 2014 at 01:35:51PM +0100, Uwe Storbeck wrote: It's the standard file from the systemd installation, no manual changes. /lib/systemd/system/graphical.target: Could you run 'ls /lib/systemd/system/graphical.target.wants/' please? I was expecting 'systemctl list-dependencies' but it seems to not list graphical.target at all on my system. Michael -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Michael at BorussiaFan dot De, Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768168: watchdog does not start at boot
Package: watchdog Version: 5.14-1 Severity: important Dear Maintainer, since the last upgrade watchdog does not get started at boot time: Nov 05 16:42:52 grappa systemd[1]: Found ordering cycle on graphical.target/start Nov 05 16:42:52 grappa systemd[1]: Breaking ordering cycle by deleting job watchdog.service/start Nov 05 16:42:52 grappa systemd[1]: Job watchdog.service/start deleted to break ordering cycle starting with graphical.target/start Starting the service manually works. The only modification in the config files I have done manually is to enable the watchdog-device. Regards Uwe -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (750, 'testing'), (650, 'unstable'), (1, 'experimental') Architecture: i386 (x86_64) Kernel: Linux 3.16-3-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages watchdog depends on: ii debconf [debconf-2.0] 1.5.53 ii init-system-helpers1.21 ii libc6 2.19-12 ii lsb-base 4.1+Debian13+nmu1 ii makedev2.3.1-93 ii udev 215-5+b1 watchdog recommends no packages. watchdog suggests no packages. -- Configuration Files: /etc/default/watchdog changed: run_wd_keepalive=1 run_watchdog=1 watchdog_module=none watchdog_options= /etc/watchdog.conf changed: watchdog-device = /dev/watchdog realtime= yes priority= 1 -- debconf information: * watchdog/run: true * watchdog/module: none * watchdog/restart: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
