My OS Ubuntu 12.04. I wrote this Kernel Module and i use insmod and rmmod command but there isn't anything in /var/log messages. how can i fix this problem?
/*
* hello-1.c - The simplest kernel module.
*/
#include <linux/module.h> /* Needed by all modules */
#include <linux/kernel.h> /* Needed for KERN_INFO */
int init_module(void)
{
printk(KERN_INFO "Hello world 1.\n");
/*
* A non 0 return means init_module failed; module can't be loaded.
*/
return 0;
}
void cleanup_module(void)
{
printk(KERN_INFO "Goodbye world 1.\n");
}
Check whether syslog daemon process is running, since this is the process which copies printk messages from kernel ring/log message buffer to /var/log/messages if I am correct. printk messages can be seen using dmesg utility/command or messages will be in /var/log/messages. If correct loglevel is set then printk messages will be displayed on the console right away, no need to use dmesg or no need to check in /var/log/messages. printk debug messages can also be part of /var/log/syslog.
Modern Linux distributions don't use rsyslog (or any other syslog daemon) anymore. They rely on journald which is part of systemd, so the /var/log/messages file is missing and you have to use the journalctl command to read the system log.
Firstly, you should check that whether your module is properly loaded or not, by using this command
lsmod | grep "hello-1" //hello-1 is the name of your module
Since you wrote a kernel module, which prints some message. The messages from kernel and its module can be found in /var/log/syslog or you can view these kind of messages using dmesg command.
As your module prints "Hello World 1.", you should use following command to see message from your module.
dmesg | grep "Hello World 1."
Look for this in /etc/syslog.conf, the *.info... lines. These seem to control what gets logged via printk.
*.=info;*.=notice;*.=warn;\
auth,authpriv.none;\
cron,daemon.none;\
mail,news.none -/var/log/messages
I found that /proc/sys/kernel/printk only really controlled the console logging levels, not the logging to the file. And I guess check syslog is running too ;) We had exactly the same issue, KERN_INFO not going to log files and this fixed it. hth
I tried to print the kernel buffer by typing the following command :
dmesg
This will print the data written in printk
Related
I'm developing a simple driver for fun, and I'm trying to debug it with printk messages. It seems that dmesg doesn't display the last printk message, and the only way to get it to show the last message is by doing another printk, which in turn is also swallowed by dmesg.
Some examples for clarification:
in my module's init function I print the following statement:
printk(KERN_INFO "%s loaded with major: %u, minor: 0", ...);
After insmoding for the first time after a boot, I see a "tainted kernel" message with dmesg, however I can't see the message I printed.
Then, I run the following command:
cat /dev/mymodule
which invokes my open function which prints:
printk(KERN_DEBUG "%s opened", ...);
and then invokes my read function which prints:
printk(KERN_DEBUG "%s reading", current->comm);
and then goes to sleep. After running dmesg (while the read function sleeps), I can suddenly see my module init message, and I can also see the "cat opened" message, however the "cat reading" message is missing.
Terminating cat with ctrl+c causes two prints: "sleep interrupted", and then "cat released". Running dmesg shows the "sleep interrupted" message, but the "cat released" message is missing, and so on.
Does anyone know what the problem might be?
You should add \n at end of every printk message not to miss any logs in the dmesg. This will solve your problem.
I've been led to understand that if abrt-ccpp.service is installed on a Linux PC, it supersedes/overwrites (I've read both, not sure which is true) the file /proc/sys/kernel/core_pattern, which otherwise specifies the location and filename pattern of core files.
Question:
When I execute systemctl, why does abrt-ccpp.service report exited under the SUB column? I don't understand the combination of active and exited: is the service "alive"/active/running or not?
> systemctl
UNIT LOAD ACTIVE SUB
abrt-ccpp.service loaded active exited ...
Question:
Where are core files generated? I wrote this program to generate a SIGSEGV:
#include <iostream>
int main(int argc, char* argv[], char* envz[])
{
int* pInt = NULL;
std::cout << *pInt << std::endl;
return 0;
}
Compilation and execution as follows:
> g++ main.cpp
> ./a.out
Segmentation fault (core dumped)
But I cannot locate where the core file is generated.
What I have tried:
Looked in the same directory as my main.cpp. Core file is not there.
Looked in /var/tmp/abrt/ because of the following comment in /etc/abrt/abrt.conf. Core file is not there.
...
# Specify where you want to store coredumps and all files which are needed for
# reporting. (default:/var/tmp/abrt)
#
# Changing dump location could cause problems with SELinux. See man_abrt_selinux(8).
#
#DumpLocation = /var/tmp/abrt
...
Looked in /var/spool/abrt/ because of a comment at this link. Core file is not there.
Edited /etc/abrt/abrt.conf and uncommented and set DumpLocation = ~/foo which is an existing directory. Followed this by restarting abrt-hook-ccpp (sudo service abrt-ccpp restart) and rerunning a.out. Core file was not generated in ~/foo/
Verified that ulimit -c reports unlimited.
I am out of ideas of what else to try and where else to look.
In case helpful, this is the content of my /proc/sys/kernel/core_pattern:
> cat /proc/sys/kernel/core_pattern
|/usr/libexec/abrt-hook-ccpp %s %c %p %u %g %t e
Can someone help explain how the abrt-hook-ccpp service works and where it generates core files? Thank you.
I'd like to credit https://unix.stackexchange.com/users/119298/meuh who answered this at https://unix.stackexchange.com/questions/343240/cannot-locate-core-file-with-abrt-hook-cpp-installed.
The answer was to add this line in file /etc/abrt/abrt-action-save-package-data.conf
ProcessUnpackaged = yes
The comment from #daniel-kamil-kozar was also a viable workaround.
I want to know how gdm works, so I read the gdm source code. I saw a lot of g_debug output in the source code like this:
case SIGUSR1:
g_debug ("Got USR1 signal");
/* FIXME:
* Play with log levels or something
*/
ret = TRUE;
gdm_log_toggle_debug ();
break;
But I want to know where I can find the g_debug output.
You have to set the G_DEBUG environment variable to make GLib print out the debugging information.
Check the values in the documentation for Running and Debugging GLib Applications.
In Fedora 20, you can modify the gdm configuration file, /etc/gdm/custom.conf then add the following.
[debug]
Enable=True
Gesture=True
Then you can view the logs by typing journalctl -lr in the terminal.
How can I get current working directory in strace output, for system calls that are being called with relative paths? I'm trying to debug complex application that spawns multiple processes and fails to open particular file.
stat("some_file", 0x7fff6b313df0) = -1 ENOENT (No such file or directory)
Since some_file exists I believe that its located in the wrong directory. I'd tried to trace chdir calls too, but since output is interleaved its hard to deduce working directory that way. Is there a better way?
You can use the -y option and it will print the full path. Another useful flag in this situation is -P which only traces syscalls relating to a specific path, e.g.
strace -y -P "some_file"
Unfortunately -y will only print the path of file descriptors, and since your call doesn't load any it doesn't have one. A possible workaround is to interrupt the process when that syscall is run in a debugger, then you can get its working directory by inspecting /proc/<PID>/cwd. Something like this (totally untested!)
gdb --args strace -P "some_file" -e inject=open:signal=SIGSEGV
Or you may be able to use a conditional breakpoint. Something like this should work, but I had difficulty with getting GDB to follow child processes after a fork. If you only have one process it should be fine I think.
gdb your_program
break open if $_streq((char*)$rdi, "some_file")
run
print getpid()
It is quite easy, use the function char *realpath(const char *path, char *resolved_path) for the current directory.
This is my example:
#include <limits.h>
#include <stdio.h>
#include <stdlib.h>
int main(){
char *abs;
abs = realpath(".", NULL);
printf("%s\n", abs);
return 0;
}
output
root#ubuntu1504:~/patches_power_spec# pwd
/root/patches_power_spec
root#ubuntu1504:~/patches_power_spec# ./a.out
/root/patches_power_spec
I'm testing the communication between node.js and executables launched as child processes. An executable will be launched from within node.js via child_process.spawn() and its output will be monitored by node.js. I'm testing this capability both on Linux and Windows OSs.
I've successfully spawned tail -f /var/log/syslog and listened to its output, but my own executables can't seem to write correctly to stdout (in whatever form it exists when captured by node.js).
Test code:
#include <iostream>
#include <stdio.h>
#include <unistd.h>
int main()
{
using namespace std;
long x = 1;
while (true)
{
fprintf(stdout, "xtime - %ld\n", x++);
usleep(1000000);
}
}
(Note: some includes may be useless; I've not checked them)
stdout output is not automatically flushed (at least on *nix) when stdout is not a tty (even if there is a newline in the output, otherwise a newline generally flushes when stdout is a tty).
So you can either disable stdout buffering entirely via setbuf(stdout, NULL); or you can manually flush output via fflush(stdout);.