TS-453BE does not enter standby after FW 4.4.3.1354 update

[WilNasU]

After 4 weeks support my new TS-453BE entered the first time in to standby mode.
Unfortunately after Firmware 4.4.3.1354 and app update I encounter the same again: The NAS does not enter standby mode. It is just burning energy, entertaining the HDs and is noisy (HDs).

Former support session:
- I did read this article: https://www.qnap.com/en/how-to/faq/arti ... ndby-mode/
- I followed the support advices from the first support session: Switching off all applications, disconnect the NAS from the network (for 2 days) and starting the disk standby debug
loop: for (( i=1; i<=30; i=i+1 )); do ./Disk_Standby_Debug --file 300 ; echo -----${i}------;sleep 300; done 2>&1 | tee /tmp/Standby_test.log
But as in the first session after the echo: Last file access: the “for loop” hangs and the out-put file is 0 bytes long.
- From the remote session I had no feedback but somehow it worked after 4 weeks.

The main reason changing to a new NAS was that my old one has no standby mode. But now unfortunately the QNAP does not enter and is even burning more energy as the disks are almost continuously active.

Meanwhile I checked the contab and found entries like:
0-59/15 * * * * /etc/init.d/nss2_dusg.sh backup of surveillance station
0-59/10 * * * * /etc/init.d/storage_usage.sh ??
*/10 * * * * /sbin/config_cache_util 0 ??
33 * * * * /sbin/qddns_check 2>/dev/null ??
Do the listed jobs stop the NAS to enter standby? Should I disable the commands as they run in short intervals?
I did set the standby time out to 15 min.!

Appreciate help to fix the standby issue, as the system burns energy for nothing and is rather noisy.

[WilNasU]

Meanwhile I followed the topic viewtopic.php?f=55&t=154344
and stopped the syslog server. I stopped also all apps again but no change the thing does not enter standby.
There are so many topics on the net about QNAS standby that I get lost what to do.
I just wanted a simple NAS to access data and save energy when not used. Unfortunately only the first point is valid.
Maybe QNAO should offer two configurations: Home with power safe mode as default and business!
Any succession what to stop based on the blkdevMonitor_v2.log log?

============= 25/100 test, Tue Aug 4 11:40:18 CEST 2020 ===============
<<7>[10514.413753] md9_raid1(2422): WRITE block 1060216 on unknown-block(8,16) (1 sectors)
<7>[10514.413782] md9_raid1(2422): WRITE block 1060216 on unknown-block(8,0) (1 sectors)

============= 26/100 test, Tue Aug 4 11:40:52 CEST 2020 ===============
<7>[10604.195830] rsyslogd(9234): dirtied inode 19928 (kmsg) on md9

============= 27/100 test, Tue Aug 4 11:42:23 CEST 2020 ===============
<7>[10713.957924] jbd2/md9-8(2435): WRITE block 632448 on unknown-block(9,9) (8 sectors)

============= 28/100 test, Tue Aug 4 11:44:11 CEST 2020 ===============
<<<<<7>[10724.364907] jbd2/md9-8(2435): WRITE block 632456 on unknown-block(9,9) (8 sectors)

============= 29/100 test, Tue Aug 4 11:44:22 CEST 2020 ===============
<7>[10789.867949] jbd2/md9-8(2435): WRITE block 616472 on unknown-block(9,9) (8 sectors)
<7>[10789.940773] jbd2/md9-8(2435): WRITE block 536776 on unknown-block(9,9) (8 sectors)

