[SCRIPT] create-autorun.sh

English General
, , , ,
1

200×137 24.9 KB

Description

This is a run-once BASH script to create an autorun environment on your QNAP NAS. This can be used to automatically execute your own scripts when the NAS boots-up.

The aim of this project is to support all QNAP NAS models and all QTS & QuTS hero versions. Please advise if you encounter any errors when running it on your NAS.

What it does

This installer script writes an autorun.sh processor into your default volume, below the .system directory. It then symlinks this from the DOM back to your default data volume so that it is run on NAS startup. This means you don’t need to load the DOM partition every time you want to change the contents of autorun.sh

The autorun device and partition are automatically determined by this script.

How to create your autorun.sh

curl -skL https://git.io/create-autorun | sudo bash

Notes

  • If you didn’t have an autorun.sh file before, then the autorun.sh file created by this utility will contain a script directory processor, and will make a scripts directory available for your own shell-scripts. Everything in this scripts directory is run (in-order) during NAS startup by the default autorun.sh file created only. The notes below are only applicable to the autorun.sh written by this utility. If you already had another autorun.sh file, then it will remain and be used instead, and the following notes won’t apply.

  • The location of the autorun system will depend on your default volume name. For example: if your default volume is CACHEDEV1_DATA, then the automatic script processor will be created at:

/share/CACHEDEV1_DATA/.system/autorun/autorun.sh

… and the scripts directory will be created at:

/share/CACHEDEV1_DATA/.system/autorun/scripts/
  • autorun.sh is triggered at some point during NAS bootup, which then runs each executable file in the scripts directory in the default filename list order. If you need to run one script before the other, prefix them with a number such as:

10-example.sh 20-example.sh 25-example.sh 30-example.sh

  • A log file is created during autorun.sh execution. It is located at /var/log/autorun.log and contains the date-time and name of each of the executable scripts found in the scripts directory as they were run, along with any stdout and stderr generated by these scripts.

  • The source for this project can be found on GitHub

making a shortcut in /share folder persistent
2

Installation on QTS 5.2.5 works, but if i try to run my scripts i got a “command not found” error. It seams that the autorun.sh is running before all QPKG’s so it does not find related commands. If i run it later manually all is working as expected. A “sleep” command at the beginning has no effect (except the “sleep”).

Best regards …

3

Correct. autorun.sh executes before QPKGs are started.

sleep won’t help as it just holds-up the boot process until autorun has finished, which includes starting QPKGs.

I later created the RunLast QPKG to help workaround this, but it no longer works as of QTS 5.2.0 due to changes made by QNAP to start QPKGs asynchronously.

There’s presently no way to run scripts after startup that rely on QPKGs.

4

This is not quite right.
I have now found a solution by using “RunLast” from the “MyQNAP” repository. I was surprised that it produced the same error at first. So I did a little research. I found out that the QNAP services are not exclusively started asynchronously and especially that they do not always wait for the successful start of the dependencies.
So I modified my start script so that it takes this into account.
This has partly to do with the way QNAP links its binaries and libraries in and out, depending on the installed apps.
For example, “autostart.sh” usually fails because most of the libraries and binaries are not yet “linked”. The same also applies in part to “RunLast”.

But please do not stop developing “RunLast”. It already follows the right approach, especially because of the nice structure of the SysV start scripts. You can get almost anything to run with it if you consider the dependencies of your application on other QPGG’s and steal a little from their start scripts. I have an simple example for my ClamD, which I use for my Xeams:

Best regards,

Mandragor59

***** There are no problems, there are only challenges *****

5 
#!/bin/sh
# Name: /share/CACHEDEV1_DATA/.qpkg/RunLast/init.d/S10-ClamD_Service
# make sure that the daemon creates a clamd.pid file in /var/run and modify Socket and IP in clamd.conf for instream scanning
# Purpose: This script starts, stops, and restarts the ClamD service.
# Author: Mandragor59 (A.Lechte)
# ------------------------------------------------------------------------------
#
# setting ClamAV ENV
#

