[SCRIPT] create-autorun.sh

[NiallCon]

OneCD,
Thank you for replying and thank you for your very kind welcome!
I had actually tried to read the good explanation that you suggested but it became a little bit tricky to understand and I didn't think it applied because of the QNAP file system not including rc#.d structure.
So am I correct in thinking that you are suggesting not running my socat command in the autorun.sh (in the scripts sub directory) but instead to run it as part of the Entware init script that you suggested above?

At the moment, when Entware-ng runs, it loads the 'socat' program automatically (don't ask me how I worked out how to do this)....lol. It just starts after the 'autorun.sh' script

Ok, I'm going to see if I can figure out the syntax in your suggested script and insert my command into it.

Thanks once again and I'll let you know how I get on.

Kind Regards,
Niall

[NiallCon]

Ok.
I created a test.sh file in /opt/etc/init.d
I used your script above but included the command I want to execute as follows:

#!/usr/bin/env bash

case "$1" in
start)
# perform your 'start' actions here
# this is where you'll run your 'socat' command
socat -u -T1 UDP-LISTEN:9,fork UDP-DATAGRAM:192.168.2.10:9,broadcast &
;;
stop)
# perform your 'stop' actions here
;;
restart)
$0 stop
$0 start
;;
*)
echo -e "\n Usage: $0 {start|stop|restart}"
;;
esac

I know this isn't right but I want the command to run and stay running, so I don't have any use for the stop/restart actions?
I also chmod'ed the file to make sure it was executable but that's irrelevant if the script doesn't work

Thanks for all your help. I'll have another look at it in the morning. My head hurts

Kind Regards,
Niall

[OneCD]

I had actually tried to read the good explanation that you suggested but it became a little bit tricky to understand and I didn't think it applied because of the QNAP file system not including rc#.d structure.

Yes, QNAP do make use of this structure.

So am I correct in thinking that you are suggesting not running my socat command in the autorun.sh (in the scripts sub directory) but instead to run it as part of the Entware init script that you suggested above?

Correct.

