On 04/05/2015 6:23 AM, Trevor Cordes wrote:
This was a lovely "bug" to run into during a server migration tonight.
as root: grep -r / foobar
cause a new system to crash/reboot. Did it again and it did it exactly at the same place.
The last line was about not being able to read (or some similar error) /dev/watchdog
Rackspace thought it was a bug too, and quite odd, then they looked around and decided this is "normal" when watchdogs are turned on. Huh? I haven't bz-checked this yet, but this smells funny to me. A read of a file should never *trigger* an action, right? It's like a /sys file: you echo > to them to get it to do something, never *read*.
A read on a file in /dev will almost always trigger an action (usually causing data to be read from a device, of course), but I can't imagine any normal scenario where that action should be a crash or reboot.
Any thoughts? If I don't find a bz about it, I'm definitely going to make one. (RHEL6)
This does sound like a bug to me.
RS claims the only "fix" is to disable watchdog or make sure not to grep -r /.
I know grep -r / is really cheesy and lame-o and wasteful as there's not going to be something in /dev I'll need (and reading /dem/kmem is really cheesy) but sometimes I really need to find all occurences of something fast with the least hassle possible (not going into / and ls'ing and deciding what to include/exclude which is different on many systems). My point is, grep -r / has never given me trouble in the past 20 years, but then again I usually don't have a watchdog.
I'd avoid grep -r from the root directory (especially as user root). The grep command is simplistic in its directory traversal, so (as I've seen in the past with it and other commands like "diff -r") you can end up in symlink-induced loops. I'd also avoid going through /dev (even just for reads), as this can cause hanging at the very least, and possibly other more serious unintended consequences. I have, in the past, done recursive traversals through /etc, but have encountered symlink loops that way.