Latest commit leads to script killed with an error

Question

Latest commit leads to script killed with an error

jimpoison opened this issue 2 years ago · 21 comments

Your latest commit e0f722b breaks execution of your script on my qnap.
I have to revert this commit to make it work again...
Error is like this:
Stopping Qthttpd hogging port 80..
Shutting down Qthttpd services: OK.
Started python HTTP server with pid 31500
renew_certificate.sh: line 59: letsencrypt/signed.crt.tmp: No such file or directory
An error occured. Restoring system state.

My system is qnap ts-251 with latest firmware.

Answer 1 · 2022-09-04T10:08:05.000Z

Where is renew_certificate.sh stored on your nas and how exactly are you calling it?

Answer 2 · 2022-09-04T10:32:16.000Z

It's stored at /share/MD1_DATA/ssl/qnap-letsencrypt, but I'm calling it via symlink at /share/MD1_DATA on the command line like ./renew_certificate.sh

Answer 3 · 2022-09-04T10:53:29.000Z

Please replace the cd "$SCRIPT_DIR" line in renew_certificate.sh with the following:

pwd
echo $SCRIPT_DIR
echo $0
echo $(dirname -- "$0")
cd $SCRIPT_DIR
pwd

call the script like usual, and post the output here.

Answer 4 · 2022-09-04T15:49:51.000Z

that's the output:

[/share/MD1_DATA] # ./renew_certificate.sh
/share/MD1_DATA
/share/MD1_DATA/ssl/qnap-letsencrypt
./renew_certificate.sh
.
/share/MD1_DATA/ssl/qnap-letsencrypt
Checking whether to renew certificate on Sun, 04 Sep 2022 17:48:10 +0200
Certificate will not expire
[/share/MD1_DATA] #

Answer 5 · 2022-09-04T16:28:56.000Z

It's stored at /share/MD1_DATA/ssl/qnap-letsencrypt, but I'm calling it via symlink at /share/MD1_DATA on the command line like ./renew_certificate.sh

Can you clarify about the symlink src/target please. It probably has to do with the symlink.

Answer 6 · 2022-09-04T17:25:01.000Z

The script itself is stored at /share/MD1_DATA/ssl/qnap-letsencrypt.
The symlink at is stored at /share/MD1_DATA.
I'm calling the symlink to run the script.
That wasn't a problem until your last commit

Answer 7 · 2022-09-04T17:26:04.000Z

What is the exact symlink src/dest?

Answer 8 · 2022-09-04T18:05:41.000Z

[/share/MD1_DATA] # ls -l renew_certificate.sh lrwxrwxrwx 1 admin administrators 57 2021-12-18 14:04 renew_certifi
cate.sh -> /share/MD1_DATA/ssl/qnap-letsencrypt/renew_certificate.sh*
I hope this is what you want to know...

Answer 9 · 2022-09-04T19:31:10.000Z

Yeah, that is what I was looking for. Now I understand your setup.

The problem is, that many qnap systems do not support readlink -f , as reported in #89. Therefore I have removed the readlink part, which does break symlink resolution.

What's the output of

readlink --help
realpath --help

on your nas?

Answer 10 · 2022-09-04T19:59:14.000Z

readlink --help
BusyBox v1.24.1 (2022-08-15 03:16:38 CST) multi-call binary.

Usage: readlink [-fnv] FILE

Display the value of a symlink

    -f      Canonicalize by following all symlinks
    -n      Don't add newline
    -v      Verbose

[~] # realpath --help
-sh: realpath: command not found

Answer 11 · 2022-09-04T20:03:03.000Z

@Itsme1609

Can you post the output of

readlink --help
realpath --help

on your nas? I think it also had the readlink issue.

Answer 12 · 2022-09-04T21:25:23.000Z

Do you think that calling the script directly without the symlink would work without problems? Then I'll do that in the future.
the only purpose of the symlink is that I don't have to type so many characters...
But I think I could live with that ;-)

Answer 13 · 2022-09-04T21:49:15.000Z

Do you think that calling the script directly without the symlink would work without problems? Then I'll do that in the future. the only purpose of the symlink is that I don't have to type so many characters... But I think I could live with that ;-)

Yes, that will certainly work.

Answer 14 · 2022-09-05T15:08:41.000Z

Hi Yannik, here is the output

