On a RHEL 6.5 Desktop, if I use:

sudo grep -r foo /*

my desktop reboots.

Q: Why?? How to debug this? It's the third time my Desktop reboots because of this :D

  • 4
    Absolutly no idea. You can try sudo grep -r foo /* > /root/grep.log and may find some additional info... – Tobias Apr 24 '14 at 14:13
  • 2
    @Spack I can't imagine there's a proc file that reboots on read. – goldilocks Apr 24 '14 at 14:15
  • 1
    By the way, why did you do this (three times)? – Tobias Apr 24 '14 at 14:15
  • 2
    @Tobias : Why not? It is pretty weird and worth investigating. Contra Spack, I think you should be able to grep -r the entire filesystem safely. – goldilocks Apr 24 '14 at 14:17
  • 1
    And maybe strace would print some interesting infos... – Tobias Apr 24 '14 at 14:26

There are things you're not supposed to blindly read from.

/dev/mem and /dev/kmem come to mind, but /dev/port sounds even more dangeous to read - it maps to I/O ports directly. Reading blindly from that sounds like a recipe for disaster (hard-locked my machine a few minutes ago... for science I guess). I don't think reading from that file will result in the same symptoms for all machines, but a reboot doesn't sound unreasonable.

At the very least, you should exclude /dev entirely from that, and /sys and /proc shouldn't be included either - it makes no sense to search those filesystems even if it was entirely safe.

Consider the performance as well. Do you really want to grep all of /dev/sda, then all of /dev/sda1, then whatever filesystem contents it has (assuming it's mounted)?

  • 2
    Since version 2.12, GNU grep only searches in regular files (or special files passed on the command line) when invoked with -r. But RHEL6 has version 2.6.3 which indeed searches in all files including devices. – Gilles Apr 24 '14 at 22:38
  • /proc/kcore would be another. And that one appears as a completely normal file. It even has a size on it. – Patrick Apr 25 '14 at 0:43

strace helped, the bad device was the /dev/cdrom

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.