export QNAP_QPKG=ClamAV
QPKG_NAME=$QNAP_QPKG
QPKG_DIR=`/sbin/getcfg $QPKG_NAME Install_Path -d NULL -f /etc/config/qpkg.conf`

# If not installed do nothing

if [ ! -d ${QPKG_DIR} ]
	then
        exit 1
fi

# Come on, let's go or not 

case "$1" in
  
  start)
	
	echo -n $"Starting ClamAV Daemon: "
	
# Looking at dependencies and linking necessary files (copied from clamav startup)

	/bin/ln -sf ${QPKG_DIR}/usr/lib/libclamav.so.9.0.5 /usr/lib/libclamav.so.9.0.5 >/dev/null 2>&1
    /bin/ln -sf ${QPKG_DIR}/usr/lib/libclammspack.so.0.1.0 /usr/lib/libclammspack.so.0.1.0 >/dev/null 2>&1
    /bin/ln -sf ${QPKG_DIR}/usr/lib/libclamunrar.so.9.0.5 /usr/lib/libclamunrar.so.9.0.5 >/dev/null 2>&1
    /bin/ln -sf ${QPKG_DIR}/usr/lib/libclamunrar_iface.so.9.0.5 /usr/lib/libclamunrar_iface.so.9.0.5 >/dev/null 2>&1
    /bin/ln -sf ${QPKG_DIR}/usr/lib/libfreshclam.so.2.0.1 /usr/lib/libfreshclam.so.2.0.1 >/dev/null 2>&1
    /bin/ln -sf ${QPKG_DIR}/usr/lib/libcharset.so.1.0.0 /usr/lib/libcharset.so.1.0.0 >/dev/null 2>&1
	
    /sbin/ldconfig
    
	/bin/ln -sf ${QPKG_DIR}/usr/local/bin/freshclam /usr/local/bin/freshclam >/dev/null 2>&1
    /bin/ln -sf ${QPKG_DIR}/usr/local/bin/clamscan /usr/local/bin/clamscan >/dev/null 2>&1
    /bin/ln -sf ${QPKG_DIR}/usr/local/bin/sigtool /usr/local/bin/sigtool >/dev/null 2>&1
    /bin/ln -sf ${QPKG_DIR}/usr/local/sbin/clamd /usr/local/sbin/clamd >/dev/null 2>&1
    /bin/ln -sf ${QPKG_DIR}/usr/local/bin/clamscan_cli /usr/local/bin/clamscan_cli >/dev/null 2>&1
    /bin/ln -sf ${QPKG_DIR}/usr/local/bin/clamav_cli /usr/local/bin/clamav_cli >/dev/null 2>&1
    /bin/ln -sf ${QPKG_DIR}/etc/init.d/antivirus_qpkg.sh /etc/init.d/antivirus_qpkg.sh >/dev/null 2>&1

# starting ClamD
	
    /usr/local/sbin/clamd 2>/var/log/clamd.log
	
	echo $"..... done."
	
    ;;
	
  stop)
  
    echo -n $"Shutdown ClamAV Daemon: "
	
	killall -9 clamd
	rm /var/run/clamd.pid >/dev/null 2>&1
	
	echo $"..... done."
	
    ;;

  status)
	
    PROC_PID=`cat /var/run/clamd.pid`
	if [ -e /proc/$PROC_PID/status ]
		then
			cat /proc/$PROC_PID/status | grep State
		else
			echo $"ClamAV Daemon not running !"
	fi
	
    ;;
	
  *)
  
    echo "Usage: $0 {start|stop|status}"
    exit 1
  
	;;

esac
6

No, it’s exactly right. Because there doesn’t currently exist generalised support for running scripts after QPKGs.

Anyone can devise a bespoke solution around a specific package, but that only helps a subset of the community that use that package. :nerd_face:

7

You answered:

“Anyone can devise a bespoke solution around a specific package, but that only helps a subset of the community that use that package.” :nerd_face:

… and therefore it is not QUITE right ! :stuck_out_tongue_winking_eye:

8

Meh… maybe I should argue German language semantics instead? German isn’t my primary language, but following your lead, I shouldn’t let that stop me. :wink: