[RndTbl] *reading* a file causes reboot

[Adam Thompson]

I've found "find / -xdev -type f -print0 | xargs grep string /dev/null" to be completely reliable and reasonably portable.  Not to mention a lot faster.  Faster yet if you use any of the #NN arguments to xargs to batch the grep invocations.
I started doing that because every time I ran grep -r, it would just hang somewhere in /etc.
-Adam
-Adam

On May 4, 2015 10:51:08 PM CDT, Trevor Cordes <trevor at tecnopolis.ca> wrote:
>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.
>_______________________________________________
>Roundtable mailing list
>Roundtable at muug.mb.ca
>http://www.muug.mb.ca/mailman/listinfo/roundtable

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.muug.mb.ca/pipermail/roundtable/attachments/20150504/774b9ad9/attachment.html>