0

I have an embedded system running a slim installation of Buildroot Linux with kernel 3.10.105. Apparently most commands come from BusyBox here, and it seems those do not always implement the full functionality of the regular counterparts... I wonder whether more presistent logging is simply not implemented here, either, or maybe this can be configured?

So if I execute htop, I see that syslogd and klogd are running. I can see recent kernel messages in the file /var/log/messages. There is no kern.log in that log folder, though. All that's in there is: messages, resolv.conf, sshd, and then folders: dbus, subsys.

I'd like to inspect, after reboot, the kern.log (or whatever equivalent file) to see what happened before the system froze when using a certain driver.

Can I do this with the BusyBox tools?

EDIT: Some notes due to comments:

Configuration: when I type syslogd --help, it mentions that "this version of syslogd ignores /etc/syslog.conf". And according to htop, it runs with the option -n, which according to this help output means "run in foreground". The only option that a file parameter is: -O FILE, and it says the default is /var/log/messages, so it's the "live" file.

  • how is that syslogd configured? you might be able to add a suitable log line into its configuration file (and touch the file to be logged to first) – thrig Nov 9 '18 at 17:51
  • see updated text – sktpin Nov 9 '18 at 18:02
1

If the system crashed when you loaded a driver, there was probably a kernel panic, and the kernel wouldn't write the last messages to the log file, because it might corrupt the file system.

You could use a serial console or a network console to see the last messages. An alternative is "print debugging" to locate where the problem occurs.

You can also try dmesg --follow on a network connection, maybe you will see something useful.

  • I don't know if it makes a difference to what you said, but it didn't crash when loading the driver. The system stopped responding after using the driver briefly. It loads just fine with insmod, and does at least a few things it's supposed to. By using I mean, opening some of the files under /dev the driver creates. – sktpin Nov 9 '18 at 18:18
  • I don't think it will make much of a difference, at some point the system stops responding, and it's unlikely that the reason for that will be written to a log file, because for that to happen, the process writing to that file must be running, and the kernel must commit the changes to disk. I also added a suggestion about dmesg --follow. – RalfFriedl Nov 9 '18 at 18:26
  • Rather than dmesg --follow over e.g., ssh, use netconsole — that is far more likely to work. kernel.org/doc/Documentation/networking/netconsole.txt is the kernel docs, Arch (wiki.archlinux.org/index.php/Netconsole) and Ubuntu (wiki.ubuntu.com/Kernel/Netconsole) also have docs – derobert Nov 9 '18 at 18:38
  • The busybox syslogd command did allow to set stdout, passing '-' (minus) as destination file. I am at least seeing something now. How much is swallowed in some unflushed buffer when it crashes, is another question. – sktpin Nov 12 '18 at 13:26

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.