[RndTbl] *reading* a file causes reboot

[Wyatt Zacharias]

Does your own system have /dev/watchdog? Mine does, but I'm in the
middle of a bunch of stuff so I'm not going to go poking at it.

Also, did you read this:
https://www.kernel.org/doc/Documentation/watchdog/watchdog-api.txt

--
Wyatt Zacharias


On Mon, May 4, 2015 at 10:51 PM, 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.muug.mb.ca/pipermail/roundtable/attachments/20150504/269ac130/attachment.html>