SCALE 23.10.1 preliminary test issues

[SayHeading]

Aware that spindown_timer.sh is not confirmed to be compatible with TrueNAS SCALE 23.10.1 but I tried and (so far…) failed.

Some observations:

(4 disks installed; 3data (tank/SATA HDD) + 1system SSD (boot-pool with system dataset/SATA SSD on USB))

Using disk names in automatic mode (e.g. -i sdd; where sda, sdb, sdc are data disks and sdd is the boot-pool) is problematic, as I observed that a reboot of TreuNAS SCALE sometimes messed up the disk names, here the boot-pool was observed to be sdd or sdc sometimes. I assume that this might be caused by how the disks are activated during boot and could probably be solved by using names iso identifiers for the spindown_timer.sh command.

But automatic mode -i boot-pool resulted in a report stating that the boot-pool was still monitored. Monitoring drives with a timeout of 900 seconds: sda sdb sdc sdd.

Manual mode -m -i tank seems to do the trick. Monitoring drives with a timeout of 900 seconds: tank

But in the end spindown/shutdown is not yet working here, I might mess up the correct path to the script, as it now resides in /home/admin/scripts as you can see on the attached terminal screenshot. The difference to CORE and it’s file directory might be my issue (and my innocence of it…).

I used /home/admin/scripts/spindown_timer.sh -t 900 -p 600 -m -i tank -s 1800 as command. Would that be okay? Or does the message [ERROR] : No supported disk parameter tool found. point towards something?

And then finally, just discovered (while typing this text) during the manually (via ssh) started script ./spindown_timer.sh: line 586: shutdown: command not found as you also can see in the screenshot.

[ngandrass]

Thanks for your detailed report :+1:

I used /home/admin/scripts/spindown_timer.sh -t 900 -p 600 -m -i tank -s 1800 as command. Would that be okay?

Your command looks fine, though I'd set the idle timeout (-t) to the same value as your shutdown timer (-s) since you are shutting down the system after just 30 minutes of idling anyway. But that's just personal preference :)

And then finally, just discovered (while typing this text) during the manually (via ssh) started script ./spindown_timer.sh: line 586: shutdown: command not found

This shows the problem pretty well: Please run the script as root. It looks like your admin user does not have the required privileges to perform spin down or shutdown operations ;)

[SayHeading]

(...)I'd set the idle timeout (...). But that's just personal preference :)

Ah, these are only settings for the evaluation phase, not serious figures :-)

This shows the problem pretty well: Please run the script as root. It looks like your admin user does not have the required privileges to perform spin down or shutdown operations ;)

Okay, so after I enabled root to have password access and ssh (what Cobia doesn´t allow as default) manually starting the script via terminal seems to work, but there is now a new issue:

Looks like tank is not sufficient to spin all 3 drives down. But I´ll give it another trial with drive names and the boot-pool connected to SATA directly to have stable numeration.

But what is more important: When using the GUI to implement the script, does it matter who does it (logged in) , admin or root? As from the interface it doesn't give me other options to do so. Or is there something that has to be added to the GUI command to clarify it has to be applied with root privileges?

[SayHeading]

...first update, boot device now directly attached to SATA, using disk names as displayed in TrueNAS GUI (aka identifier) in auto mode. Running script via terminal as root (disabled script in GUI). But still no joy, shutdown: invalid option -- 'p'

And still - although with the boot device now on SATA directly iso USB to SATA enclosure - do the device identifier/names change from reboot to reboot. Not a script issue, but one for the script user who monitors devices by identifier.

Cross check with -u zpool covers the changing disk identifier.

[Salvoxia]

Yes, the Debian shutdown command does not recognize the -p argument as FreeBSD does. The same result (Halt or Power off after shutdown) can be achieved with -h under Debian based systems. The script would somehow need to distinguish between these two.

The disk device names changing between boots is a known behavior in TrueNAS Scale. AFAIK nothing you can do about that.

Side question because I have problems with that: If a drive is spun down for you, does it stay that way for a prolonged period of time without waking up "on its own"?

[SayHeading]

The disk device names changing between boots is a known behavior in TrueNAS Scale. AFAIK nothing you can do about that.

Good to know it's not my hardware so I can revert using an USB->SATA attached boot drive to save SATA ports if needed. And using -u zpool instead is a usable option, but it would be worth emphasizing the possible issue in the user instructions.

Side question because I have problems with that: If a drive is spun down for you, does it stay that way for a prolonged period of time without waking up "on its own"?

Wasn't able to test that yet in prolonged period, as our electricity will be shut down soon during the afternoon. Up to know I just have a short time window of 30 minutes to report, where the disks were sleeping before I now have to shut down the system. I'll try again once power is up again.

In the meanwhile - but that is now explained by your comment - I could report that adding the script via the GUI as root spun the disks down, but caused no shutdown.

Update - as power is still up ;-)

Without the slightest clue what I'm doing there, but I opened Niel's script and found in line 586 shutdown -p now. Would it be a simple replacement by -h ? Will try anyway, but still awaiting the blackout...

Update - power still up

-h did the trick - thanks a lot, @Salvoxia ! And I'll test the disks' sleep, but not before the blackout happened, have to seriously shut my stuff down now...

[ngandrass]

Thanks for further investigating :)

And using -u zpool instead is a usable option, but it would be worth emphasizing the possible issue in the user instructions.

Yes, when you want to use zpool names instead of device names you need to switch from -u disk (default) to -u zpool, as described in the help text (-h) and README.

Regarding the device identifier problem: I could add a note about this to the README file. However, nowadays most people seem to use SCALE anyway and therefore potentially face this problem. Wouldn't it be better to make the zpool mode the default, replacing the "fragile" disk device identifiers?

Yes, the Debian shutdown command does not recognize the -p argument as FreeBSD does. The same result (Halt or Power off after shutdown) can be achieved with -h under Debian based systems. The script would somehow need to distinguish between these two.

I should be able to distinguish between both somehow. The script already does this for camcontrol/hdparm.

[SayHeading]

...so, back up again...

Side question because I have problems with that: If a drive is spun down for you, does it stay that way for a prolonged period of time without waking up "on its own"?

The disks stayed spun down for the last few hours (only manually/acoustically confirmed). Scale Cobia is a fresh vanilla install without anything else running beyond the shutdown_script and one defined share which of course wasn't used.

[Salvoxia]

The disks stayed spun down for the last few hours (only manually/acoustically confirmed). Scale Cobia is a fresh vanilla install without anything else running beyond the shutdown_script and one defined share which of course wasn't used.

Thanks for reporting back. Just to be sure: Do you have the S.M.A.R.T. service enabled and running in System Settings-> Services, and if so, is S.M.A.R.T. enabled for the disks you tested spindown with? My disks keep waking up at latest 30s after spindown, which I guess is a good way to an early grave...

[SayHeading]

Yes, it is enabled and running (also SMB and SSH), all 3 disks that shall spin down have the same settings:

[SayHeading]

This shows the problem pretty well: Please run the script as root. It looks like your admin user does not have the required privileges to perform spin down or shutdown operations ;)

Just one note on this one. This is the default 'admin' that Cobia creates during initial install, I did not change anything for that user. I startet my journey into NAS with this version but I think I read that this recommended setup was first introduced with Cobia? And if yes, is that something that has to be considered when setting up Init Scripts like your's? Does it matter who - root or admin - does define a command via the GUI? Your answer seems to cover the ssh/terminal case, but would it affect the GUI behaviour also?