Bug #1470014 “systemd-udevd: Process '/lib/udev/hdparm' failed w...” : Bugs : hdparm package : Ubuntu

Revision history for this message

dino99 (9d9) wrote on 2015-06-30:

#1

journal.ntp.log Edit (252.0 KiB, text/plain)
CurrentDmesg.txt Edit (56.7 KiB, text/plain; charset="utf-8")
Dependencies.txt Edit (3.0 KiB, text/plain; charset="utf-8")
JournalErrors.txt Edit (10.0 KiB, text/plain; charset="utf-8")
Lspci.txt Edit (13.6 KiB, text/plain; charset="utf-8")
ProcCpuinfo.txt Edit (3.2 KiB, text/plain; charset="utf-8")
ProcEnviron.txt Edit (328 bytes, text/plain; charset="utf-8")
ProcInterrupts.txt Edit (2.2 KiB, text/plain; charset="utf-8")
ProcModules.txt Edit (3.9 KiB, text/plain; charset="utf-8")
SystemdDelta.txt Edit (1013 bytes, text/plain; charset="utf-8")
UdevDb.txt Edit (129.7 KiB, text/plain; charset="utf-8")

Martin Pitt (pitti) on 2015-06-30

affects:

systemd (Ubuntu) → hdparm (Ubuntu)

dino99 (9d9) on 2015-06-30

description:

updated

Revision history for this message

Launchpad Janitor (janitor) wrote on 2015-08-04:

#2

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in hdparm (Ubuntu):
status:	New → Confirmed

Alberto Salvia Novella (es20490446e) on 2015-08-09

Changed in hdparm (Ubuntu):
importance:	Undecided → High

Bug Watch Updater (bug-watch-updater) on 2015-08-10

Changed in hdparm (Debian):
status:	Unknown → New

Revision history for this message

Jim Watson (ay-ubuntu) wrote on 2016-01-19:

#3

I get the same error, and I've found the cause of it on my system:
- /lib/udev/rules.d/85-hdparm.rules calls /lib/udev/hdparm for every sdX and shX drive
- /lib/udev/hdparm loads functions from /lib/hdparm/hdparm-functions
- When the 'hdparm_options' function is called it sets a default global APM policy
- Because I'm on AC power, with a stock /etc/hdparm.conf file, this results in -B 254 getting set.

While you can change the APM value via hdparm.conf, the -B switch is going to get set, no matter what. And not all of my drives support that. I understand why this is being done, but, we need the ability to disable it. My suggestion is another option in hdparm.conf, say "noapm" :)

In the meantime, because I actually wish to use hdparm.conf and easily see any errors on boot, I've edited:
/lib/hdparm/hdparm-functions, mine was line 88, comment out 'hdparm_set_option -B254'

Revision history for this message

Ivan Larionov (xeron-oskom) wrote on 2016-04-25:

#4

Same bug has been reported against xenial: https://bugs.launchpad.net/ubuntu/+source/hdparm/+bug/1568474

tags:

added: xenial

Revision history for this message

F-3000 (f3000d) wrote on 2016-05-11:

#5

A solution could be, that support for APM is checked before trying to set APM level.

user@hostname:~/$ sudo hdparm -B /dev/sda
[sudo] salasana henkilölle user:

/dev/sda:
APM_level = not supported
user@hostname:~/$

Revision history for this message

Drew Scott Daniels (drewdaniels) wrote on 2016-11-06:

#7

Download full text (3.2 KiB)

The other bug suggested this could be repeated by running (where sdX is the name of your block device, e.g. sda from /dev/sda):
sudo udevadm trigger --action=add /sys/block/sdX --verbose

Another way debug this without a reboot for a drive that's not mounted, you can disconnect the device and re-scan to add it.

# #Comment: First, figure out which logical port the drive is connected to:
# #Comment: In the output, make note of the host0 part. Other output may have host1 etc.
# #Comment: you may need to put a sudo in front of readlink.
# readlink /sys/block/sdX #e.g. for /dev/sda it would be readlink /sys/block/sda
../devices/pci0000:00/0000:00:1f.1/ata1/host0/target0:0:1/0:0:1:0/block/sda

