I added a printk() in the function void __init setup_arch(char **cmdline_p) in /usr/src/linux/arch/x86/kernel/setup.c. And then run make and then dmesg /var/log and couldn't see my printk content,how and where can i see them
Take help from kernel log-level
http://elinux.org/Debugging_by_printing#Log_Levels
you can use following for enable all logs of kernel
echo 7 > /proc/sys/kernel/printk
hopefully it will help you.
To see kernel logs use -> dmesg it shows you printf of ring buffer of linux().
if there is problem to logs on console then use dmesg > log_file (logs will store in file you can find logs in file)
for more logs of system you can use following
vim /var/log/messages
vim /var/log/syslog
in /var/log/ directory all the system logs exist.
Related
I am currently using the following to read the system log:
journalctl -u <service name> | tail -n1
However I have a need to monitor the system log live, as changes come in (in a bash script), instead of just looping through the log file.
What is the best way to do this? I did some research to where the journalctl command is reading from, and it seems that the system logs are unreadable (or at least when I attempted with cat.
Any suggestions would be much appreciated!
journalctl tool has a -f flag which enables printing the contents of log file as soon as it is changed. Use it like this:
$ journalctl -u <service name> -f
I am using strace to capture calls to open(), close() and read() on Linux. The target process is the jetty web server. As far as I can tell, strace is not logging all calls to open(). Maybe the others too, I have not tried to correlate the file descriptors to open() calls.
For example, starting strace:
strace -f -e trace=open,close,read -o/tmp/strace.out -p62881
I then use wget to fetch 100 static files; all were retrieved successfully. In one run, only 56 open events were logged; on another run of 100 different files, I got 66 open events.
I believe that using "-f" results in strace attaching to all the LWPIDs for the threads ("Process 62881 attached with 25 threads - interrupt to quit
"); when I try to explicitly attach to all using multiple "-p" options, I get a single "attach" success message, but multiple "Operation not permitted messages", one for each child PID.
I restarted Jetty to clear its cache before my tests.
Kernel version is 2.6.32-504.3.3.el6.x86_64 (Red Hat). Strace package version is strace-4.5.19-1.19.el6.x86_64.
What am I missing?
Thanks
On some systems you have to use openat() instead of open().
Try:
strace -f -e trace=openat,close,read -o/tmp/strace.out -p62881
Try -ff (in addition to -f):
-ff: If the -o filename option is in effect, each processes trace is written to filename.pid where pid is
the numeric process id of each process. This is incompatible with -c, since no per-process counts are
kept.
I have a Java program after 2 weeks of running in average will become stuck and produce the following error:
Caused by: java.net.SocketException: Too many open files
at sun.nio.ch.Net.socket0(Native Method)
at sun.nio.ch.Net.socket(Net.java:415)
at sun.nio.ch.Net.socket(Net.java:408)
at sun.nio.ch.SocketChannelImpl.<init>(SocketChannelImpl.java:105)
That hints to me that many sockets are opened but never closed.
Before diving into programmatic instrumentation i started to inspect what information i could draw from linux itself. I am using Redhat.
And then, a few questions came up as follows:
Why the following commands do not give the same output?
See
[ec2-user#ip-172-22-28-102 ~]$ sudo ls /proc/32085/fd | wc -l
592
[ec2-user#ip-172-22-28-102 ~]$ sudo lsof -a -p 32085 | wc -l
655
Is there a way to know from the proc stat info which thread created which file descriptor?
It seems like there is not because if i do the following, i am getting the same information:
[ec2-user#ip-172-22-28-102 ~]$ sudo ls /proc/32085/task/22386/fd | wc -l
592
[ec2-user#ip-172-22-28-102 ~]$ sudo ls /proc/32085/fd | wc -l
592
Same if i go to the thread directly from under /proc/ .
Thx
Is there a way to know from the proc stat info which thread created which file descriptor?
I am pretty sure the answer here is "no". File descriptors are opened by processes, not threads (and will be visible to all threads spawned by the same process).
Why the following commands do not give the same output?
First, the -a argument to lsof appears to be a no-op in this case. Specfically, the man says that it "causes list selection options to be ANDed, as described above". So you are really just running:
sudo lsof -p 32085
And that will print things other than open file descriptors (such as memory-mapped files, current working directory, etc), while /proc/<PID>/fd contains only open file descriptors. So you're getting different results because you're asking for different information.
The only reason you can receive that message is that you have opened files and you didn't close them after use. You have a file descriptor leak in your java application. Java programmers normally don't check memory as the garbage collector copes with unreferenced objects. If you save file descriptors without closing in some data structure or you don't close the files after using, you can reach the maximum limit allowed to a process (this is controlled per process and can be changed by the ulimit shell command)
But if your problem is a file descriptor leak, pushing up the ulimit will only delay the problem some time. File descriptors must be closed, or you'll run into trouble.
I've just ran across this difference today, the explanation is that lsof takes into account more types of files, like memory-mapped objects, run-time libraries etc
I tried to search this in many places and also documents/man pages of openlog(), syslog(0, rsyslogd(8) but couldn't find answer for this.
My question is, if rsyslogd is stopped or not yet started, then do the new syslog messages get lost? Or rsyslogd fetches them from /dev/log later when it's enabled?
My test is:
On a running system, rsyslog is running. Now, do the following:
logger -p local7.notice "my custom message1"
grep message1 | /var/log/messages ----> Success
Stop rsyslogd process
logger -p local7.notice "My other custom message2"
now, start the rsyslogd daemon
grep message2 | /var/log/messages ----> FAIL
I understand from openlog(3) and syslog(3) man pages that a socket is opened for /dev/log file and if there is an error while sending the message to syslog (as rsyslogd is not running) then the connection is closed (and message is printed on console/stderror if you have used LOG_CONS/LOG_PERROR).
Could anybody please tell me:
Is there any way rsyslogd to get all those messages came in absence of it in syslog file when it comes up?
If not by default, is there any syscall, command,etc.etc.way to do that??
Thank you in advance.
-Neo
It won't happen by default. You can use the 'cat' command and pipe it to logger to get them in, though. Something like the following should work.
cat your.log | logger -n yourserver
You can also use the 'tail' command similarly to 'cat'.
Actually i want my driver messages to reach my terminal for debugging purpose. So i just try to check by following below link.
I refred following link :--
http://elinux.org/Debugging_by_printing
I am using a ubuntu in side vmplayer virtual machine. Ubuntu is running in terminal mode inside virtual machine.
I am trying to send some message to kernel printk buffer, buts echo command fails.
klog demon is also running i confirmed with following command .
ps aux | grep klogd
Cat command on proc printk entry :---
# cat /proc/sys/kernel/printk
4 4 1 7
run echo command :---
#sudo echo "<1>Writing critical printk messages from userspace" >/dev/kmsg
But i am not able to get the message on the terminal. I am getting following error when runs above command :--
-bash: /dev/kmsg: Permission denied
Please suggest how to print on console ?
my actual requirement is to ... send messages of printk() in my driver ... directly to my console. I am just testing here from my console that messages of low priority reaches console or not .
how this post is right then .. ?
linux kprint messages on console
Please suggest.
The error is because the shell is the thing trying to write to /dev/kmsg (via the redirect), and it is not being run with sudo. Also, by default echo is usually a shell builtin, not a binary that can executed in another process, though that's kind of irrelevant here. The right way to do this is
echo "blah" | sudo tee /dev/kmsg
tee is a command that copies stdin to a file and stdout. It's called tee because it's like a T-shaped pipe in a pipeline.