Answer 15 · 2022-09-05T15:38:25.000Z

In my renew_certificate log file I have the same error message as jimpoison
BusyBox v1.01 (2022.06.22-22:54+0000) multi-call binary

Usage: readlink

Displays the value of a symbolic link.

Checking whether to renew certificate on Mon, 05 Sep 2022 03:30:01 +0200
Renewing certificate...
Using python path: python3
Stopping Qthttpd hogging port 80..
Shutting down Qthttpd services: OK.
Started python HTTP server with pid 7776
/share/MD0_DATA/.qpkg/Entware/letsencrypt/qnap-letsencrypt/renew_certificate.sh: line 58: letsencrypt/signed.crt.tmp: No such file or directory
An error occured. Restoring system state.
/share/MD0_DATA/.qpkg/Entware/letsencrypt/qnap-letsencrypt/renew_certificate.sh: line 11: 7776 Killed "$PYTHON" ../HTTPServer.py (wd: /share/MD0_DATA/homes/admin/tmp-webroot)
Start apache proxy: OK
Starting Qthttpd services: OK

I thougt the reason is that the port 80&443 are closed. I opened them and executed renew_certificate.sh manually.
No entry in the logfile...

Answer 16 · 2022-09-20T08:59:03.000Z

Please replace the cd "$SCRIPT_DIR" line in renew_certificate.sh with the following:
pwd
echo $SCRIPT_DIR
echo $0
echo $(dirname -- "$0")
cd $SCRIPT_DIR
pwd
call the script like usual, and post the output here.

I also have the same issue and added the debug output from the answer above resulting in this output:

BusyBox v1.01 (2022.06.22-22:54+0000) multi-call binary

Usage: dirname FILENAME

Strips non-directory suffix from FILENAME

/tmp/cron
/tmp/cron
/opt/qnap-letsencrypt/renew_certificate.sh
BusyBox v1.01 (2022.06.22-22:54+0000) multi-call binary

Usage: dirname FILENAME

Strips non-directory suffix from FILENAME


/tmp/cron
User "admin" checking whether to renew certificate on Tue, 20 Sep 2022 10:43:01 +0200
Renewing certificate...
Using python path: /share/MD0_DATA/.qpkg/Python3/python3/bin/python3
Stopping Qthttpd hogging port 80..
Shutting down Qthttpd services: OK.
Started python HTTP server with pid 5048
/opt/qnap-letsencrypt/renew_certificate.sh: line 64: letsencrypt/signed.crt.tmp: No such file or directory
An error occured. Restoring system state.
/opt/qnap-letsencrypt/renew_certificate.sh: line 11:  5048 Killed                  "$PYTHON" ../HTTPServer.py  (wd: /tmp/cron/tmp-webroot)
Start apache proxy: OK
Starting Qthttpd services: OK

I have located the stuff at /opt/qnap-letsencrypt which worked well until the last commit. The cronjob is calling /opt/qnap-letsencrypt/renew_certificate.sh

EDIT:
I found that the -- in the dirname leads to an error, as it ends the parameter input list of the command. So the value of SCRIPT_DIR is always empty, because of that. The following instead is working as expected:

SCRIPT_DIR=$(CDPATH= cd -- "$(dirname "$0")" && pwd)

Answer 17 · 2022-10-05T14:25:03.000Z

@Itsme1609 Please check if this is fixed for you with the merge of #121

Answer 18 · 2022-10-05T19:48:09.000Z

Hi Yannik, I adjusted the script of renew_certificate. That´s the output of running the script.

[/opt/letsencrypt/qnap-letsencrypt] # ./renew_certificate.sh
Checking whether to renew certificate on Wed, 05 Oct 2022 21:54:47 +0200
[/opt/letsencrypt/qnap-letsencrypt] #

@Yannik: Is that the debug output you expected ?

Answer 19 · 2022-10-06T07:57:21.000Z

@Itsme1609 No, you will need to rm letsencrypt/signed.crt to make sure a new cert is generated.

Answer 20 · 2022-10-06T21:49:47.000Z

@Itsme1609 No, you will need to rm letsencrypt/signed.crt to make sure a new cert is generated.

The certificate was renewed without any error 👍

Answer 21 · 2022-10-06T22:07:04.000Z

@Itsme1609 that's good, then i'll close this.