============= 30/100 test, Tue Aug 4 11:45:27 CEST 2020 ===============
<<<<7>[11030.215755] md9_raid1(2422): WRITE block <<<<<<7>[11031<<

============= 31/100 test, Tue Aug 4 11:49:29 CEST 2020 ===============
<<<7>[11045.321936] jbd2/md9-8(2435): WRITE block 622480 on unknown-block(9,9) (8 sectors)

============= 32/100 test, Tue Aug 4 11:49:42 CEST 2020 ===============
<7>[11054.850757] gen_band<7>[11055.404923] jbd2/md9-8(2435): WRITE block 622496 on unknown-block(9,9) (8 sectors)

============= 33/100 test, Tue Aug 4 11:49:52 CEST 2020 ===============
<<<<7>[11062.464878] rsyslogd(9234): dirtied inode 19928 (kmsg) on md9

============= 34/100 test, Tue Aug 4 11:50:02 CEST 2020 ===============
<<<<7>[11115.904776] md9_rai<<<<<7>[11116.915767] hal_enc_fan(2584): dirtied inode 1723436 (em_0.inf~) on tmpfs
<<<<<<7>[11118.997531] md9_raid1(2422): WRITE block 10<

============= 35/100 test, Tue Aug 4 11:50:58 CEST 2020 ===============

[WilNasU]

Today I switched off also the last active app Qboost and restarted blkdevMonitor.
It looks like that rsyslogd still blocks entering standby even I “stopped” it via Control Panel / Applications / Syslog Server!

Protokol
[~] # /root/blkdevMonitor_20151225.sh
===== Welcome to use blkdevMonitor_v2 on Mon Aug 10 09:08:54 CEST 2020 =====
Stop klogd.sh daemon... Done
Turn off/on VM block_dump & Clean dmesg
Countdown: 3 2 1
Start...
============= 0/100 test, Mon Aug 10 09:09:02 CEST 2020 ===============
<<7>[ 1470.339276] md1_raid1(2687): WRITE block 7794127<
============= 1/100 test, Mon Aug 10 09:10:07 CEST 2020 ===============
<<7>[ 1778.061408] rsyslogd(24466): dirtied inode 19928 (kmsg) on md9
<7>[ 1778.061431] rsyslogd(24466): dirtied inode 19928 (kmsg) on md9
============= 2/100 test, Mon Aug 10 09:15:14 CEST 2020 ===============
<7>[ 1832.8<7>[ 1833.842445] jbd2/md9-8(2437): WRITE block 843064 on unknown-blo ck(9,9) (8 sectors)
============= 3/100 test, Mon Aug 10 09:16:10 CEST 2020 ===============
<7<7>[ 1896.560439] rsyslogd(24466): dirtied inode 19928 (kmsg) on md9
============= 4/100 test, Mon Aug 10 09:17:13 CEST 2020 ===============
<<<<<7>[ 2019.521384] rsyslogd(24466): dirtied inode 19928 (kmsg) on md9
============= 5/100 test, Mon Aug 10 09:19:17 CEST 2020 ===============
<7>[ 2143.661438] jbd2/md9-8(2437): WRITE block 875136 on unknown-block(9,9) (8 sectors)
============= 6/100 test, Mon Aug 10 09:21:20 CEST 2020 ===============
<7>[ 2235.707451] jbd2/md9-8(2437): WRITE block 1056168 on unknown-block(9,9) (8 sectors)
============= 7/100 test, Mon Aug 10 09:22:52 CEST 2020 ===============
<<7>[ 2254.819277] md9_raid1(2424): WRITE block 1060216 on unknown-block(8,16) ( 1 sectors)
<7>[ 2254.819307] md9_raid1(2424): WRITE block 1060216 on unknown-block(8,0) (1 sectors)
<<<7>[ 2254.867277] md9_raid1(2424): WRITE block 1060232 on unknown-block(8,0) ( 1 sectors)

Further I checked the PID’s 2424 and 24466 to find out the process name with the command:
ls /proc/2424 or /24466. But I got not the expected information!

[~] # ls /proc/2424
auxv comm environ gid_map map_files/ mounts oom_adj personali-ty sessionid stack syscall wchan
cgroup coredump_filter exe@ io maps mountstats oom_score pro-jid_map setgroups stat task/
clear_refs cpuset fd/ limits mem net/ oom_score_adj root@ smaps statm timerslack_ns
cmdline cwd@ fdinfo/ loginuid mountinfo ns/ pagemap schedstat smaps_rollup status uid_map

Appreciate any help to stop rsyslogd and how to use the ls /proc/2424 command.

[OneCD]

Further I checked the PID’s 2424 and 24466 to find out the process name with the command:
ls /proc/2424 or /24466. But I got not the expected information!

[~] # ls /proc/2424
auxv comm environ gid_map map_files/ mounts oom_adj personali-ty sessionid stack syscall wchan
cgroup coredump_filter exe@ io maps mountstats oom_score pro-jid_map setgroups stat task/
clear_refs cpuset fd/ limits mem net/ oom_score_adj root@ smaps statm timerslack_ns
cmdline cwd@ fdinfo/ loginuid mountinfo ns/ pagemap schedstat smaps_rollup status uid_map

Appreciate any help to stop rsyslogd and how to use the ls /proc/2424 command.

I can't (and won't) help with the drive standby issue.

But regarding your usage of 'ls', the default is to list all filenames one-after-another. It's not a very informative display.

If you'd like a more usable file-list, try 'll':

Code: Select all

ll /proc/2424

And for more information about that process, examine the 'cmdline' file. This file exists for every process:

Code: Select all

cat /proc/2424/cmdline

[WilNasU]

Thanks for feedback. I appreciate it very much.
Meanwhile I have executed the proposed commands and stopped rsyslog per command:

[~] # /etc/init.d/rsyslog.sh stop
Shutting down rsyslog: OK
Starting rsyslog for only klog: OK

But unfortunately 2494/2481 is still active:

[~] # cp /share/Public/blkdevMonitor_20151225.sh /root
[~] # chmod +x /root/blkdevMonitor_20151225.sh
[~] # /root/blkdevMonitor_20151225.sh
===== Welcome to use blkdevMonitor_v2 on Thu Aug 13 11:08:00 CEST 2020 =====
Stop klogd.sh daemon... Done
Turn off/on VM block_dump & Clean dmesg
Countdown: 3 2 1
Start...
============= 0/100 test, Thu Aug 13 11:08:07 CEST 2020 ===============
<7>[ 8571.738115] jbd2/md9-8(2494): WRITE block 604688 on unknown-block(9,9) (8 sectors)
============= 1/100 test, Thu Aug 13 11:08:36 CEST 2020 ===============
<7>[ 8622.135177] jbd2/md9-8(2494): WRITE block 604792 on unknown-block(9,9) (8 sectors)
============= 2/100 test, Thu Aug 13 11:09:26 CEST 2020 ===============
<<7>[ 8782.710140] rsyslogd(7980): dirtied inode 19928 (kmsg) on md9
============= 3/100 test, Thu Aug 13 11:12:07 CEST 2020 ===============
<7>[ 8810.857016] md9_raid1(2481): WRITE block 1060216 on unknown-block(8,32) (1 sectors)
<7>[ 8810.857046] md9_raid1(2481): WRITE block 1060216 on unknown-block(8,16) (1 sectors)
<7>[ 8810.857055] md9_raid1(2481): WRITE block 1060216 on unknown-block(8,48) (1 sectors)
<7>[ 8810.857065] md9_raid1(2481): WRITE block 1060216 on unknown-block(8,0) (1 sectors)


Next I started this 2 commands to find out which process is still preventing shutdown:
ll /proc/2481
cat /proc/2481/cmdline
But unfortunately I don’t get the process name or info:
/bin/ls: cannot read symbolic link /proc/2481/exe: No such file or directory
total 0

How can I find out which process is running behind the ID 2494 and 2481?
Thanks for help.

[OneCD]

How can I find out which process is running behind the ID 2494 and 2481?

Read-up on the 'pstree' command. You may need to install Entware first.

[WilNasU]

Thanks for feedback. It looks like it is getting out of my scope.
For a last time I did also run SOP (Disk Standby Issue for arm_marvell) and only after step 12, 13, 14 the thing is entering standby.
As it started with the download of FW 4.4.3.1354 it is in my view a FW problem and this is out of users scope.
I just wonder that power saving is still written in small letters after so many NAS years.

[WilNasU]

Just for information:
After the FW-update to v4.4.3.1400) and Multimedia Console update to v1.1.5 is the NAS entering standby again.

