Ubuntu
udisks package

udisk prevent disk from standby, standby timer is broken

Bug #1899361 reported by Mohammad Kazemi on 2020-10-11

This bug affects 5 people

Affects		Status	Importance	Assigned to	Milestone
	udisks (Ubuntu)	Confirmed	Undecided	Unassigned
	udisks2 (Ubuntu)	Confirmed	Undecided	Unassigned

Bug Description

It seems udisks tries to access my HDD every 10 minute. So when I set standby timer less than 10 minutes, It can't go to standby.
Probably the disk shouldn't be checked when it's on standby.

This bug has been reported before (+bug #1281588) and seems to be fixed, But I'm experiencing this again.

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: udisks2 2.8.4-1ubuntu1
ProcVersionSignature: Ubuntu 5.4.0-48.52-generic 5.4.60
Uname: Linux 5.4.0-48-generic x86_64
ApportVersion: 2.20.11-0ubuntu27.9
Architecture: amd64
CasperMD5CheckResult: skip
CurrentDesktop: KDE
CustomUdevRuleFiles: wolfram-vernierlink-libusb.rules
Date: Sun Oct 11 19:38:48 2020
InstallationDate: Installed on 2020-10-02 (8 days ago)
InstallationMedia: Kubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
MachineType: ASUSTeK COMPUTER INC. VivoBook S15 X510UF
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.4.0-48-generic root=UUID=2dccc476-4ac0-4ab2-9742-bde2ad020de3 ro quiet splash vt.handoff=7
SourcePackage: udisks2
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 09/06/2019
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: X510UF.304
dmi.board.asset.tag: ATN12345678901234567
dmi.board.name: X510UF
dmi.board.vendor: ASUSTeK COMPUTER INC.
dmi.board.version: 1.0
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK COMPUTER INC.
dmi.chassis.version: 1.0
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrX510UF.304:bd09/06/2019:svnASUSTeKCOMPUTERINC.:pnVivoBookS15X510UF:pvr1.0:rvnASUSTeKCOMPUTERINC.:rnX510UF:rvr1.0:cvnASUSTeKCOMPUTERINC.:ct10:cvr1.0:
dmi.product.family: VivoBook S
dmi.product.name: VivoBook S15 X510UF
dmi.product.version: 1.0
dmi.sys.vendor: ASUSTeK COMPUTER INC.

See original description

Tags:

Revision history for this message

Mohammad Kazemi (mokazemi) wrote on 2020-10-11:

CurrentDmesg.txt Edit (77.4 KiB, text/plain; charset="utf-8")
Dependencies.txt Edit (4.9 KiB, text/plain; charset="utf-8")
Lspci.txt Edit (12.4 KiB, text/plain; charset="utf-8")
Lspci-vt.txt Edit (1.3 KiB, text/plain; charset="utf-8")
Lsusb.txt Edit (384 bytes, text/plain; charset="utf-8")
Lsusb-t.txt Edit (626 bytes, text/plain; charset="utf-8")
Lsusb-v.txt Edit (31.8 KiB, text/plain; charset="utf-8")
Mounts.txt Edit (3.0 KiB, text/plain; charset="utf-8")
ProcCpuinfo.txt Edit (10.2 KiB, text/plain; charset="utf-8")
ProcCpuinfoMinimal.txt Edit (1.3 KiB, text/plain; charset="utf-8")
ProcEnviron.txt Edit (284 bytes, text/plain; charset="utf-8")
ProcInterrupts.txt Edit (4.8 KiB, text/plain; charset="utf-8")
ProcModules.txt Edit (6.5 KiB, text/plain; charset="utf-8")
UDisksDump.txt Edit (27.8 KiB, text/plain; charset="utf-8")
UdevDb.txt Edit (223.4 KiB, text/plain; charset="utf-8")
acpidump.txt Edit (583 bytes, text/plain; charset="utf-8")

Revision history for this message

Launchpad Janitor (janitor) wrote on 2020-10-12:

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

Changed in udisks (Ubuntu):
status:	New → Confirmed
Changed in udisks2 (Ubuntu):
status:	New → Confirmed

Mohammad Kazemi (mokazemi) on 2020-10-12

description:

updated

Revision history for this message

Rocko (rockorequin) wrote on 2020-10-13:

Actually, I don't think this bug was ever fixed. IIRC we suggested putting in a configurable time for checking the SMART mon status but the gnome dev said that the bug was due to buggy hard drive firmware and so he wasn't going to do anything about it. It's a pain because each time udisks2 is updated I have to edit the source to make the check time longer and then rebuild and re-install it on each of my machines. It seems the "buggy" firmware is quite common in WD drives.

Revision history for this message

Mohammad Kazemi (mokazemi) wrote on 2020-10-13:

I'm using smartmontools to check my drive every 30 minutes. It has an option to don't check if the drive is standby. Can't they at least do the same?
And I had a question. Why does udisks checks smart data? Is it going to notify me if there's a problem, or ... ?

P.S. My hard drive model number is TOSHIBA MQ04ABF100

Revision history for this message

john reid (reidjr) wrote on 2021-05-20:

This problem is still in 20.04.1, but appears to have been fixed in master udisk2, patching from 10 mins to 60 mins.

https://github.com/storaged-project/udisks/issues/407#ref-commit-326b182

I assume this is in 21.x, but not available in LTS (?)

As a workaround, you can turn off the smarts function in Gnome-disks [Disks] GUI, which stops the polling through udisk2, and disables smarts on the disk. You can then re enable SMARTs on the individual drives with:

smartctl -s enable /dev/sdX.

smartmontools or other smartd tools will then work, with a configurable polling frequency if you need SMARTs. This does not re enable Disks udisk2 based polling, so the disks now sleep.

Revision history for this message

john reid (reidjr) wrote on 2021-05-20:

Sorry should have been:

smartctl -s on /dev/sdX.

Revision history for this message

Anghel Cristi-Marian (a.c.m) wrote on 2021-07-26:

@John Reid, sir, your comment is pure gold. My HDDs haven't slept in a LOOONG time. I wouldn't mind it if it wasn't for a fanless, HTPC NAS... that is in my living room.

Thank you.

:~$ sudo hdparm -C /dev/sda

/dev/sda:
drive state is: standby
:~$ sudo hdparm -C /dev/sdb

/dev/sdb:
drive state is: standby

Revision history for this message

Anghel Cristi-Marian (a.c.m) wrote on 2021-07-29:

3 days later ... I've realized that after restart, the system acts just like before, ignoring /etc/hdparm.conf and Gnome Disks pooling every 10 minutes. If I again, after restart, disable SMART in DISKS and re-enable it with smartctl -s on /dev/sdX it will resolve the problem till next reboot.

Revision history for this message

Emanem (em4n3m) wrote on 2021-09-10:

#10

This issue hits me also - I hope gets fixed asap. I hope that udisks2 gets updated to the version without this behaviour (10/5 minutes polling) as part of 20.04.

Revision history for this message

Patrick T (ptrant) wrote on 2024-02-15 (last edit on 2024-02-15):

#11

This issue also affects me on Mantic. I'm running a small home server and udisks2 was installed as a dependency of cockpit-storaged.

For now I removed cockpit-storaged and udisks2 and now my disks do go into standby, but it would be nice to be able to use the storage mangement in cockpit without breaking the HDD standby timer.

Revision history for this message

tommiku (tommiku) wrote on 2024-05-29:

#12

This issue also affects me on Ubuntu Mate Mantic. I'm running a desktop computer which have ssd and hdd. Hdd is for file archiving so i want it to spin down if it is not in use after specified time. Disks applications settings for hdd power management does not have any effect, however immediately spin down works correctly.