arpl icon indicating copy to clipboard operation
arpl copied to clipboard

Hibernation hdd.

Open vadimyra opened this issue 2 years ago • 9 comments

Please help me. I'm trying to install with your new bootloader 1.0 beta2 918+ and 920+. Everything works except hibernation HDD. There is always some kind of operation with the hard drive. Can this be fixed? On the forum they write that it is written logs on the disk, but I did not find a solution. Tell me. Thank you. i3 -6100(1151), board GA-H110M-S2, 8Gb, HDD 500Gb

vadimyra avatar Nov 07 '22 20:11 vadimyra

我也遇到了一样的问题,所有应用套件全部关闭,并且日志写在了tmp内存中,依然无法硬盘休眠不知道是什么影响的

zhouchiyan82 avatar Nov 08 '22 05:11 zhouchiyan82

我也遇到了一样的问题,所有应用套件全部关闭,并且日志写在了tmp内存中,依然无法硬盘休眠不知道是什么影响的

Try it didn't work for me. https://www.openos.org/threads/dsm7.4418/

vadimyra avatar Nov 08 '22 06:11 vadimyra

I have the same problem. I tried the script without success. The NAS never goes into hibernation. You have an idea?

AdictiK5 avatar Nov 16 '22 14:11 AdictiK5

Please update ARPL, rebuild the loader and test it again.

fbelavenuto avatar Nov 18 '22 19:11 fbelavenuto

unfortunately the problem is not solved. HDD hibernation and system hibernation still does not work, HDD is constantly busy. In all likelihood, logs and errors are written. On DSM 6.2.3. The problem was solved by prohibiting logging. 1 2

Can you help with the problem? Thank you.

vadimyra avatar Nov 19 '22 07:11 vadimyra

我也遇到了这样的问题,所有应用套装全部关闭,并且日志写在了tmp内存中,仍然无法硬盘休眠不知道是什么影响的

尝试它对我不起作用。 https://www.openos.org/threads/dsm7.4418/

yes,metoo,it's not work

zhouchiyan82 avatar Nov 19 '22 07:11 zhouchiyan82

我看了下官方的说明,可以在这里开启调试日志,但是我看了下里面的日志我根本看不懂是什么写入导致的无法休眠。。。。如果你有方案了希望能通知我一下 image

zhouchiyan82 avatar Nov 19 '22 07:11 zhouchiyan82

Unfortunately, I don't know hieroglyphs. Describe in a few words with Google translator. Thank you.

vadimyra avatar Nov 19 '22 08:11 vadimyra

Please update ARPL, rebuild the loader and test it again.

OK. I erased everything and started all over again. I did a clean installation, and rebuilt the loader with the new version of ARPL unfortunately without success. He still does not go into hibernation... Do you have another idea to test?

AdictiK5 avatar Nov 19 '22 10:11 AdictiK5

Ok, I've reduced the amount of systemd logs, but apparently that's not it! I still have no idea what it could be.

fbelavenuto avatar Nov 21 '22 11:11 fbelavenuto

Ok, I've reduced the amount of systemd logs, but apparently that's not it! I still have no idea what it could be.

You probably need to edit scemd.conf Here in this thread they describe how to do it, but it's too complicated for me. https://xpenology.com/forum/topic/52330-%D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D0%B5-%D0%B2%D0%BE%D0%BF%D1%80%D0%BE%D1%81%D0%B0-%D0%BF%D0%BE-%D0%B3%D0%B8%D0%B1%D0%B5%D1%80%D0%BD%D0%B0%D1%86%D0%B8%D0%B8-%D0%B4%D0%B8%D1%81%D0%BA%D0%BE%D0%B2-%D0%BF%D0%B5%D1%80%D0%B5%D1%85%D0%BE%D0%B4-%D0%B2-%D1%81%D0%BF%D1%8F%D1%89%D0%B8%D0%B9-%D1%80%D0%B5%D0%B6%D0%B8%D0%BC-%D0%B4%D0%B8%D1%81%D0%BA%D0%BE%D0%B2-dsm-623/#comment-254028

vadimyra avatar Nov 21 '22 11:11 vadimyra

Ok, please go to loader, update ADDONs, rebuild the loader and test it.

fbelavenuto avatar Nov 21 '22 12:11 fbelavenuto

As I was the author of the original post (about /dev/null) I can add several words.

  1. Instead of /dev/null I use now flags(final): log { source(src); filter(f_scemd); filter(f_scemd_sev); filter(f_no_auth); flags(final); };
  2. I had to change not only scemd.conf, but synosystemd.conf as well.
  3. After those changes those two logs are empty, but the problem was not solved - somebody uses hdds...
  4. Right now ARPL NAS in ssh copy sequence - so I can't check anything myself for about 42 hours. Sorry...

vasiliy-gr avatar Nov 21 '22 14:11 vasiliy-gr