# #Comment: Force disconnect the device (you may have to "sudo su -" first, or use sudo with tee):
# echo 1 > /sys/block/sdX/device/delete

# #Comment: Trigger rescan (you may have to "sudo su -" first, or use sudo with tee).
# #Comment: Note host0 matches from the readlink call above:
# echo "- - -" > /sys/class/scsi_host/host0/scan

If you want to apply the workaround for xenial, you need to comment out both "hdparm_set_option -B254" and the "else" above it in /lib/hdparm/hdparm-functions. If you don't properly comment out the else section, then you'll get something like:
systemd-udevd[XXX]: Process '/lib/udev/hdparm' failed with exit code 2.

A workaround that didn't work for me was to add "hdparm_set_option -q" on the line before "hdparm_set_option -B254" /lib/hdparm/hdparm-functions . Just changing it to "hdparm_set_options -q -B254" results in the -B254 not getting set as a parameter, which may be good enough for some people.

To add some debugging code, add the following to line 2 of /lib/udev/hdparm like suggested in bug 1568474.
set -x; exec 2>>/tmp/hdparm.txt
When incorrectly commenting out the "-B254" part, you may see something in /tmp/hdparm.txt like:
/lib/udev/hdparm: 89: /lib/hdparm/hdparm-functions: Synax error: "fi" unexpected

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795025 says "the -B254 option status is written to the unavailable output and generates the IO error."

The correct solution seems to be, as suggested test if the -B option is accepted before using it, having hdparm ignore the error (with a -q on line 88?), or changing the hdparm code's handling of the -B option failing. It would be nice to know when it fails with a warning in syslog instead of this error. It may also be useful to somehow get the output of hdparm going directly to the syslog when there is a non-0 error code, or even adding some information about what the command line was for the statement that failed if /lib/udev/hdparm is allowed to write to syslog.

For me this may be a problem that comes and goes as I need to look at older drives where the APM_level is not supported. For the one drive I'm currently looking at I see:
user@host:~$ sudo /sbin/hdparm -B254 /dev/sda

/dev/sda:
Setting Advanced Power Management level to 0xfe (254)
HDIO_DRIVE_CMD failed: Input/output error
APM_level = not supported
user@host:~$ sudo /sbin/hdparm /dev/sda

/dev/sda:
multcount = 16 (on)
IO_support = 1 (32-bit)
readonly = 0 (off)
readahead = 2...

The other bug suggested this could be repeated by running (where sdX is the name of your block device, e.g. sda from /dev/sda):
sudo udevadm trigger --action=add /sys/block/sdX --verbose

Another way debug this without a reboot for a drive that's not mounted, you can disconnect the device and re-scan to add it.

# #Comment: First, figure out which logical port the drive is connected to:
# #Comment: In the  output, make note of the host0 part. Other output may have host1 etc.
# #Comment: you may need to put a sudo in front of readlink.
# readlink /sys/block/sdX #e.g. for /dev/sda it would be readlink /sys/block/sda
../devices/pci0000:00/0000:00:1f.1/ata1/host0/target0:0:1/0:0:1:0/block/sda

# #Comment: Force disconnect the device (you may have to "sudo su -" first, or use sudo with tee):
# echo 1 > /sys/block/sdX/device/delete

# #Comment: Trigger rescan (you may have to "sudo su -" first, or use sudo with tee).
# #Comment: Note host0 matches from the readlink call above:
# echo "- - -" > /sys/class/scsi_host/host0/scan

If you want to apply the workaround for xenial, you need to comment out both "hdparm_set_option -B254" and the "else" above it in /lib/hdparm/hdparm-functions. If you don't properly comment out the else section, then you'll get something like:
systemd-udevd[XXX]: Process '/lib/udev/hdparm' failed with exit code 2.

A  workaround that didn't work for me was to add "hdparm_set_option -q" on the line before "hdparm_set_option -B254" /lib/hdparm/hdparm-functions . Just changing it to "hdparm_set_options -q -B254" results in the -B254 not getting set as a parameter, which may be good enough for some people.

