I have noticed that, since either the August or the September updates (I did them basically within 3 days of difference, as I was away for a month), my external HDD doesn’t stay sleeping. Nothing on my system has changed except the updates.
I included a line in my crontab to do sudo /sbin/hdparm -S 240 /dev/sda > /dev/null regularly, but this is not helping. If I do sudo /sbin/hdparm -Y /dev/sda the hard drive goes to sleep, but after a while it wakes up.
The relevant part of the system log between is as follows:
Oct 06 23:10:40 raspi sudo[11718]: osmc : TTY=pts/0 ; PWD=/home/osmc ; USER=root ; COMMAND=/sbin/hdparm -Y /dev/sda
Oct 06 23:10:40 raspi sudo[11718]: pam_unix(sudo:session): session opened for user root by osmc(uid=0)
Oct 06 23:10:40 raspi sudo[11718]: pam_unix(sudo:session): session closed for user root
Oct 06 23:10:46 raspi sudo[11720]: osmc : TTY=pts/0 ; PWD=/home/osmc ; USER=root ; COMMAND=/bin/journalctl
Oct 06 23:10:46 raspi sudo[11720]: pam_unix(sudo:session): session opened for user root by osmc(uid=0)
Oct 06 23:11:02 raspi sudo[11720]: pam_unix(sudo:session): session closed for user root
Oct 06 23:17:01 raspi CRON[12180]: pam_unix(cron:session): session opened for user root by (uid=0)
Oct 06 23:17:01 raspi CRON[12181]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Oct 06 23:17:01 raspi CRON[12180]: pam_unix(cron:session): session closed for user root
Oct 06 23:20:01 raspi CRON[12400]: pam_unix(cron:session): session opened for user smmsp by (uid=0)
Oct 06 23:20:01 raspi CRON[12401]: (smmsp) CMD (test -x /etc/init.d/sendmail && /usr/share/sendmail/sendmail cron-msp)
Oct 06 23:20:01 raspi CRON[12400]: pam_unix(cron:session): session closed for user smmsp
Oct 06 23:38:38 raspi kernel: usb 1-1.3: reset high-speed USB device number 4 using dwc_otg
So this reset of the high-speed USB seems to be responsible for this. Any ideas on how to debug this further? As I said, nothing in my configuration has changed so I’m quite sure no other piece of software is affecting this.
I have read through other related topics in the forum, but as I said this started very recently, so there may be some changes in the latest updates. For completness, the relevant part of my udisks-glue.conf is
match disks {
post_insertion_command = '
if [ $(/bin/lsblk -n -d -o RM "%device_file") -eq 1 ] || [ $(/bin/lsblk -n -d -o ROTA "%device_file") -eq 0 ]; then
device=$(/bin/lsblk -n -d -o MAJ:MIN,TYPE -s "%device_file" | grep disk | sed "s/[^0-9:]*//g")
echo 1024 | sudo tee "/sys/dev/block/$device/queue/read_ahead_kb" > /dev/null
else
sudo /sbin/hdparm -S 240 %device_file
fi'
}
reset high-speed USB device number 4 using dwc_otg
message is the culprit, so I investigated a bit further to try to discard hardware failure. I tried to use smartctl to run tests, and the long one cannot run because it’s reset by the host, but the short one worked just fine:
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 6677 -
# 2 Extended offline Interrupted (host reset) 80% 6663 -
I’m starting to suspect that either my raspberry pi is failing or there has been a change in the kernel that causes this. Anybody else seeing this?
Even further investigation. This is happening every half hour if the HDD is sleeping. I set it to sleep at 10:40 (it was awake at 10:17) and this is what the logs show:
Oct 16 09:17:59 raspi kernel: usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
Oct 16 09:47:59 raspi kernel: usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
Oct 16 10:47:59 raspi kernel: usb 1-1.5: reset high-speed USB device number 4 using dwc_otg
It may not be very helpful but in my system the disk is going into stand by in a nicely fashion
I’ve edited udisks-glue.conf for different timmings and the disk always goes to stand by after the confugred timming.
Allow me to place to questions:
a) have you tried connecting another disk just for testing purposes ?
b) won’t you have any service running which may be using the disk and forcing it to wake up ?
thanks for the answers! I will try to also answer your questions:
I just tried adding an extra hard drive and it’s woken up at the exact same time as the other one: every half an hour.
I only installed, on top of OSMC, monitorix and deluge. I stopped both today and it is still happening.
It’s worth noting I’ve been running the EXACT same setup since January 2016. Nothing has been installed and the only updates are the monthly ones from OSMC. In fact, as you said, udisks-glue.conf had been configured for a 20 minute sleep timer (and in fact, the disks still go to sleep and are woken up after) and it was always sleeping until the August or September updates.
This is the reason I think it must be related to the update. Do you have any other ideas of what I could try?
Well … I agree is strange.
What file system are you using ? (ntfs, ext4, ext3, …)
What disk are you using ?
(I’m using a 2.5" seagate 2TB disk)
You disk is being powered by the pi itself or does it has an external power source ?
I would advise you to review your power source.
In my particular experience (having a 2.5 hdd powered by the pi), I had some issues in the past with the disk randomly disconnecting and reconnecting. It was solved when I bought an official raspberry pi 3 power supply , (which was the only one to guarantee real 5.1V @ 2.5A).
I believe that you having issues after an osmc update is just a coincidence.
But you can try using another sd-card and installing an older osmc version just to confirm the disk stays in sleep state with it.
[EDIT]
You may also try to look into your cron tabs just to make sure that “monitorix” or “deluge” didn’t left any disk wake up task running (I’m sorry, but I don’t know any of those tools)
Another shot is trying to install the current osmc version in a fresh new sd-card just to make sure it isn’t something else you may have installed in your system.
It’s a 3.5" disk with ext4, and has its own power supply. The pi is powered with the official RPi 3 power supply too, so that should be OK.
It may be a coincidence, but it’s literally the only thing that has changed in the system. I keep an extremely stable system. I’ll try to install an older osmc version, see how it goes (how should I go about that, BTW?).
I disabled both monitorix and deluge, and the problem was still happened. As I said, nothing has changed (including those two pieces of software, which were installed from source and therefore not automatically updated). Same goes for the rest of software in my system.
Again, I would really like to thank you for trying to help me debug this!
Albert
I still believe the best approach right now is to pick up another sd-card and installing there an older osmc version -as available in osmc site.
This will help you trace if your issue is related or not to the new osmc version.
If you problem is not replicable in the older osmc version, you should use that same version to upgrade to the most recent - tihs wil help you test the new version without any 3rd party installation.
(Using another sd-card will let you keep your current configuration during these tests)
Thanks a lot for the suggestions! Unfortunately I didn’t have any spare SD Card so while I waited to have time to go to the shop and buy one, the latest OSMC update came.
After installing it, the USB resets are gone and the hard drive is not being actually woken up each half an hour. It is till woken up from time to time but it’s something acceptable and probably due to real disk activity. I still can’t get the HDD to spin down on its own (it used to do it before, but now it’s not working), but it’s a definitive improvement.
It looks like it was something in OSMC after all. I’ll keep this open and report back as soon as I’ve made more extensive testing, but things are looking better.
