Synology DSM 7+ Fixes

[johnnyxmas]

Add DSM 7+ Notifiarr install and uninstall scripts with log rotation and Entware support

• Installer auto-detects architecture (x86_64 / aarch64)
• Installs zstd via opkg (Entware) (Notifiarr no longer supplies tar.gz files for Synology architectures)
• Installs latest Notifiarr release from GitHub
• Redirects logs to /volume1/data to avoid disk quota issues
• Adds weekly log rotation (4 compressed backups)
• Creates DSM boot startup script and cron-based updater
• Includes uninstall script to fully remove all components -Updated README with new installation instructions

The old install-synology.sh script has been renames install-synology-dsm6.sh. NOTE: It is semi-broken (persistence does not work) as it relies on systemd functionality which DSM 6 (nor 7) does not have. This is NOT fixed in this commit.

[davidnewhall]

Thank you for this. Left a few comments. I do not have a syno and will need nitsua to test this.

[johnnyxmas]

Thanks for this!! I agree this is all valid; just need clarification on the few comments I left above.

FWIW I'm running DSM 7 and have done the install/uninstall several times as a test and things appear to be going well.

[davidnewhall]

I'll try to get @austinwbest to test this. He has a couple Synos, but is on holiday this week.

[davidnewhall]

@bakerboy448 Can you turn this content into a wiki page, so we can link to it from here instead of extend this readme by 40 lines? <3

[johnnyxmas]

Upon further consideration, I think 90% of this info isn't something any user would need, and if they do, it's easy enough to search in the script. I've cleaned up the readme to be more concise.

[davidnewhall]

I'm beginning to think there's a better way.

[johnnyxmas]

Yeah, I caught this too. I'm currently working on it. I'm going prompt during install to have the user enable auto-update if desired. This will create a crontab to call notifiarr.sh update, which will cause the generated notifiarr.sh script to check if the latest release is newer, then download and install it. This also allows the user to still run notifiarr.sh update manually. No additional scripts.

[davidnewhall]

I meant.. a way that doesn't involve hundreds of lines of bash. Like a deb or rpm package. What do we do on syno?

[johnnyxmas]

That's the dream...and the right way to do this, but it's outside of my scope of knowledge. Here are the resources though:

You have to make an SPK package (seems to be a proprietary docker container), then host it in a repo that users can add to their synos. Synology has 2 pinned repos here for each of those tasks. This package development guide is likely also useful.

[johnnyxmas]

In the meantime, this script is working on my end.

[austinwbest]

DSM6 did not support systemd, you are correct. DSM7 introduced it and does which is why the install script has a switch in it. Below is my output for example

DSM 7.2.1-69057 Update 7

austin@best-nas:~$ systemctl status notifiarr
● notifiarr.service - notifiarr - Official Client for Notifiarr.com
   Loaded: loaded (/etc/systemd/system/notifiarr.service; disabled; vendor preset: disabled)
   Active: active (running) since Wed 2025-05-07 19:22:51 EDT; 1 months 7 days ago
 Main PID: 29439 (notifiarr)
   CGroup: /system.slice/notifiarr.service
           └─29439 /usr/bin/notifiarr -c /etc/notifiarr/notifiarr.conf
austin@best-nas:~$

Another NAS i have is DSM 7.2-64570 Update 4 and it works there as well

We originally started this on DSM 6 and it should run there as well via upstart

[davidnewhall]

Hey @johnnyxmas!

Austin and I finally jumped on a call today and discussed this contribution. We also helped a user troubleshoot their DSM 7 syno and get notifiarr running again. That user was able to run the existing script and it updated them correctly.

Our discussion lead to some questions about your contribution.

You mentioned a few things in your initial PR description that I need clarification on. One of the primary new features in DSM 7 is the replacement of upstart with systemd. You said DSM7 has no systemd, so I'm a bit confused on that. Which leads to further confusion because your pull request doesn't create a unit file for systemd. What version of DSM are you running that lacks systemd?

You also mentioned that the existing script is broken, but didn't provide errors or steps to reproduce the error. The existing scripts support DSM 6 and 7 by detecting the version and installing an upstart file or a systemd unit file. I've had no reports of problems and I just witnessed someone use it successfully. Please let me know what problems you had with it.

[johnnyxmas]

Hey, apologies. The issue is more complex than "there is no systemd," and I may have even misspoke in saying that. I'll clear up the final ask first: This all stemmed from me struggling with getting Notifiarr to maintain persistence across reboots or DSM updates. The issue had been going on since I was on 6, and persisted into 7, which is when I decided to start digging in. I, too, thought it was working fine with the existing script, except I noticed reboots and updates would often (always?) cause me to have to manually start the process. I got tired of it and began work on this script that would eliminate the problem.

Now, what I should have said instead of "there is no systemd" is: DSM 7 does not use systemd
While systemctl may exist on some DSM 7 devices, it's typically a stub or partial implementation. Furthermore, DSM 7 does not use systemd to manage services. Instead, Synology uses other control tools:

• BusyBox init
• Proprietary service tooling:
  • /usr/syno/bin/synoservicectl
  • /usr/syno/bin/synopkg
• Hardcoded startup hooks in /etc/rc, /etc.defaults/rc, and /usr/syno/etc.defaults/rc.sysv/

The following are incomplete or ignored in DSM and risk being completely overwritten during DSM upgrades:

• /etc/init.d/exists but is not used by DSM 7
• /etc/rc.local may exist, but is ignored
• systemd unit files (*.service)

For user-installed services, the only reliable (and supported) method is to place the startup scripts in /usr/local/etc/rc.d/<your-script>.sh. DSM7 executes all *.sh scripts in that dir on boot.

Here's the relevant boot process, for clarity:

1. Boot starts from BusyBox init
2. Calls /etc/rc scripts by runlevel (rc.boot, rc.sysinit, etc.)
3. When DSM boots, it eventually calls:
4. /etc/rc and includes /usr/syno/sbin/synoservice
5. That loads Synology-managed services
6. Then /usr/local/etc/rc.d/*.sh gets called

[davidnewhall]

The part I'm interested is the part in parenthesis: and supported. No one's ever reported a problem with notifiarr not starting with the systemd unit file. Perhaps not many people reboot their devices; I know we don't reboot ours ever. Can you tell me where you learned about Synology supported implementations?