Trying to understand /var/log/messages read out

NewbODA · 10-25-2017, 08:57 AM

I have tried to Google and research, but trying to understand the meaning of this error. I believe this is disk related, but what can you tell from the "sd 2:0:17:0". Does this tell you what drive is having issues?

kernel: sd 2:0:17:0: qdepth(64), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)

Thank you

jsbjsb001 · 10-25-2017, 09:15 AM

Quote:

Originally Posted by NewbODA

I have tried to Google and research, but trying to understand the meaning of this error. I believe this is disk related, but what can you tell from the "sd 2:0:17:0". Does this tell you what drive is having issues?

kernel: sd 2:0:17:0: qdepth(64), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)

Thank you

From the output you have provided, no, it does not mean you are necessarily having any drive issues. You have to remember that the Linux kernel is very, very verbose and not just with drives either.

If your output looks similar to the following, this is quite normal:

Code:

[    2.215541] sd 2:0:0:0: [sdb] 390721968 512-byte logical blocks: (200 GB/186 GiB)
[    2.215568] sd 2:0:0:0: [sdb] Write Protect is off
[    2.215570] sd 1:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/112 GiB)
[    2.215571] sd 2:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[    2.215592] sd 1:0:0:0: [sda] Write Protect is off
[    2.215594] sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00
[    2.215612] sd 3:0:0:0: [sdc] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
[    2.215614] sd 3:0:0:0: [sdc] 4096-byte physical blocks
[    2.215615] sd 2:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    2.215632] sd 3:0:0:0: [sdc] Write Protect is off
[    2.215633] sd 3:0:0:0: [sdc] Mode Sense: 00 3a 00 00
[    2.215634] sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    2.215673] sd 3:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

If you want to check your drives, you can do a file system check (and the system should do this anyway, when it mounts your drives).

If you want to check the health of the hardware itself, you can run the following command:

Code:

smartctl -a /dev/sdXX

Replace "sdXX" with the actual device name.

NewbODA · 10-25-2017, 09:43 AM

Ran the smartctl cmd along with badblocks:
Just not sure why those errors are being reported, looks like on a daily basis filling up the log file.

Oct 25 03:55:00 kernel: sd 2:0:17:0: qdepth(64), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
Oct 25 04:01:01 kernel: sd 3:0:17:0: qdepth(64), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
Oct 25 04:01:01 kernel: sd 2:0:17:0: qdepth(64), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
Oct 25 04:07:02 kernel: sd 3:0:17:0: qdepth(64), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)

badblocks -v /dev/sdap
Checking blocks 0 to 390711384
Checking for bad blocks (read-only test): done
Pass completed, 0 bad blocks found.

smartctl 5.42 2011-10-20 r3458 [x86_64-linux-2.6.39-400.245.1.el5uek] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net

Vendor: HGST
Product: HSCAC2DA4SUN400G
Revision: A122
User Capacity: 400,088,457,216 bytes [400 GB]
Logical block size: 512 bytes
Logical Unit id: 0x5000cca04e0dfb84
Serial number: 001507JQPBZA 0QV7PBZA
Device type: disk
Transport protocol: SAS
Local Time is: Wed Oct 25 09:42:33 2017 EDT
Device supports SMART and is Enabled
Temperature Warning Enabled
SMART Health Status: OK
SS Media used endurance indicator: 0%

Current Drive Temperature: 28 C
Drive Trip Temperature: 70 C
Manufactured in week 07 of year 2015
Specified cycle count over device lifetime: 0
Accumulated start-stop cycles: 0
Specified load-unload count over device lifetime: 0
Accumulated load-unload cycles: 0
defect list format 6 unknown
Elements in grown defect list: 0
Vendor (Seagate) cache information
Blocks sent to initiator = 9977776182394880

Error counter log:
Errors Corrected by Total Correction Gigabytes Total
ECC rereads/ errors algorithm processed uncorrected
fast | delayed rewrites corrected invocations [10^9 bytes] errors
read: 0 0 0 0 0 103865.899 0
write: 0 0 0 0 0 4556.738 0

Non-medium error count: 0
No self-tests have been logged
Long (extended) Self Test duration: 2774 seconds [46.2 minutes]

ondoho · 10-25-2017, 11:11 AM

unless they are tagged as errors ("ERROR" or "EE" or "fail" or some such), they are NOT errors!!!

how many repetitions are you seeing? like, daily? how large does the log file grow?

NewbODA · 10-26-2017, 08:51 AM

