[RndTbl] *reading* a file causes reboot

[Trevor Cordes]

On 2015-05-04 Gilbert E. Detillieux wrote:
> 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

Hmm, that's a good point.  I suppose a read on a device could "steal"
the input another program was expecting.

It's strange though, because now that I think about it, when I run grep
-r /, I'm pretty sure it's not reading all the disk block files, etc,
as it runs way too fast for that...

Ah, I forgot I had this set as an alias to grep on every system I use:
/bin/grep -s --devices=skip

I just checked and this new Rackspace box indeed had my alias set!
So the plot thickens!  So it's two possibly bugs: why was grep even
reading that watchdog device in the first place; and why did reading it
trigger a reboot?

> can end up in symlink-induced loops.  I'd also avoid going

I've never actually ended up in a symlink loop, but I can see how it
would be easy to run into.  I guess I don't use many dir symlinks on my
systems.

Or... I just RTFM and it looks like gnu grep solved the symlink problem
already:

       -r, --recursive
              Read  all  files  under  each  directory,  recursively,
following  symbolic links only if they are on the command line.  Note
       that if no file operand is given, grep
              searches the working directory.  This is equivalent to
the -d recurse option.

       -R, --dereference-recursive
              Read all files under each directory, recursively.  Follow
              all symbolic links, unlike -r.

So that explains why I've never hit a symlink loop: I've never used -R
(capital).

Ah, even better:
       -D ACTION, --devices=ACTION
              If  an input file is a device, FIFO or socket, use ACTION
to process it.  By default, ACTION is read, which means that devices are
read just as if they were ordinary
              files.  If ACTION is skip, devices are silently skipped.

So that means my -D skips every "weird" file.  That means that I've
definitely, for sure, hit some bugs here.  There's absolutely nothing
now that should stop anyone from safely doing a:

grep -r -D skip /

on any system with modern gnu grep.

The main reason I want to be able to do grep -r / sometimes is that I
need to find a string (like an IP address) that may be scattered
literally anywhere on the fs.  In the past when I say to myself "oh, it
must only be in /etc or /var or /home", there ends up being some little
file in /usr (not even /usr/local) or wherever that was changed ages ago
for whatever reason to work around whatever problem, and it gets missed
unless I just "grep the whole darn thing".  And to ls / and go through
the 10-15 items in my brain deciding if they are greppable or 
"system/non-greppable" takes time and is error/omission-prone, and to
list each one on the command line is a pain.  Now this would be easier
with a shell like zsh that has "negative globs" where I could specify
"* except /dev /sys" (ie just make an "exclude" list, not an include
list), but my beloved tcsh doesn't have that and I'm not ready to switch
to zsh yet.  And like I said before, each UNIX has its own different
set of "don't grep this" dirs, and they change over time (even in
Linux), so making a "one-alias fits all" is a non-solution.