To add some debugging code, add the following to line 2 of /lib/udev/hdparm like suggested in bug 1568474.
set -x; exec 2>>/tmp/hdparm.txt
When incorrectly commenting out the "-B254" part, you may see something in /tmp/hdparm.txt like:
/lib/udev/hdparm: 89: /lib/hdparm/hdparm-functions: Synax error: "fi" unexpected

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=795025 says "the -B254 option status is written to the unavailable output and generates the IO error."

The correct solution seems to be, as suggested test if the -B option is accepted before using it, having hdparm ignore the error (with a -q on line 88?), or changing the hdparm code's handling of the -B option failing. It would be nice to know when it fails with a warning in syslog instead of this error. It may also be useful to somehow get the output of hdparm going directly to the syslog when there is a non-0 error code, or even adding some information about what the command line was for the statement that failed if /lib/udev/hdparm is allowed to write to syslog.

For me this may be a problem that comes and goes as I need to look at older drives where the APM_level is not supported. For the one drive I'm currently looking at I see:
user@host:~$ sudo /sbin/hdparm -B254 /dev/sda

/dev/sda:
 Setting Advanced Power Management level to 0xfe (254)
 HDIO_DRIVE_CMD failed: Input/output error
 APM_level      = not supported
user@host:~$ sudo /sbin/hdparm /dev/sda

/dev/sda:
 multcount     = 16 (on)
 IO_support    =  1 (32-bit)
 readonly      =  0 (off)
 readahead     = 256 (on)
 geometry      = 25694/255/63, sectors = 234441658, start = 0

Revision history for this message

Thomas Mayer (thomas303) wrote on 2017-01-03:

#8

I can confirm this for ubuntu 16.04 with Kernel 4.4 (up-to-date).

