Scheduled HDD fix script needs a reboot

[MikeyMan83]

Just dit my first firmware update after starting to use SSDs as storage.

So i added the scripting through the scheduler. Basically it works.
Only thing i'm wondering; is it possible to do a reboot if some of the fixes have applied?

Had to do a manual reboot now, which is a bit of an inconvenience.

Also container manager failed... Got it restored, but its completely cleared out now...

[007revad]

If your Container Manager was installed on your NVMe volume Package Center probably "repaired" Container Manager to the HDD volume when the NVMe volume was missing. To prevent things like happening after a DSM major update I've written a script, syno_hdd_shutdown.sh, that you schedule to run as root at shutdown to stop all packages installed on NVMe volumes. It creates a log of the packages it stopped. Eventually I'll update syno_hdd_db.sh to:

1. Check if the log of stopped packages exists.
2. Check if the NVMe volume(s) that the packages in the log are installed on is mounted.
3. If yes to 1 and 2 then start those packages.

To fix Container Manager we probably just need to:

1. Stop Container Manager.
2. Edit the symlink that points to @docker

Does this command return the HDD volume or the NVMe volume?

readlink /var/packages/ContainerManager/var/docker

It's easy to do a reboot via SSH but it's not ideal. It can cause unsafe shutdown messages. But in DSM 7 it's only needed if certain fixes have been applied.

The problem with the script automatically rebooting when needed is if something went wrong the NAS could get stuck in a never ending reboot loop.

[MikeyMan83]

Reinstalling container manager to volume2 did fix it.

Might not be the best idea to have everything on volume2 probably. Theres a downside that comes with the speed increase.

Good arguments on the reboot though!

[MikeyMan83]

Only thing that did go tits up is hyper backup. Lost its tasks. Might be better to keep that on volume 1.

[MikeyMan83]

@007revad Might be a good advice to only move applications that are safe at reboot and benefit from the performance to the ssd volume?

I currently have:
[Installed package list]

1. /volume1 Antivirus Essential
2. /volume1 @database
3. /volume1 Glacier Backup
4. /volume1 Hyper Backup
5. /volume1 Log Center
6. /volume2 Advanced Media Extensions
7. /volume2 Container Manager
8. /volume2 Emby Server
9. /volume2 Mosquitto
10. /volume2 Node.js v20
11. /volume2 Surveillance Station
12. /volume2 Surveillance Video Extension
13. /volume2 Synology Application Service
14. /volume2 Synology Drive Server
15. /volume2 Synology Photos
16. /volume2 Transmission
17. /volume2 Universal Viewer
18. /volume2 Virtual Machine Manager
19. /volume2 WebDAV Server
    Select the package to move:

Hyper backup lost all its data during the move. And apart from that not all applications might benefit from the move?

[007revad]

I would only move packages that would benefit from the speed of an NVMe drive. Like Drive, Plex, jellyfin, Emby, Container Manager and VMM. Mainly packages that have a database.

It's the DSM updates that break packages on 3rd party NVMe volumes.

Immediately after the DSM update's reboot the scheduled boot-up tasks have not run yet. So the 3rd party NVMe volume is missing and any packages installed there show as needing "repair". DSM then "repairs" those packages by re-installing them on the HDD volume. This only happens if the package was running when DSM shut down - e.g. DSM does not start packages that were previously stopped.

To avoid this I have written a small script to be scheduled to run at shut down as root that stops all packages that are installed on an NVMe volume and creates a log which packages it stopped. It's named syno_hdd_shutdown.sh and included in syno_hdd_db v3.6.115 and v3.6.116

I intend to add code to syno_hdd_db to check if the shutdown log file exists and if it does:

1. Check if the NVMe volume or volumes the logged packages are installed on is mounted and accessible.
2. If step 1 was okay then start those packages.

This way if the NAS needs another reboot to get the NVMe volume(s) back those packages won't be started until after that 2nd reboot.

I tested syno_hdd_shutdown.sh on my DS925+ when I updated to DSM 7.3.2 and none of my NVMe packages got broken by DSM "repairing" them.

I should also make syno_hdd_db check if there are packages installed on a 3rd party NVMe volume, then check if syno_hdd_shutdown.sh is scheduled to run as root at shut down. If it's not syno_hdd_db should advise the user how and why to schedule syno_hdd_shutdown.sh

[007revad]

I decided to add a reboot option. It's almost finished.