OneCDOnly / RunLast

run custom shell-scripts after QPKG startup.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

support init.d style scripts

mickroll opened this issue Β· comments

Currently, scripts are executed after NAS startup. During shutdown, no additional script runs can be configured.

It would be great to support init.d - style scripts, that are called with a parameter:

  • after nas startup: start
  • before nas shutdown: stop

As existing scripts likely do not support these parameters, a second script directory could be used for these new scripts: RunLast/init.d.

Script execution order should be as follows:

  • after nas startup: sort
  • after nas startup: sort --reverse

This way, additional programs are started in the order 1-2-3 and shutdown 3-2-1, so dependencies between them are respected.

WDYT?

commented

@mickroll that sounds like a great idea. πŸ‘πŸ½

If a user has scripts in the standard RunLast scripts directory, should these run before or after the scripts in the init.d directory?

Hmmm good question. And it depends on what users want to achive with their scripts.
I guess that the scripts rely on a system that is ready-to-go, with all services startet. It sounds like this was the intention of creating the whole RunLast package.
I would call the things started from the new init.d-directory to be also services providing more or less essential stuff. So i am leaning towards:
startup:

  1. init.d
  2. scripts

shutdown:

  1. init.d

Btw. naming the new directory init.d would reduce needed documenation to a minimum, i think most people that are able to create bash scripts know how stuff works in /etc/init.d.

Oh and i forgot to thank you for creating the package in the first place. πŸ‘
I use it to start a simple git daemon, as on my old QNAP-TS410 there is no QGit available.

commented

Good thinking Michael. πŸ‘πŸ½

So, on startup, run everything in init.d in-order with start as the first argument. Then everything in scripts in-order with no argument.

On shutdown, run everything in init.d in reverse-order with stop as the first argument.

I'll begin work on this shortly. I'm currently relocating all my IT gear from one room in my house to another, so need to get that finished first.

I'll begin work on this shortly. I'm currently relocating all my IT gear from one room in my house to another, so need to get that finished first.

πŸš€ great!

commented

@mickroll I've just pushed v201029 into the build directory, can you please try this one out and let me know how it goes?

@OneCDOnly will try during the weekend, nas is in use currently

Today i tested the zip file https://github.com/OneCDOnly/RunLast/blob/acc865559b25b3afd2030cc0d8a33b97a97a7d78/build/RunLast_201029.qpkg.zip

PEBCAK, giant one - i removed most of my previous posting.

As soon as i realized that i have to unzip the qpgk before handing it over to the nas, installation worked:
grafik
Sorry for any confusion, if you already read my previous post. πŸ™ˆ

Will now test init-script handling.

Update:
I used my simple git daemon script for testing: gitdaemon.sh.zip (uses no authentication and needs git-daemon-export-ok marker file in git dir to be exposed)
Did put it into init.d directory, then chmod +x gitdaemon.sh
First test was using ./runlast.sh start:

RunLast (20201029)
script processing started
[Sun Nov  1 10:33:20 CET 2020] executing '/share/MD0_DATA/.qpkg/RunLast/init.d/gitdaemon.sh' start:
returncode=[0]
stdout=[Starting git daemon...
git daemon started]
stderr=[]
script processing completed

... and ./runlast.sh stop:

RunLast (20201029)
package shuffle started
package shuffle completed
script processing started
[Sun Nov  1 10:33:14 CET 2020] executing '/share/MD0_DATA/.qpkg/RunLast/init.d/gitdaemon.sh' stop:
returncode=[0]
stdout=[Shutting down git daemon...
git daemon stopped]
stderr=[]
script processing completed

πŸ‘

Run on nas shut down also worked:

RunLast (20201029)
[Sun Nov  1 10:34:58 CET 2020] script processing started

[Sun Nov  1 10:34:59 CET 2020] executing '/share/MD0_DATA/.qpkg/RunLast/init.d/gitdaemon.sh' stop:
returncode=[0]
stdout=[Shutting down git daemon...
git daemon stopped]
stderr=[]

[Sun Nov  1 10:34:59 CET 2020] script processing completed

But on starting there was a problem:

RunLast (20201029)
[Sun Nov  1 10:50:35 CET 2020] script processing started

[Sun Nov  1 10:50:42 CET 2020] executing '/share/MD0_DATA/.qpkg/RunLast/init.d/gitdaemon.sh' start:
returncode=[0]
stdout=[Starting git daemon...
git daemon started]
stderr=[/share/MD0_DATA/.qpkg/RunLast/init.d/gitdaemon.sh: line 10: git: command not found]

[Sun Nov  1 10:50:43 CET 2020] script processing completed

I connected via ssh as early as possible (runlast did not run by then), testing for git:

# git
-sh: git: command not found

Even after RunLast did execute (kind of marking that the nas is ready), this did not change. I had to reconnect shh for git to be available:

# which git
/opt/bin/git

with: opt -> /share/MD0_DATA/.qpkg/Entware/