At the moment, when Entware-ng runs, it loads the 'socat' program automatically (don't ask me how I worked out how to do this)....lol. It just starts after the 'autorun.sh' script

Ah, then it sounds like it's running a daemon. Sorry, I've not used it myself. If it only permits a single instance, then you'll have to kill the running one.

I created a test.sh file in /opt/etc/init.d
I used your script above but included the command I want to execute as follows:

Your script looks fine.

I also chmod'ed the file to make sure it was executable but that's irrelevant if the script doesn't work

Agreed.

The next thing to do is to test it. Run that script with:

Code: Select all

/opt/etc/init.d/yourscript.sh start

... then check your process list for 'socat':

Code: Select all

ps | grep socat

[NiallCon]

Hey OneCD (me again!)

I put the test_socat.sh into the /opt/etc/init.d directory. When I run this manually, I get the following:

Code: Select all

[/opt/etc/init.d] # ./test_socat.sh start
 
./test_socat.sh: line 7: socat: command not found

If I look at the processes

Code: Select all

ps | grep socat

21605 admin       980 S   grep socat 

So 'socat' is running as a process. Hmmmm.

[OneCD]

I put the test_socat.sh into the /opt/etc/init.d directory. When I run this manually, I get the following:

Code: Select all

[/opt/etc/init.d] # ./test_socat.sh start
 
./test_socat.sh: line 7: socat: command not found

How's your $PATH look?

Code: Select all

echo $PATH

You should see something like this:

Code: Select all

[~] # echo $PATH
/opt/bin:/opt/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin

I've just installed socat, and it seems to work fine. There is no instance of it in memory after installation, so I don't think it has a daemon:

Code: Select all

[~] # opkg install socat
Installing socat (1.7.3.2-2) to root...
Downloading http://bin.entware.net/x64-k3.2/socat_1.7.3.2-2_x64-3.2.ipk
Configuring socat.

Code: Select all

[~] # socat
2018/04/04 05:03:19 socat[12379] E exactly 2 addresses required (there are 0); use option "-h" for help

Code: Select all

[~] # which socat
/opt/bin/socat

Code: Select all

[~] # socat -V
socat by Gerhard Rieger and contributors - see www.dest-unreach.org
socat version 1.7.3.2 on 1520075158
   running on Linux version #1 SMP Fri Dec 8 04:33:44 CST 2017, release 3.4.6, machine x86_64
features:
  #define WITH_STDIO 1
  #define WITH_FDNUM 1
  #define WITH_FILE 1
  #define WITH_CREAT 1
  #define WITH_GOPEN 1
  #define WITH_TERMIOS 1
  #define WITH_PIPE 1
  #define WITH_UNIX 1
  #define WITH_ABSTRACT_UNIXSOCKET 1
  #define WITH_IP4 1
  #define WITH_IP6 1
  #define WITH_RAWIP 1
  #define WITH_GENERICSOCKET 1
  #define WITH_INTERFACE 1
  #define WITH_TCP 1
  #define WITH_UDP 1
  #define WITH_SCTP 1
  #define WITH_LISTEN 1
  #define WITH_SOCKS4 1
  #define WITH_SOCKS4A 1
  #define WITH_PROXY 1
  #define WITH_SYSTEM 1
  #define WITH_EXEC 1
  #undef WITH_READLINE
  #define WITH_TUN 1
  #define WITH_PTY 1
  #define WITH_OPENSSL 1
  #undef WITH_FIPS
  #undef WITH_LIBWRAP
  #define WITH_SYCLS 1
  #define WITH_FILAN 1
  #define WITH_RETRY 1
  #define WITH_MSGLEVEL 0 /*debug*/

If I look at the processes

Code: Select all

ps | grep socat

21605 admin       980 S   grep socat 

So 'socat' is running as a process. Hmmmm.

Ah, no - this is commonly known as a "gotcha".

Whenever you grep the process list, grep becomes one of those processes. The process list shows the command-line argument list for each process by default on QTS firmware. In short - the result you're seeing there is the search you performed. It's something I tend to ignore automatically, but you can also add a third command to remove that line from your results. Try this instead:

Code: Select all

ps | grep socat | grep -v grep

[Briain]

Code: Select all

ps | grep <stuff> | grep -v grep

Much coolness, Sir! Ages ago, I very crudely 'kluged' my way out of that two-lines issue (this being within an embarrassingly 'M. Mouse' grade script ), but that is a far more elegant way to do it! Hey, there is a reason why we are often called 'radio hams' (a serious disservice to some that I know, but in my case, the latter word clearly being an appropriate one)!

All the best,
Mad McBri

[OneCD]

Thanks Briain.

But I'm still shocked when I look back at some of the 'solutions' I used in my early days too.

[NiallCon]

Ok.
I have an update. It took me a long time to work out what was going on but now I can replicate it.
The error I was getting in relation to the script running above

Code: Select all

./test_socat.sh: line 7: socat: command not found

was because socat wasn't working. socat wasn't working because entware-ng wasn't working. When entware-ng is installed and socat is installed using entware-ng and I run the script manually

Code: Select all

[/opt/etc/init.d] # ./test_socat.sh start

It works perfectly.

BUT if I do nothing and reboot the NAS to see if it will work after a reboot. Entware-ng will not work, I run the 'opkg' command and get

Code: Select all

-sh: opkg: command not found

and therefore socat and the script don't work.


The only way I can fix this is to reinstall entware-ng completely, then install socat. Because I have uninstalled entware-ng, the script gets removed because the /opt/etc/init.d directories are deleted and replaced with empty ones.

So by starting the test_socat.sh manually, it is running well until a reboot. So I am thinking that somehow the test_socat.sh has to be stopped before a reboot and then started again after a reboot.

The script template you very kindly wrote for me does work when I start it manually but how can I start it automatically after a reboot and stop it before the NAS powers off?

By the way, I should mention than before entware-ng becomes disabled (after a reboot) I get the same outputs as you re: $PATH, opkg install socat, #socat, #which socat and ps | grep socat | grep -v grep

Thanks once again for any help or advice. It really had me confused and took me a long time to work out what was going on. My head hurts....again....lol

[OneCD]

* edit: I've just been looking through the Entware init processor (rc.unslung) and realised Entware requires each init script filename to start with a capital 'S' character. Sorry! *

BUT if I do nothing and reboot the NAS to see if it will work after a reboot. Entware-ng will not work, I run the 'opkg' command and get

Code: Select all

-sh: opkg: command not found

and therefore socat and the script don't work.

Entware-ng (in fact, all the Entware versions I've used) are not immediately available after a reboot.

When the NAS boots, it does its various things like loads drivers, mounts volumes, starts services, loads the autorun.sh and then starts loading the QPKGs like Entware-ng. But Entware-ng can take a couple of minutes to finalise its re-integration, even when the NAS appears to have completed its startup.

If you SSH into the NAS during this period, none of the IPKGs or Entware BusyBox commands are available. But wait a few minutes, then SSH in, and they are available. If re-integration completes while you're logged-in via SSH, that SSH session will be using out-of-date environment variables. So, logout then login again.

When Entware completes its re-integration, it processes the scripts in [/opt/etc/init.d]. You can create a script to confirm Entware is processing this directory.

Create this as [/opt/etc/init.d/Stest-entware.sh]

Code: Select all

#/usr/bin/env bash
uptime > /var/log/test-entware.log

Mark it executable:

Code: Select all

chmod +x /opt/etc/init.d/Stest-entware.sh

Check it with:

Code: Select all

/opt/etc/init.d/Stest-entware.sh && cat /var/log/test-entware.log

... and you should see your current uptime.

If this works, then reboot the NAS. Wait a few minutes after startup is complete, then check that Entware is available:

Code: Select all

which opkg

If the opkg path is displayed, then check the log:

Code: Select all

cat /var/log/test-entware.log

If the uptime is shown, then Entware has correctly run the test script.

[NiallCon]

Success!!
OneCD thank you so much for all your help.
I've learned quite a bit over the last few days.

I don't think I was giving Entware-ng much time to load. Because the QNAP was rebooting beside me and I was waiting for it to boot (to see if the changes I had made were going to work)....as soon as I heard the 'beep' that told me it had rebooted....I pulled up PuTTY and logged in straight away. I also didn't realise that I had to log back out of ssh to see if the service had been started afterwards. I just presumed that because I had an active ssh connection that any services that came up after I logged in would be visible. I guess that's not the case!

This really is great and your help has given me more energy to get back into linux. It's been a long time but as a lot of devices now have it running on their backend.....I think it would be good to know

Thank you once again. It's been a long trip but I've learned a lot along the way

Kind Regards,
Niall

[OneCD]

I also didn't realise that I had to log back out of ssh to see if the service had been started afterwards. I just presumed that because I had an active ssh connection that any services that came up after I logged in would be visible. I guess that's not the case!

It's only because environment variables (like $PATH) are altered when Entware loads. As you're in an SSH session that loaded an environment before this occurred, your variables do not change. Your directory tree will change, and you could even try running some of the Entware apps directly, but without an updated $PATH, their operation is uncertain. You can source a new environment file (in fact, I do this for a script on the forum that installs Entware then installs some Entware apps), but for interactive (user) sessions, it's easier to logout then back in again.

Thank you once again. It's been a long trip but I've learned a lot along the way

No worries.

[NiallCon]

Great thanks!
I have one more question (I really hope you don't mind).

I want to add a static ip address mapping into the Qnap arp table. This is because the arp table gets reset when the Qnap reboots.

I have created a script (from the one you have given me earlier).

Code: Select all

#!/usr/bin/env bash

case "$1" in
start)
# perform your 'start' actions here
# this is where you'll run your 'ip neigh' command to create static arp mapping to MAC address
ip neigh add 192.168.2.10 lladdr 00:1a:a0:71:a7:1b dev eth1 nud perm
;;
stop)
# perform your 'stop' actions here
;;
restart)
$0 stop
$0 start
;;
*)
echo -e "\\n Usage: $0 {start|stop|restart}"
;;
esac

I have tested it by running it manually and it works but again, it's not auto starting. Or maybe it is just a timing issue and it's starting too quickly?

I thought this might be a good use of your autorun script so I put it in:

Code: Select all

/share/CACHEDEV1_DATA/.system/autorun/scripts

When I check the autorun.log, it tells me the time that it has run but it doesn't give me any errors.

Any ideas?
Sorry again for all the questions. If you think this should be a new thread then let me know and I will create one for it.

Kind Regards,
Niall

[OneCD]

I have tested it by running it manually and it works but again, it's not auto starting. Or maybe it is just a timing issue and it's starting too quickly?

If you're using the autorun.sh method, then you don't need the usual 'init.d' format for your script. The case block can be removed. Which leaves you with this:

Code: Select all

#!/usr/bin/env bash

ip neigh add 192.168.2.10 lladdr 00:1a:a0:71:a7:1b dev eth1 nud perm

[NiallCon]

OneCD Sir,
It worked! My lack of scripting knowledge created the problem
Thank you once again for your time and great advice.

[OneCD]

No problem, and I’m glad that it works.