mhhh - since it cost me more then one hour to find out why my machine reboots and triggering a reboot by just _reading_ a file on my system, device node or not is at least very weird behaviour from a user`s perspective.
waiting for an user-space daemon to start handling of /dev/watchdog file (opening it and manipulating it from time to time to show that it's still alive. When you cat the file, kernel recognizes it as that such an app is taking over control of the watchdog and starts it.
it`s looks a little bit too simple for me. triggering a reboot just by some simple open() and read() and close() ? let`s wait what the maintainer has to tell.
regards roland
Hi! I think it's not a bug, it's a normal behaviour. The kernel watchdog is normally not active when the machine is booted, waiting for an user-space daemon to start handling of /dev/watchdog file (opening it and manipulating it from time to time to show that it's still alive). When you cat the file, kernel recognizes it as that such an app is taking over control of the watchdog and starts it. However, because cat closes the file immediately, it is not handled anymore and kernel recognizes it as a userspace problem, thus rebooting the machine after the timeout expires. With regards, Pavel Troller
-----Ursprüngliche Nachricht----- Von: Pavel Troller patrol@sinus.cz Gesendet: 20.11.07 08:49:53 An: devzero@web.de CC: Hans Leidekker hans@it.vu.nl, wine-devel@winehq.org Betreff: Re: Unimplemented function KERNEL32.dll.FindFirstVolumeW
i`ve tracked this down to a watchdog issue.
whenever i do "cat /dev/watchdog" - my system reboots after ~1 minute.
i`ve contacted the maintainer of the watchdog subsystem.
looks like a bug to me.
thanks roland
Hi! I think it's not a bug, it's a normal behaviour. The kernel watchdog is normally not active when the machine is booted, waiting for an user-space daemon to start handling of /dev/watchdog file (opening it and manipulating it from time to time to show that it's still alive). When you cat the file, kernel recognizes it as that such an app is taking over control of the watchdog and starts it. However, because cat closes the file immediately, it is not handled anymore and kernel recognizes it as a userspace problem, thus rebooting the machine after the timeout expires. With regards, Pavel Troller
______________________________________________________________________________ Jetzt neu! Im riesigen WEB.DE Club SmartDrive Dateien freigeben und mit Freunden teilen! http://www.freemail.web.de/club/smartdrive_ttc.htm/?mc=021134
mhhh - since it cost me more then one hour to find out why my machine reboots and triggering a reboot by just _reading_ a file on my system, device node or not is at least very weird behaviour from a user`s perspective.
waiting for an user-space daemon to start handling of /dev/watchdog file (opening it and manipulating it from time to time to show that it's still alive. When you cat the file, kernel recognizes it as that such an app is taking over control of the watchdog and starts it.
it`s looks a little bit too simple for me. triggering a reboot just by some simple open() and read() and close() ? let`s wait what the maintainer has to tell.
regards roland
OK, Roland, but it's Linux :-). Isn't "rm -rf /" a simple command ? Yes, it is :-). Less keystrokes than "cat /dev/watchdog". And its impact is even more catastrophic :-). It's the reason why working as root is so much discouraged. With regards, Pavel Troller
On Tuesday 20 November 2007, devzero@web.de wrote:
mhhh - since it cost me more then one hour to find out why my machine reboots and triggering a reboot by just _reading_ a file on my system, device node or not is at least very weird behaviour from a user`s perspective.
Root's perspective != user's perspective. Normal users don't have access to /dev/watchdog (if they do, your system is misconfigured).
it`s looks a little bit too simple for me. triggering a reboot just by some simple open() and read() and close() ? let`s wait what the maintainer has to tell.
If you do it as root - yes. /dev/watchdog won't be the only culprit.
Cheers, Kuba
-
devzero＠web.de -
Kuba Ober -
Pavel Troller