Long story short: your script works as intended. Thanks for that πŸ‘
But the shell that starts runlast is kind of 'incomplete'. I guess the PATH is not set or the link of /opt was not set to Entware...
Which makes me wonder: maybe some Entware setup runs after runlast?

It turns out, that the early-opened shell has fewer entries in its PATH:
early: PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin
later: PATH=/opt/bin:/opt/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin

Somehow, runlast seems to have the early PATH, missing the /opt/ entries. I changed my startup script to output the current PATH and run git via /opt/bin/git:

unLast (20201029)
[Sun Nov  1 11:42:03 CET 2020] script processing started

[Sun Nov  1 11:42:15 CET 2020] executing '/share/MD0_DATA/.qpkg/RunLast/init.d/gitdaemon.sh' start:
returncode=[0]
stdout=[Starting git daemon...
path is: /bin:/sbin:/usr/bin:/usr/sbin:/usr/bin/X11:/usr/local/sbin:/usr/local/bin
git daemon started]
stderr=[]

[Sun Nov  1 11:42:18 CET 2020] script processing completed

@OneCDOnly Now everything works as expected! πŸ‘

I left a remark on the commit, just a nitpick regarding logging.

I also created a PR with an updated readme: #5

commented

Good work Michael. πŸ‘πŸ½

Entware is a special case. After QTS finishes Entware reintegration during bootup, QTS continues processing the next QPKG in [/etc/config/qpkg.conf].

The problem is: Entware is still starting-up, and cannot be immediately used. It can take a few minutes to become available to the rest of the system.

Also note that $PATH is modified via [/root/.profile] -> [/opt/etc/profile] to prepend the Entware directories. This only takes-effect when the user logs-in via SSH. If you were already logged-in, your $PATH would need to be reloaded by sourcing that profile:

. /opt/etc/profile

If you have startup scripts that rely on Entware, you might consider putting them into the Entware init directory [/opt/etc/init.d/]. Files placed here must be named beginning with an uppercase 'S'. Entware will then automatically execute these scripts when it's ready.

I've merged your documentation PR - thank you.

Also note that I released a newer QPKG yesterday (201101) that changes the log format a little. Can you try this one out and see if it addresses your suggestion?

Cheers!

I've merged your documentation PR - thank you.

πŸ˜ƒ

Also note that I released a newer QPKG yesterday (201101) that changes the log format a little. Can you try this one out and see if it addresses your suggestion?

AFAICS the latest update adds timestamps to all log messages. Thats a good thing, but does not address the "problem" i discovered: the human log-reader is still unable to decide, if the log messages were created during startup or shutdown. But that's a minor thing and doesn't prevent this issue from being closed.

Thank you for your good work, quick reaction and all your explanations! πŸ‘

commented

AFAICS the latest update adds timestamps to all log messages. Thats a good thing, but does not address the "problem" i discovered: the human log-reader is still unable to decide, if the log messages were created during startup or shutdown. But that's a minor thing and doesn't prevent this issue from being closed.

The log should also show the command executed. For the SysV scripts, this will have 'start' or 'stop' as the first argument.

commented

Hi Michael, I've just pushed v201104 which changes the log layout again. It now shows start and stop a bit clearer in the RunLast log and in the QTS system log. Can you download this one and try it out?

If it works fine on your end, I'll submit this version to the QnapClub repo.

Can you download this one and try it out?

I just did and the log looks fine πŸ˜ƒ

────────────────────────────────────────────────────────
RunLast (20201104)
[Thu Nov 5 16:33:29 CET 2020] begin "start" scripts ...
[Thu Nov 5 16:33:30 CET 2020] -> executing: "'/share/MD0_DATA/.qpkg/RunLast/init.d/gitdaemon.sh' start" ...
[Thu Nov 5 16:33:30 CET 2020] => returncode: (0)
[Thu Nov 5 16:33:30 CET 2020] => stdout: "Starting git daemon...
git daemon started"
[Thu Nov 5 16:33:30 CET 2020] => stderr: ""
[Thu Nov 5 16:33:30 CET 2020] end "start" scripts
───────────────────────────────────────────────────────
RunLast (20201104)
[Thu Nov 5 16:33:27 CET 2020] begin "stop" scripts ...
[Thu Nov 5 16:33:27 CET 2020] -> executing: "'/share/MD0_DATA/.qpkg/RunLast/init.d/gitdaemon.sh' stop" ...
[Thu Nov 5 16:33:27 CET 2020] => returncode: (0)
[Thu Nov 5 16:33:27 CET 2020] => stdout: "Shutting down git daemon...
git daemon stopped"
[Thu Nov 5 16:33:27 CET 2020] => stderr: ""
[Thu Nov 5 16:33:27 CET 2020] end "stop" scripts
────────────────────────────────────────────────────────

πŸ‘

I think its good for pushing into QnapClub repo. Maybe with a mention to my idea? πŸ˜‰

commented

I think its good for pushing into QnapClub repo. Maybe with a mention to my idea? wink

Done! Thanks Michael. πŸ‘πŸ½

Now available via the QnapClub Store as version 201106.