Synology DonwloadStation blocklist update script

synology-blocklist-update

#!/bin/bash
set -euo pipefail

BLOCKLIST_URL='https://list.iblocklist.com/?list=bt_level1&fileformat=p2p&archiveformat=gz'
BLOCKLIST_FILE=/var/packages/DownloadStation/etc/download/blocklists/level1

echo "Clean old blocklist"
rm -f $(dirname $BLOCKLIST_FILE)/*

echo "Download new blocklist"
curl -sSLf --retry 10 --retry-delay 60 --max-time 30 "$BLOCKLIST_URL" \
        | gzip -cd - \
        | sed -e '/^\s*#/d' -e '/^\s*$/d' \
        > $BLOCKLIST_FILE

# patch configuration & service files that might be overwritten after a package update:
# - enable blocklists in transmissiond config file
# - prevent this config file to be deleted by the service's startup script
echo "Patch service files"
sed -i /var/packages/DownloadStation/etc/download/settings.json \
        -e 's/\(^\s*"blocklist-enabled"\s*:\)[^,]*/\1 true/' \
        -e 's/\(^\s*"blocklist-url"\s*:\)[^,]*/\1 ""/'
sed -i /var/packages/DownloadStation/scripts/start-stop-status \
        -e 's|\(^\s*rm .\+/settings.json\s*$\)|#\1|'

echo "Restart DownloadStation"
#synoservicectl --restart pkgctl-DownloadStation
/var/packages/DownloadStation/target/scripts/S25download.sh restart

echo "Verify that the blocklist file was loaded by transmissiond"
sleep 10  # wait for transmissiond to finish starting up
[ -s "$BLOCKLIST_FILE".bin ] \
    || { echo "Missing bin file: blocklist was not loaded by transmissiond"; exit 1; }
# transmissiond logfile: /var/services/download/transmissiond.log

Hi @olbat, got exactly the same issue than @nexttoyou
I do a vi /etc/block.sh and a chmod +x /etc/block.sh

Then task scheduler with bash /etc/block.sh
as root : could not change directory to "/root": Permission denied
as admin results in sed: can't read /var/packages/DownloadStation/etc/download/settings.json: Permission denied
directly into ssh : curl error 16

Regards

However, I confirm that script downloads because after removing level1 and level1.bin, a ls command in the dir after execute the script shows the 2 files again.
But don't know if errors about permissions prevents the script to be efficient.

Tâche : Blocklist
État actuel : 0 (Normal)
Sortie standard/erreur :
Clean old blocklist
Download new blocklist
Patch service files
Restart DownloadStation
Stopping scheduler ...
131 (process ID) old priority -20, new priority -5
pgsql is enabled.
Update download queue table and set all pid to -1
test upload_rate in download_queue table
test seeders in download_queue table
could not change directory to "/root": Permission denied
Check current amule version...
No need to upgrade amule.conf...
test destination column in download_queue table
test rss_feed table in download db
test uid column in user_setting table
test enable_watchffolder column in user_setting table
test unzip_password column in download_queue table
test unzip_progress column in download_queue table
test is_regex column in rss_filter table
test task_plugin table in download db
test thumbnail table in download db
test thumbnail_status column in download_queue table
test completed_time column in download_queue table
test waiting_until_time column in download_queue table
test colume one in view test_filter_view
test aftertaskdeleted trigger function
could not change directory to "/root": Permission denied
test given_filename, referer, cookie_path column in download_queue table
test torrent_oid column in download_queue table
test notification table in download db
test if notification_view
test task trigger function
could not change directory to "/root": Permission denied
CREATE FUNCTION
could not change directory to "/root": Permission denied
test if function lo_unlink_non_raise is defined
Starting Download Station scheduler daemon ...
131 (process ID) old priority -5, new priority -20
Verify that the blocklist file was loaded by transmissiond

Again, it looks that you all have an issue with the script's runtime environment.
Please make sure that the script is executable and being run with a user that has the relevant access.

Don't remember if script was loaded directly from the scheduler or via .sh but if 2nd case it have been chmod. And root in my case and case of @nexttoyou.
No issue from the other script where I found your comment.
Regards.

Just look at the script, every single paths are fully qualified. The script doesn't assume that you run it from a specific directory. Again it's just a matter of runtime environment and user permissions.