Linux Log Locations (and Power Saving Info?)

[James_McN]

Hello,

I'm trying to debug a problem with a USB device and struggling to find previous logs. It appears that /var/logs/demsg is the main system log for the current session, is that right?

If so can I see previous logs? There is a file called lastlog but it is empty - should this have the previous log in? Is there a way to keep a few more previous logs? My customers will often try rebooting things when they stop working and I don't want to loose useful information.

The problem is that we lost connection to a USB device (that was previously very reliable under windows) so I'm looking for any clues about why that connection was lost. If there are any other relevant logs that would be of interest (like I presume there is no power saving on these?)

Cheers,

James

[gratian.crisan]

'/var/logs/dmesg' is the boot time kernel log for the current session. You can also get this information by running the 'dmesg' command in a serial or ssh console.

Using 'dmesg' will also show you events that happen after boot so it is probably what you want. To debug the issue it would be helpful if you can post the output of 'dmesg' after the problematic USB device is plugged in.

Other useful tools for debugging this issue:

• lsusb - will list USB devices currently plugged in. It is useful to run it with 'lsusb -v'. This will increase the verbosity i.e. print the device descriptors.
• The contents of the pseudo file '/sys/kernel/debug/usb/devices' can also be useful. It is similar to the lsusb output but more condensed and lists the driver associated with a device.
• lsmod - will list currently loaded kernel modules (useful to see if a required driver is not loaded).

[James_McN]

Thanks Gratian - thats really useful.

So is there anyway to see dmesg for a previous session?

[gratian.crisan]

As you've already discovered by default most logs get wiped by a reboot. This happens because '/var/log' is actually a symbolic link to '/var/volatile/log' which is a temporary filesystem in RAM. The reason behind this on cRIO is because some of these logs get written to a lot during normal operation and it causes wear on the solid state storage (NAND or SSD chip). The system is configured to do wear leveling so it is going to take a while before you get bad blocks/failures but frequent writes will eventually shorten the disk life.

If you do want to enable persistent logging for debug purposes you can try:

• edit '/etc/default/volatiles/00_core' to comment out the following line (by adding a '#' character): '# l root root 0755 /var/log /var/volatile/log'
• remove '/etc/volatile.cache' file (it will get recreated on reboot): rm /etc/volatile.cache
• remove '/var/log' symbolic link: rm /var/log
• reboot

Some caveats:

• I've only tried this on a 2018 software stack with a cRIO-9049. Older software stacks might have a different setup. It might be helpful to know what version you are using.
• These changes will be lost if you re-format the target.