How can grep hog your entire cpu? I am absolutely shocked by this.
Entire CPU ??!! Are you logging CPU based on numbers or by usage ..
In Solaris,
If by number wise - mpstat command will help you ..
If by usage wise - prstat ..
All I was doing is this.
sudo grep -ri "xprofile" /etc/* 2>/dev/null
My gui completely froze so I hit ctrl+alt+f2 to open up a new console. Then I used used top to check out what was going on. top said I was at 100% cpu usage and grep was hogging my entire cpu.
Hmm.
This will search every inode in directory /etc whether or not that inode is suitable for "grep". You can even find pipes under /etc .
On my system it would try to search over 8000 inodes.
As a minimum, consider limiting the list by using "find -xdev -type f" and then further checking for text files with the "file" command.
Is there any particular reason you were running it as root? Nearly nothing in /etc/ needs root to be read. Using root needlessly is dangerous.
grep has no power to freeze your GUI. It only gets as much CPU time as it's given, it can't hog it. This was an OS or GUI crash of some sort.
Is this the same system you were having severe system instability with before? Did you ever really track that down?
You better use find as suggested. When I forget (that happens more often) about the location of any config file or any such thing, but somehow if I remember any unique word in that file I do this:
find /etc -xdev -type f | xargs grep -i "unique_word"
This is lot faster.
@Corona688
Some directories in /etc are indeed restricted for root. This depends on what UNIX/Linux variant you are using and the installed software/packages. See below:
##for a RHEL 6.1
$ ls -ltr /etc/* 2>err
$ cat err
ls: cannot open directory /etc/sudoers.d: Permission denied
ls: cannot open directory /etc/dhcp: Permission denied
ls: cannot open directory /etc/named: Permission denied
ls: cannot open directory /etc/sssd: Permission denied
ls: cannot open directory /etc/audisp: Permission denied
ls: cannot open directory /etc/audit: Permission denied
##for a Solaris11
$ ls -ltr /etc/* 2>err
$ cat err
/etc/sudoers.d: Permission denied
##for a FreeBSD
$ ls -ltr /etc/* 2>err
$ cat err
ls: /etc/ntp: Permission denied
What if the file you are searching are in one of those directories.
Also, my RHEL 6.1 VM took 100% of CPU time of 4 allocated cores (with only 953 inodes in /etc directory):
top - 23:24:54 up 18 min, 2 users, load average: 0.20, 0.05, 0.02
Tasks: 173 total, 2 running, 171 sleeping, 0 stopped, 0 zombie
Cpu(s): 25.0%us, 0.2%sy, 0.0%ni, 74.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 756832k total, 380896k used, 375936k free, 5760k buffers
Swap: 1540088k total, 0k used, 1540088k free, 219216k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2522 root 20 0 101m 1468 724 R 100.0 0.2 0:08.52 grep
2055 unixuser 20 0 15088 1284 952 R 0.3 0.2 0:01.35 top
1 root 20 0 19396 1544 1248 S 0.0 0.2 0:00.96 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.01 kthreadd
3 root RT 0 0 0 0 S 0.0 0.0 0:00.09 migration/0
4 root 20 0 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0
5 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
6 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
7 root RT 0 0 0 0 S 0.0 0.0 0:00.09 migration/1
8 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/1
9 root 20 0 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/1
10 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/1
11 root RT 0 0 0 0 S 0.0 0.0 0:00.08 migration/2
12 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/2
13 root 20 0 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/2
14 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/2
15 root RT 0 0 0 0 S 0.0 0.0 0:00.10 migration/3
16 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/3
So there's a pretty good reason why your GUI got stuck as grep has to run a loop for each inode (that includes directories as well which is absolutely meaning less in this case).
Use find!!!
So? He's not looking inside any directories.
So what? That doesn't hang the system. Linux is a pre-emptive kernel. If a process wastes too much time, it will be stopped so something else can go. At worst grep could've lagged the system from using 100% CPU. It wouldn't freeze it.
Back in my college days, a fellow student accidentally left behind a process which due to a bug did nothing but eat 100% CPU. Several weeks later, it was still there. Nobody noticed it until I ran 'top'. It hadn't interfered with people's use of the system at all.
Are you sure of that?
Shell expands "/etc/*" to any file and folder beneath /etc directory. "grep -r" recursively checks in those directories. So if you do not have permission to get into the directory, how else would you access files/folders beneath it?
So what? That doesn't hang the system. Linux is a pre-emptive kernel. If a process wastes too much time, it will be stopped so something else can go. At worst grep could've lagged the system from using 100% CPU. It wouldn't freeze it.
You are right. Linux indeed gives priority to interactive processes when "preemptive"-ness is compiled into the kernel. On server platform, as you are less likely to use interactive programs, preemption is not set on some distro's kernel. Take a look at my RHEL 6.2 kernel config:
# uname -a
Linux blue 2.6.32-220.el6.x86_64 #1 SMP Wed Nov 9 08:03:13 EST 2011 x86_64 x86_64 x86_64 GNU/Linux
# grep -i preempt /boot/config-2.6.32-220.el6.x86_64
# CONFIG_TREE_PREEMPT_RCU is not set
CONFIG_PREEMPT_NOTIFIERS=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
So unless you are compiling a vanilla kernel or using a desktop platform, you are highly likely using non-preemptive kernel 
Server distributions often lower the tick rate so pre-emption happens less often, but it'd be ridiculous to turn it off. Anyone who's ever used windows 3.1 knows the consequences of that, and allowing one faulty usermode process to bomb your system is beyond stupid. I don't accept that option means what you think it does. I'll investigate in more detail myself.
There's an enormous problem with your explanation, anyway. His system did, in fact, pre-empt grep. How else could he have regained control by ctrl-alt-f1? Why would it pre-empt for ctrl-alt-f1, and not for the GUI? His system wasn't hardlocked. The GUI had malfunctioned.
---------- Post updated at 10:19 AM ---------- Previous update was at 08:51 AM ----------
I'm pretty sure you're talking about kernel-mode pre-emption, which is something different. It allows the kernel to pre-empt itself in some circumstances so it can respond more quickly and smoothly to realtime requests. This is often left disabled for servers, because it may trade some performance for response time.
This has nothing to do with the pre-emption of user-mode programs. A linux system that lacks user-mode pre-emption would not be stable or sane.
So I stand by my earlier point: grep should not have been able to freeze a system by consuming 100% CPU. Something else is going wrong with this system. If this is the system I think it is, COKEDUDE has had strange problems with this system before, like random segmentation faults in perfectly good programs, so I don't trust that grep itself is the issue.
The "grep" is searching everything under /etc (including pipes or whatever). The scope of the search needs fixing such that "grep" only searches ascii text files.
Whether 100% cpu means a lot depends on how many cpus you have fitted. To achieve 100% cpu on a single cpu and run a program to report the value is pretty unlikely.
Can you please explain what -xdev -and -type f do in in find?
I was reading this and don't understand.
Aren't all files considered regular files or directories? Can you explain the
different filetypes?
-type c
File is of type c:
b block (buffered) special
c character (unbuffered) special
d directory
p named pipe (FIFO)
f regular file
l symbolic link; this is never true if the -L option or the
-follow option is in effect, unless the symbolic link is
broken. If you want to search for symbolic links when -L
is in effect, use -xtype.
s socket
D door (Solaris)
Wouldn't giving it the directory /etc prevent it from descending into another filesystem?
-xdev Don't descend directories on other filesystems.
Yes, I created the file as root and didn't give anyone else read permissions. root is the only way to create files in the /etc directory. Also many files in fedora are readonly by root only.
Grep did freeze my gui. I tested 3 times on a fresh startup. I also tested 3 times after leaving my computer running for an hour. The same thing happened all 6 times.
I reformatted. I also took it to 2 different computer stores and neither could find a problem.
The find trick seemed way faster when it works but it doesn't seem reliable. The second time I saw it was searching binary files and there is no point of the that so I added the -I option to grep. The third time it looks like it skipped /etc directory.
$ find /etc -xdev -type f 2>/dev/null | xargs grep -i "1122334455" 2>/dev/null
/etc/sysconfig/network-scripts/keys-YOYO:KEY1=1122334455
$ find / -xdev -type f 2>/dev/null | xargs grep -i "1122334455" 2>/dev/null
Binary file /opt/google/talkplugin/GoogleTalkPlugin matches
/usr/share/doc/ppp-2.4.5/README.pwfd:char *username = "1122334455661122334455660001@t-online.de";
Binary file /usr/share/gimp/2.0/gimpressionist/Brushes/grad02.pgm matches
^C
$ find / -xdev -type f 2>/dev/null | xargs grep -iI "1122334455" 2>/dev/null
/usr/share/doc/ppp-2.4.5/README.pwfd:char *username = "1122334455661122334455660001@t-online.de";
Yes I am. The file is somewhere in the /etc directory.
I only have 2 cores.
Your right. Its not set for me either.
$ uname -a
Linux hi 2.6.41.9-1.fc15.i686 #1 SMP Fri Jan 13 16:43:37 UTC 2012 i686 i686 i386 GNU/Linux
$ grep -i preempt /boot/config-2.6.41.9-1.fc15.i686
# CONFIG_PREEMPT_RCU is not set
CONFIG_PREEMPT_NOTIFIERS=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set
I have several computers at work and school I can use.
What command do you recommend? The find trick doesn't seem reliable.
I have a dual core on the computer I am talking about.
@COKEDUDE
It's time to read up and learn how to search only inodes on the current filesystem which are ascii text files.
When you come up with your original script, please post it on this forum for the benefit of others.
Don't forget to post in the Homework Forum if your post is nothing to do with your daytime work.