I see this error in syslog, during boot (I'm using Luks-encrypted software raid (dmraid)).

Revision history for this message

Thomas Mayer (thomas303) wrote on 2017-01-03:

#9

I'm also using WD hard disks: WD30EURS

Revision history for this message

Nathan Stratton Treadway (nathanst) wrote on 2017-01-11: systemd-udevd: Process '/lib/udev/hdparm' failed with exit code 5

#10

I ran into this (using hdparm 9.48+ds-1 running under Ubuntu
16.04.1 LTS) with some HP Enterprise MB4000GCWLV drives that don't
have APM support (i.e.
hdparm -I /dev/sdb | grep "Advanced Power"
returns no output, or [as mentioned in comment #5] "hdparm -B"
reports "not supported").

For these drives, along with the "failed with exit code 5" log
messages, the default behavior of /lib/udev/hdparm triggered a
"SMART error (ErrorCount) detected on host" email from smartd each
time the system was rebooted (one email for each affected drive).

Each warning email had a message similar to:
Device: /dev/sdb [SAT], ATA error count increased from 33 to 34
... and sure enough, "smartctl -l error /dev/sdb" showed errors
like this one:

Error 30 [1] occurred at disk power-on lifetime: 5380 hours (224 days + 4 hours)
When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER -- ST COUNT LBA_48 LH LM LL DV DC
  -- -- -- == -- == == == -- -- -- -- --
  04 -- 51 00 00 00 00 00 00 00 00 00 00 Error: ABRT

  Commands leading to the command that caused the error were:
  CR FEATR COUNT LBA_48 LH LM LL DV DC Powered_Up_Time Command/Feature_Name
  -- == -- == -- == == == -- -- -- -- -- --------------- --------------------
  ef 00 05 01 fe dc d8 08 00 00 00 40 08 10:18:04.515 SET FEATURES [Enable APM]
  2f 00 00 00 01 00 00 00 00 00 11 00 08 10:17:53.325 READ LOG EXT
  2f 00 00 00 01 00 00 00 00 06 04 00 08 10:17:53.091 READ LOG EXT
  2f 00 00 00 01 00 00 00 00 05 04 00 08 10:17:52.857 READ LOG EXT
  2f 00 00 00 01 00 00 00 00 04 04 00 08 10:17:52.618 READ LOG EXT

Once I tracked these errors down to the default settings in the
hdparm udev script, I was able to avoid them by setting the "apm"
option to blank in a hdparm.conf device block, e.g.

/dev/disk/by-id/wwn[...] {
apm =
}

(This causes the script to end up running "hdparm -B" instead of
"hdparm -B254" for the drive in question, thus skipping the attempt
to enable APM on the drive, and as a result avoiding both the
error exit status message and a new instance of the error in the
ATA error log.)

Nathan

I ran into this (using hdparm 9.48+ds-1 running under Ubuntu
16.04.1 LTS) with some HP Enterprise MB4000GCWLV drives that don't
have APM support (i.e.
  hdparm -I /dev/sdb | grep "Advanced Power"
returns no output, or [as mentioned in comment #5] "hdparm -B"
reports "not supported").

For these drives, along with the "failed with exit code 5" log
messages, the default behavior of /lib/udev/hdparm triggered a
"SMART error (ErrorCount) detected on host" email from smartd each
time the system was rebooted (one email for each affected drive).

Each warning email had a message similar to:
   Device: /dev/sdb [SAT], ATA error count increased from 33 to 34
... and sure enough, "smartctl -l error /dev/sdb" showed errors
like this one:

Error 30 [1] occurred at disk power-on lifetime: 5380 hours (224 days + 4 hours)
  When the command that caused the error occurred, the device was active or idle.

After command completion occurred, registers were:
  ER -- ST COUNT  LBA_48  LH LM LL DV DC
  -- -- -- == -- == == == -- -- -- -- --
  04 -- 51 00 00 00 00 00 00 00 00 00 00  Error: ABRT

Commands leading to the command that caused the error were:
  CR FEATR COUNT  LBA_48  LH LM LL DV DC  Powered_Up_Time  Command/Feature_Name
  -- == -- == -- == == == -- -- -- -- --  ---------------  --------------------
  ef 00 05 01 fe dc d8 08 00 00 00 40 08     10:18:04.515  SET FEATURES [Enable APM]
  2f 00 00 00 01 00 00 00 00 00 11 00 08     10:17:53.325  READ LOG EXT
  2f 00 00 00 01 00 00 00 00 06 04 00 08     10:17:53.091  READ LOG EXT
  2f 00 00 00 01 00 00 00 00 05 04 00 08     10:17:52.857  READ LOG EXT
  2f 00 00 00 01 00 00 00 00 04 04 00 08     10:17:52.618  READ LOG EXT

Once I tracked these errors down to the default settings in the
hdparm udev script, I was able to avoid them by setting the "apm"
option to blank in a hdparm.conf device block, e.g.

/dev/disk/by-id/wwn[...] {
apm = 
}

(This causes the script to end up running "hdparm -B" instead of
"hdparm -B254" for the drive in question, thus skipping the attempt
to enable APM on the drive, and as a result avoiding both the
error exit status message and a new instance of the error in the
ATA error log.)

Nathan

Revision history for this message

Laurent Bonnaud (laurent-bonnaud) wrote on 2017-03-01:

#11

I no longer see this bug in Ubuntu 16.10. Can anyone else confirm?

Revision history for this message

dino99 (9d9) wrote on 2017-03-01:

#12

Seems this has been indirectly fixed somewhere in the past.

tags:

removed: wily

Bug Watch Updater (bug-watch-updater) on 2019-10-13

Changed in hdparm (Debian):
status:	New → Fix Released

Ubuntu
hdparm package

systemd-udevd: Process '/lib/udev/hdparm' failed with exit code 5.

Bug Description

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Affects		Status	Importance	Assigned to	Milestone
	hdparm (Debian)	Fix Released	Unknown	debbugs #795025
	hdparm (Ubuntu)	Confirmed	High	Unassigned

Ubuntuhdparm package

systemd-udevd: Process '/lib/udev/hdparm' failed with exit code 5.

Bug Description

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntu
hdparm package