Firmware 4.2.2 build 20161021 prevent disk from hibernate

[JMO91]

Hello,

I own a TS251C with 2 disks in JBOD. No RAID. Fully encrypted.

Just tried the last firmware 4.2.2 build 20161021.
I noticed the disk hibernate feature does not work (the 2 leds blinks every 20 seconds)
Put back the previous version 4.2.2 build 20160901.
Everything runs fine with this version.

Anyone else notice this behaviour ?

Thanks. Have a nice day !

[sj5150]

Confirmed. TS-251 HDD spin down ceased to function after update from 4.2.2 20160901 to 20161021.
Reverted back to 20160901 and drives spin down correctly now.
Ooops.. Try again QNAP.

[JMO91]

Hello,
Just to inform a new firmware has been posted.
However, in the bug fixes, I don't see any changes regarding HDD hibernate
https://www.qnap.com/en/releasenotes/

[dolan.m]

I can confirm 4.2.2 build 20161028 doesn't help with this problem.

[dolan.m]

I've been quite desperate to pin this down. I came to some observations but sadly no way out of it.

1. I ran the infamous blkdevMonitor.sh. I can see no point to share it here in its fullness (please correct me if I'm wrong), here is a typical record in the beginning of every disk wakeup log record (the rest is unintersting and all this is repeated 100 times with NO other significant entries):

Code: Select all

============= 16/100 test, Sat Oct 29 16:56:42 CEST 2016 ===============
<7>[10590.376323] setcfg(26095): dirtied inode 13485 (uLinux.conf.bak) on md9
<7>[10590.376442] setcfg(26095): dirtied inode 13491 (?) on md9
<7>[10590.383781] setcfg(26097): dirtied inode 13491 (uLinux.conf.bak) on md9
<7>[10590.387577] setcfg(26098): dirtied inode 13485 (uLinux.conf.bak) on md9
<7>[10590.395023] setcfg(26100): dirtied inode 13491 (uLinux.conf.bak) on md9
<7>[10590.402411] setcfg(26102): dirtied inode 13485 (uLinux.conf.bak) on md9
<7>[10590.409809] setcfg(26104): dirtied inode 13491 (uLinux.conf.bak) on md9
<7>[10620.408190] setcfg(26988): dirtied inode 13485 (uLinux.conf.bak) on md9
<7>[10620.408306] setcfg(26988): dirtied inode 13491 (?) on md9
<7>[10620.416168] setcfg(26990): dirtied inode 13491 (uLinux.conf.bak) on md9
<7>[10620.420001] setcfg(26991): dirtied inode 13485 (uLinux.conf.bak) on md9
<7>[10620.427451] setcfg(26993): dirtied inode 13491 (uLinux.conf.bak) on md9
<7>[10620.434855] setcfg(26995): dirtied inode 13485 (uLinux.conf.bak) on md9
<7>[10620.442332] setcfg(26997): dirtied inode 13491 (uLinux.conf.bak) on md9
<7>[10565.739819] kjournald(304): WRITE block 536248 on md9 (8 sectors)
<7>[10565.739831] kjournald(304): WRITE block 536256 on md9 (8 sectors)
<7>[10565.739841] kjournald(304): WRITE block 536264 on md9 (8 sectors)
...
...

2. I could not find the file uLinux.conf. bak anywhere. But /etc/config/uLinux.conf is indeed touched (changed file date) every single minute! Needless to say, nothing is changed in the file. If nothing else, this IS positively waking up the disk every single minute. I don't observe this behaviour on other Qnap NASes (119, 219 and 131) which didn't get the last firmware update. IMHO this /etc/config/uLinux.conf update is not driven by any cron task. And I would really like to know what else may do it. I hate it because it's absolutely useless.

(the rest is possibly irrelevant to the spindown problem)
3. I had a look in the crontab. One entry is interesting as it runs every minute:

Code: Select all

* * * * * /mnt/ext/opt/netmgr/util/lock_timer.sh

I tried to run the script manually and there was an error:

Code: Select all

/mnt/ext/opt/netmgr/util/lock_timer.sh: line 38: 1477764617-: syntax error: operand expected (error token is "-")

Around the line 38 there is this:

Code: Select all

# Timeout handler of API Service Daemon (ASD)
if [ -f "/etc/config/cmd_timestamp" ]; then
	old_time=$(cat /etc/config/cmd_timestamp)
	new_time=$(date +%s)

[b]	if [ $(($new_time-$old_time)) -gt 180 ]; then            # line 38[/b]
		echo "ASD timeout"
		kill -9 $(cat /tmp/asd.pid)
		/mnt/ext/opt/Python/bin/python /mnt/ext/opt/netmgr/api/core/asd.py &
		echo $! > /tmp/asd.pid
		rm /etc/config/cmd_timestamp
	fi
fi

So if there is the file /etc/config/cmd_timestamp and it is empty, it crashes the script. And it was my case. I deleted the /etc/config/cmd_timestamp (which the scipt would otherwise do anyway) and it now runs fine. Don't quite understand the point of it, as the other Qnap NASes do very well without it, but ok.

4. Earlier in this thread was mentioned another crontab entry:

Code: Select all

0-59/10 * * * * /etc/init.d/storage_usage.sh

It runs every ten minutes but IMHO if there is no change in disk usage, it lets the disk in standby. The timestamps of the files to be written by storage_usage.sh are maintained for hours in my case.

[Robert_73]

I have exactly the same issue on 20161021 and 20161028 builds on my 253 Pro. Also there is issue with AFP privileges on those builds - cannot use TimeMachine - can read and verify existing backup but it is impossible to start new. Reverting to 20160901 cures all issue. Already sent ticket to Qnap but till now didn't receive anything from them

[mmicha]

I've been quite desperate to pin this down. I came to some obs.......I tried to run the script manually and there was an error:

Code: Select all

/mnt/ext/opt/netmgr/util/lock_timer.sh: line 38: 1477764617-: syntax error: operand expected (error token is "-")

Around the line 38 there is this:
.....

nice...

Seems it is realy a problem within the netmgr ( Network and virtuall Switch ). Possible they use a script which run a programm as a service ( asd.py ) . This script create/fill this timestamp file - but also not sure.

I think there is a bug within the mentioned script. There is no default value if file is empty. Possible also the file should simple not exist as you mentioned

If we would simple do nothing if file not exist or file is empty , then following simple change would be the fix :

replace:
if [ -f "/etc/config/cmd_timestamp" ]; then

with:
if [ -s "/etc/config/cmd_timestamp" ]; then

Regards,
Michael

[dolan.m]

Well, it would certainly make the code more foolproof, but it has nothing to do with the lack of ability to of the disk to sleep. I corrected the obvious error in the code with a workaround (removed the timestamp file) but still the disks run all the time.

[fatnasa]

i am facing the same issue with TVS-1282

[manny2003]

Same problem with spin down here with my HS-251+ after updating to 20161021 from 20160812 that was working ok.
Same kjournald and setcfg discovered in the traces from blkdevMonitor.

Hope there will be a fix to this!
Many thanks @dolan.m for his deep investigation.

Update:
There is a new 20161102 release of the firmware but unfortunately this does not fix the spin down issue

[kugelkopf]

if you're not using a wireless connection, there is a temp. workaround to fix it.
this has to be applied after every reboot:

1. open /etc/init.d/network.sh
2. find: patch_wireless_conf #FIXME: this is a workaround
3. add a # to the line to look like this: #patch_wireless_conf #FIXME: this is a workaround

regards

Original Post: viewtopic.php?f=55&t=127182&start=15



in combination with:

I've been quite desperate to pin this down. I came to some obs.......I tried to run the script manually and there was an error:

Code: Select all

/mnt/ext/opt/netmgr/util/lock_timer.sh: line 38: 1477764617-: syntax error: operand expected (error token is "-")

Around the line 38 there is this:
.....

nice...

Seems it is realy a problem within the netmgr ( Network and virtuall Switch ). Possible they use a script which run a programm as a service ( asd.py ) . This script create/fill this timestamp file - but also not sure.

I think there is a bug within the mentioned script. There is no default value if file is empty. Possible also the file should simple not exist as you mentioned

If we would simple do nothing if file not exist or file is empty , then following simple change would be the fix :

In:

Code: Select all

/mnt/ext/opt/netmgr/util/lock_timer.sh

replace:
if [ -f "/etc/config/cmd_timestamp" ]; then

with:
if [ -s "/etc/config/cmd_timestamp" ]; then

Regards,
Michael

Original Post: viewtopic.php?f=55&t=126958


worked for me perfectly! Thanks for this!

But is there an option for keeping this "FIXME" thing permanantly? Because i dont wont to fix it every time i reboot.

Can somebody help me with this?

[FrankChutsky]

I have QNAP TS-451 running 4.2.2 Build 20161102. I made the changes to the above scripts from Ben_beton and dolan.m:

/etc/init.d/network.sh
/mnt/ext/opt/netmgr/util/lock_timer.sh

NAS is still constantly accessing disks making a racket (waited an hour w/ no connected devices). Are there additional steps that must be taken to make the above changes take effect? I am not a linux guy...sorry

[kugelkopf]

I have QNAP TS-451 running 4.2.2 Build 20161102. I made the changes to the above scripts from Ben_beton and dolan.m:

/etc/init.d/network.sh
/mnt/ext/opt/netmgr/util/lock_timer.sh

NAS is still constantly accessing disks making a racket (waited an hour w/ no connected devices). Are there additional steps that must be taken to make the above changes take effect? I am not a linux guy...sorry

Have you checked this:
https://helpdesk.qnap.com/index.php?/Kn ... andby-mode

Try the diagnostic program there to find out what you nas do.

[FrankChutsky]

Yes I read that article and I ran the diagnostic and sent it to qnap - haven't heard anything back....

I decided to replace my existing firmware (4.2.2 20161102) with 4.2.2. 20160901. and my NAS now spins down when not in use - much quieter.

Thanks everyone for contributing to this forum!!

[ElectronKing]

I detected this issue back in October (before this tread was even started) and was working with a Qnap tech trying to demonstrate they had an issue with the latest [then subsequent] firmware. After he was finally convinced, he said he would escalate the issue to the firmware guys.

He contacted me today stating the issue has been resolved as of the newest release of the firmware (4.2.2 1208). Haven't tested it myself yet but intend to do that ASAP. Just wanted to let you guys know.

Thanks to Andy at Qnap tech support for following this through and hopefully coming to a resolution.

Cheers!