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

Bug #1470014 reported by dino99
This bug affects 26 people
Affects Status Importance Assigned to Milestone
hdparm (Debian)
Fix Released
hdparm (Ubuntu)

Bug Description

This is logged into journalctl
systemd-udevd[421]: Process '/lib/udev/hdparm' failed with exit code 5.

hdparm 9.43-1ubuntu3 (wily)

ProblemType: Bug
DistroRelease: Ubuntu 15.10
Package: systemd 221-1ubuntu2
ProcVersionSignature: Ubuntu 4.0.0-3.5-generic 4.0.5
Uname: Linux 4.0.0-3-generic i686
NonfreeKernelModules: nvidia
ApportVersion: 2.17.3-0ubuntu4
Architecture: i386
CurrentDesktop: GNOME
Date: Tue Jun 30 10:41:28 2015
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
 Bus 003 Device 002: ID 046d:c50e Logitech, Inc. Cordless Mouse Receiver
 Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.0.0-3-generic root=UUID=7b1f4a51-558f-468f-85e0-f815d2f791e1 ro
SourcePackage: systemd
UdevLog: Error: [Errno 2] No such file or directory: '/var/log/udev'
UpgradeStatus: No upgrade log present (probably fresh install) 07/22/2010
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 3002
dmi.board.asset.tag: To Be Filled By O.E.M. P5W DH Deluxe
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: Rev 1.xx
dmi.chassis.asset.tag: Asset-1234567890
dmi.chassis.type: 3
dmi.chassis.vendor: Chassis Manufacture
dmi.chassis.version: Chassis Version
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr3002:bd07/22/2010:svnASUSTEKCOMPUTERINC:pnP5WDHDeluxe:pvrSystemVersion:rvnASUSTeKComputerINC.:rnP5WDHDeluxe:rvrRev1.xx:cvnChassisManufacture:ct3:cvrChassisVersion: P5W DH Deluxe
dmi.product.version: System Version
dmi.sys.vendor: ASUSTEK COMPUTER INC

Revision history for this message
dino99 (9d9) wrote :
Martin Pitt (pitti)
affects: systemd (Ubuntu) → hdparm (Ubuntu)
dino99 (9d9)
description: updated
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in hdparm (Ubuntu):
status: New → Confirmed
Changed in hdparm (Ubuntu):
importance: Undecided → High
Changed in hdparm (Debian):
status: Unknown → New
Revision history for this message
Jim Watson (ay-ubuntu) wrote :

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 :

Same bug has been reported against xenial:

tags: added: xenial
Revision history for this message
F-3000 (f3000d) wrote :

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:

 APM_level = not supported

Revision history for this message
Drew Scott Daniels (drewdaniels) wrote :
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

# #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 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

 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

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


Revision history for this message
Thomas Mayer (thomas303) wrote :

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 :

I'm also using WD hard disks: WD30EURS

Revision history for this message
Nathan Stratton Treadway (nathanst) wrote : systemd-udevd: Process '/lib/udev/hdparm' failed with exit code 5

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:
  -- -- -- == -- == == == -- -- -- -- --
  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.)


Revision history for this message
Laurent Bonnaud (laurent-bonnaud) wrote :

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

Revision history for this message
dino99 (9d9) wrote :

Seems this has been indirectly fixed somewhere in the past.

tags: removed: wily
Changed in hdparm (Debian):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.