[dolan.m]

Not for me. Every second a seek, regular as clock. One container in container station, most of the time sleeping like a baby. No other apps, just on demand file sharing. Last time I discussed this and shared a solution here viewtopic.php?f=354&t=123933&p=699806#p697623.
I even don't hunt spindown anymore, I just demand there's no permanent disk I/O activity with ABSOLUTELY NO value. Which is not fulfilled by Qnap. Some of the QTS (or embedded apps) functions are implemented so that they are executed in DEBUG mode which makes them write every piece of s**t to their logs. Sorry for the language but if the apps are not ready for production (an need be "debugged"), Qnap, just don't deploy them in production. If they are properly tested, run them in production (no "debug") mode. They may otherwise poorly designed but I don't care, just let them make unnecessary actions in-memory.
So, to the point: my solution mentioned above ceased to work after an upgrade to 4.4.3.1400. For some reason Multimedia station (however disabled in QTS) is running like this (just approximate ps listing):

Code: Select all

ps | grep media
25880 admin      2532 S   /usr/sbin/SCREEN -dmS MYTRANSCODE /usr/local/medialibrary/bin/mytranscodesvr -debug -db /share/CACHEDEV1_DATA/
25882 admin     11164 S   /usr/local/medialibrary/bin/mytranscodesvr -debug -db /share/CACHEDEV1_DATA/
26541 admin      5864 S   /usr/local/medialibrary/bin/mymedia_cli -d

Killing these processes doesn't work, they restart immediately.
For some reason even container station also makes some access to disk with no real "business" value which has been solved by my guide viewtopic.php?f=354&t=123933&p=699806#p697623.
And moreover, for some reason blkdevMonitor.sh is not working for me after upgrade to new disks (WD Ultrastar).