Well, here is a snip-it of just the 8:00 timeframe today of /var/log/messages, but looks like it's alerting every 6 minutes..

Oct 26 08:03:33 kernel: sd 3:0:17:0: qdepth(64), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
Oct 26 08:03:33 kernel: sd 2:0:17:0: qdepth(64), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
Oct 26 08:09:34 kernel: sd 3:0:17:0: qdepth(64), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
Oct 26 08:09:34 kernel: sd 2:0:17:0: qdepth(64), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
Oct 26 08:15:34 kernel: sd 3:0:17:0: qdepth(64), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
Oct 26 08:15:34 kernel: sd 2:0:17:0: qdepth(64), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
Oct 26 08:21:35 kernel: sd 3:0:17:0: qdepth(64), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
Oct 26 08:21:35 kernel: sd 2:0:17:0: qdepth(64), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
Oct 26 08:27:36 kernel: sd 3:0:17:0: qdepth(64), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
Oct 26 08:27:36 kernel: sd 2:0:17:0: qdepth(64), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
Oct 26 08:33:36 kernel: sd 3:0:17:0: qdepth(64), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
Oct 26 08:33:36 kernel: sd 2:0:17:0: qdepth(64), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
Oct 26 08:39:37 kernel: sd 3:0:17:0: qdepth(64), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
Oct 26 08:39:37 kernel: sd 2:0:17:0: qdepth(64), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
Oct 26 08:45:38 kernel: sd 3:0:17:0: qdepth(64), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
Oct 26 08:45:38 kernel: sd 2:0:17:0: qdepth(64), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
Oct 26 08:51:39 kernel: sd 3:0:17:0: qdepth(64), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
Oct 26 08:51:39 kernel: sd 2:0:17:0: qdepth(64), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
Oct 26 08:57:40 kernel: sd 3:0:17:0: qdepth(64), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
Oct 26 08:57:40 kernel: sd 2:0:17:0: qdepth(64), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)
Oct 26 09:03:41 kernel: sd 3:0:17:0: qdepth(64), tagged(1), simple(0), ordered(0), scsi_level(7), cmd_que(1)

ondoho · 10-28-2017, 01:18 AM

i don't know what this message means, but as i said, it's not an error, not even a warning.
every 6 minutes seems fine, your logs shouldn't fill up faster than your log rotation software can handle, but of course you can check filesizes in /var/log yourself.
my complete /var/log is just 66M.
a single file can grow to a few megabyte in size.
these are of course very rough estimates and not meant to be taken literally or even seriously.
apart from that, logrotate or systemd should take care of deleting old logs.

Shadow_7 · 10-28-2017, 06:43 AM

You could scan the kernel for what generates that message. There's probably a flag somewhere to turn down the logging level / verbosity if they annoy you that much. /proc/sys/dev/scsi/logging_level ???

# egrep -r -i scsi_level /lib/modules/4.12.0-2-amd64/*

Code:

Binary file /lib/modules/4.12.0-2-amd64/kernel/drivers/scsi/scsi_debug.ko matches
Binary file /lib/modules/4.12.0-2-amd64/kernel/drivers/scsi/scsi_mod.ko matches

so scsi_debug and scsi_mod kernel modules. Further inspection of the sources could help you understand what is being reported. Although 6-ish minutes seems like the spindown time for spinning rust that is inactive. Just a guess though, you might be able to umount whatever part of them are mounted to avoid it spinning back up. Or just unplug them if you're not actively using them to avoid the messages (and save power).

wpeckham · 10-28-2017, 07:03 AM

I second ondoho on this. The file is "messages" not "errors" for good reason. It is full of kernel, application, listener, shell, and process messages that might be very handy IF something goes wrong. Unless they contain the ERR string or WARNING they are just messages and do not indicate (by themselves) a problem.

I would ignore them unless you get them in association with an error or warning.

JockVSJock · 10-28-2017, 07:37 AM

Is this a physical system or a VM? You haven't said, and I'm wondering because that possibly would make a difference.

https://www.smartmontools.org/wiki/F...machineguestOS

Code:

Do smartctl and smartd run on a virtual machine guest OS?

Yes and no. Smartctl and smartd run on a virtual machine guest OS without problems. But this isn't very useful because the virtual disks do not support SMART. If a guest OS disk is configured as a raw disk, this only means that its sectors are mapped transparently to the underlying physical disk. This does not imply the ATA or SCSI pass-through access required to access the SMART info of the physical disk. Even the disk's identity is typically not exposed to the guest OS.