As I was the author of the original post (about /dev/null) I can add several words.

  1. Instead of /dev/null I use now flags(final): log { source(src); filter(f_scemd); filter(f_scemd_sev); filter(f_no_auth); flags(final); };
  2. I had to change not only scemd.conf, but synosystemd.conf as well.
  3. After those changes those two logs are empty, but the problem was not solved - somebody uses hdds...
  4. Right now ARPL NAS in ssh copy sequence - so I can't check anything myself for about 42 hours. Sorry...

Ops, my bad! I'll adapt my script, thanks.

fbelavenuto avatar Nov 21 '22 15:11 fbelavenuto

I found one more item. I am not exactly sure on it... But... /var/lib/systemd/timers/stamp-powersched.timer This file is updated every 30 seconds. And it is on root FS, not ram FS, I think. So it makes hybernation never occure. This file is created for powershed.service by systemd on powersched.timer. And I do not know how to disable it permanently myself... Also there may be the same problem with remove-pma extension (that uses the same mechanism), but it can be disabled (deleted) easily, But I didn't examine its timer - may be it is not a problem... And this does not cancel the theme with scemd.log and synosystemd.log - they should be also cleared.

vasiliy-gr avatar Nov 26 '22 01:11 vasiliy-gr

Ok, thanks for the information

fbelavenuto avatar Nov 28 '22 11:11 fbelavenuto

Reference in new iss

Hello, I come to the news. I updated everything and I rebuilt the loader without success unfortunately, still no hibernation. Do you have other ideas to test?

AdictiK5 avatar Nov 28 '22 18:11 AdictiK5

nothing for now :(

fbelavenuto avatar Nov 29 '22 11:11 fbelavenuto

nothing for now :(

Eh... But what about checking and annihilation of stamp-powersched.timer?.. It may be not the only main reason for no hibernation, but seems to be important reason.

vasiliy-gr avatar Nov 29 '22 12:11 vasiliy-gr

Eh... But what about checking and annihilation of stamp-powersched.timer?.. It may be not the only main reason for no hibernation, but seems to be important reason.

I'm changing systemd.timer to crontab

fbelavenuto avatar Nov 29 '22 13:11 fbelavenuto

May be right now it is simplier to make extension "powersched" configurable on/off?.. I really do not need it (and its binary does nothing). But the persistent presense of it makes things worse because of systemd.timer.

vasiliy-gr avatar Nov 29 '22 13:11 vasiliy-gr

May be right now it is simplier to make extension "powersched" configurable on/off?.. I really do not need it (and its binary does nothing). But the persistent presense of it makes things worse because of systemd.timer.

Ok, I'll do

fbelavenuto avatar Nov 29 '22 15:11 fbelavenuto

The problem of hibernation of disks is smbd related. I tried disabling SMB through DSM configuration - right then my disks (SATA and SAS on SAS-hba) hibernated... I'll try to find out what happens with SMB daemon later on. But the problem seems to be solved. Anyway the two logs from previos discussion should be disabled also. And I still not sure about powersched extension and its timer (it is disabled on my test NAS but I do not need it).

And few words about beta6 and powersched extension. Previously I had beta3 (so this extension was mandatory). I rebooted with ARPL menu, updated ARPL, rebooted, updated everything below ARPL in update menu, checked extension menu, installed reducelog extension, rebuilded loader, rebooted again and now loaded DSM. But I found that binary and timer are still there! I think this is because this extension was absent previously and was absent now. So previous mandatory version with systemd.timer left untouched. And I had to delete binary manually and run systemctl disable/kill powersched.*. But anyway - I do not sure it is because of Beta6, as i did a lot of experiments with that NAS myself. And I am not sure if it is hibernation related problem or not. So now I will go on with a question, what is wrong with Samba... It is not very important for me (as all clients have NFS), but it is a disorder...

vasiliy-gr avatar Dec 02 '22 01:12 vasiliy-gr

About samba and one more solution for hibernation. You may wonder - what is the connection between samba and hibernation.... Samba service in DSM 42962 has a bug. It closes a connection with smth every minute. I think that it is a broadcast. May be the bug is not in samba itself but somewhere in DSM. Anyway I don't know how to fix it... May be it will be fixed in next DSM release. Samba service on connection close do not write log. Instead it writes smbd_cleanupd.tdb file in /var/cache/samba. This file has no useful information but prevents hdd-s from hibernation. So the most simple solution - is to disable samba completely as I wrote previously. Another solution - is to wait for a fix in DSM. May be there is some combination of settings that prohibits the bug. But I don't know... And there is a third one - to place all appropriate files in RAM instead of hdd-s. I found this method here: https://xpenology.com/forum/topic/64721-ds918-dsm-624-~-dsm-711-42962-hdd-cant-sleep-issue-hibernate-issue/ The above reference is only about logs, so I extended the method for samba cache. I will wrote scripts next post.

vasiliy-gr avatar Dec 02 '22 05:12 vasiliy-gr

You need to make two scripts - on boot-up and shutdown. It is very easy in DSM interface using its control panel. Both scripts run as root and has any names you like. On boot-up: if [ ! -d "/var/logbak" ]; then mkdir /var/logbak cp -a -f /var/log/. /var/logbak/ fi cp -a -f /var/logbak/. /tmp/log/ mount -B /tmp/log /var/log if [ ! -d "/var/cachebak" ]; then mkdir /var/cachebak cp -a -f /var/cache/samba/. /var/cachebak/ fi cp -a -f /var/cachebak/. /tmp/cache/ mount -B /tmp/cache /var/cache/samba

On shutdown: if [ ! -d "/var/logbak" ]; then cp -a -f /tmp/log/. /var/logbak fi if [ ! -d "/var/cachebak" ]; then cp -a -f /tmp/cache/. /var/cachebak fi

And then reboot. Everything should now work - both samba and hibernation. As we store all logs in ram - there is no practical need to do anything with them. But I think that it is better to leave as done now, as this two logs contain only garbage with ARPL. On the other hand I do not know how to examine boot logs that were produced before first script (but dmesg works). And as for ARPL - there may be some more elegant solution, I don't know... And the above scripts can be reduced twice - if you abondon first half about /var/log. And hibernation will work. But hdd-s will wake up if somebody will write to logs. It happens several times a day. Also I am not sure that samba works with previous session cache tdb-s. If not - scripts may be reduced on writing its back on shutdown.

vasiliy-gr avatar Dec 02 '22 05:12 vasiliy-gr

Is it necessary to reset the systemd log count to its original state? or is it enough to download the latest loader and update the addons and apply the rules?

Ok, please go to loader, update ADDONs, rebuild the loader and test it.

vadimyra avatar Dec 02 '22 07:12 vadimyra

@vasiliy-gr Very thanks for the informations!

fbelavenuto avatar Dec 02 '22 11:12 fbelavenuto

Hello, I followed your instructions, I updated everything and ARPL, I installed the "reducelog" extension, and I configured the two startup and shutdown scripts. Unfortunately without success, the NAS never goes into hibernation. I have an Asrock Q2900m with DS920+ installed. The problem comes from my configuration? Everything works for you?

You need to make two scripts - on boot-up and shutdown. It is very easy in DSM interface using its control panel. Both scripts run as root and has any names you like. On boot-up: if [ ! -d "/var/logbak" ]; then mkdir /var/logbak cp -a -f /var/log/. /var/logbak/ fi cp -a -f /var/logbak/. /tmp/log/ mount -B /tmp/log /var/log if [ ! -d "/var/cachebak" ]; then mkdir /var/cachebak cp -a -f /var/cache/samba/. /var/cachebak/ fi cp -a -f /var/cachebak/. /tmp/cache/ mount -B /tmp/cache /var/cache/samba

On shutdown: if [ ! -d "/var/logbak" ]; then cp -a -f /tmp/log/. /var/logbak fi if [ ! -d "/var/cachebak" ]; then cp -a -f /tmp/cache/. /var/cachebak fi

And then reboot. Everything should now work - both samba and hibernation. As we store all logs in ram - there is no practical need to do anything with them. But I think that it is better to leave as done now, as this two logs contain only garbage with ARPL. On the other hand I do not know how to examine boot logs that were produced before first script (but dmesg works). And as for ARPL - there may be some more elegant solution, I don't know... And the above scripts can be reduced twice - if you abondon first half about /var/log. And hibernation will work. But hdd-s will wake up if somebody will write to logs. It happens several times a day. Also I am not sure that samba works with previous session cache tdb-s. If not - scripts may be reduced on writing its back on shutdown.

AdictiK5 avatar Dec 05 '22 14:12 AdictiK5

I have 4 NASes. All of them use Proxmox, 12th generation of Intel CPUs, m/b-s Asus Prime Z690-P Wifi D4 or Z690M-Plus D4, SATA controllers are disabled, internal network cards are disabled, Intel 10G X550-T1 lan cards, LSI 9300-8i, 9400-8i and two 9400-16i, and a bunch of drives from 14 to 16 TB both SATA and SAS (WD Ultrastar and some Toshiba-s). Also every NAS names itself as DS3622xs+ with 7.1.1-42962 u2 DSM. And as for hibernation - all four work perfectly with ARPL 1.0-beta6. And I can check it easily on SAS hdd-s - they have inverted logic for activity leds on backplane (if no activity - led shines, on activity led turns out or blink), as in hibernation SAS leds turn out, as SATA leds do with no activity or in hibernation. As for your question there may be difference in SATA controller presense. More likely - in DS920+ on your side. Or may be something wrong with your setup and somebody writes to log... I don't know exactly...

vasiliy-gr avatar Dec 05 '22 15:12 vasiliy-gr

NAS называет себя DS3622xs+ с 7.1.1-42962 u2 DSM Надо попробовать перейти с 918+ на DS3622xs+ и посмотреть что получиться.

vadimyra avatar Dec 05 '22 17:12 vadimyra