[GH-ISSUE #359] Issue running sign.py on Semaphore CI (connect ECONNREFUSED ::1:8080) #96

New issue

Closed

opened 2026-03-04 00:23:51 +03:00 by kerem · 1 comment

kerem commented

2026-03-04 00:23:51 +03:00

Owner

Originally created by @colto1000 on GitHub (Sep 16, 2023).
Original GitHub issue: https://github.com/SignTools/SignTools/issues/359

I tried basic troubleshooting first

Updated both SignTools and the builder (SignTools-CI or SignTools-Builder) to the latest version
Read through the FAQ page

Describe the bug

It appears there is an issue with something related to the functionality or implementation of Node, specifically in relation to the node_download() function within sign.py. This is, however, only an assumption based on my understanding of the log file.

As sign.py begins to run within Semaphore CI, we see the parent error: connect ECONNREFUSED ::1:8080. It appears to me there may be an issue with Semaphore CI interfacing with localhost (ipv6) at port 8080. That this is localhost of Semaphore CI, and not the SignTools process (on my RPi), as I have tested running SignTools on a different port (8081) and still receive the same error.

The issue persists with the implementation of GitHub Actions, in place of Semaphore CI. Issue also persists when interfacing with SignTools directly on the host machine (and disabling Caddy, the Reverse Proxy). Although, in this case, the task was using a custom bundleID, the issue still persists when signing an application with a default configuration.

SignTools’ web interface always reports either “Waiting“ or “Failed“ four any given application.

I’m using custom/explicit certificate and mobile provisioning files, with a password text file and then file included. The directory structure outlined in the advanced install guide was followed and all other functionality seems to be working as expected.

I have done as much Googling and Stack Overflow’ing as I would find reasonable before posting this bug (colluding some research into node_fetch), but I feel they may just be an issue with my configuration of the whole setup. I have follow the advance, guide closely, as well as viewing the FAQ, I have not been able to find the answer to this issue.

To reproduce

Steps to reproduce the behavior:

Start an app-signing job via SignTools web interface.
Click ‘Status’.
Select the most recent CI job.
See error.

Expected behavior

I would expect the CI handler to successfully run sign.py, and furthermore sign the requested application.

Logs

Full Log: https://pastebin.com/fPb5PBD3

Screenshots

System configuration

SignTools version: 2.6.2
Installation type: Raspberry Pi (self-hosted) → Caddy Reverse Proxy
Builder type: SignTools-CI via Semaphore CI
Builder version: 704d7be

Additional context

I am running SignTools on a Raspberry Pi 4 and run a reverse proxy through Caddy.

Originally created by @colto1000 on GitHub (Sep 16, 2023). Original GitHub issue: https://github.com/SignTools/SignTools/issues/359 **I tried basic troubleshooting first** - [x] Updated **both** [SignTools](https://github.com/SignTools/SignTools) **and** the builder ([SignTools-CI](https://github.com/SignTools/SignTools-CI) or [SignTools-Builder](https://github.com/SignTools/SignTools-Builder)) to the latest version - [x] Read through the [FAQ page](https://github.com/SignTools/SignTools/blob/master/FAQ.md) **Describe the bug** It appears there is an issue with something related to the functionality or implementation of Node, specifically in relation to the `node_download()` function within `sign.py`. This is, however, only an assumption based on my understanding of the log file. As `sign.py` begins to run within Semaphore CI, we see the parent error: `connect ECONNREFUSED ::1:8080`. It appears to me there may be an issue with Semaphore CI interfacing with localhost (ipv6) at port 8080. That this is localhost of Semaphore CI, and not the SignTools process (on my RPi), as I have tested running SignTools on a different port (8081) and still receive the same error. The issue persists with the implementation of GitHub Actions, in place of Semaphore CI. Issue also persists when interfacing with SignTools directly on the host machine (and disabling Caddy, the Reverse Proxy). Although, in this case, the task was using a custom bundleID, the issue still persists when signing an application with a default configuration. SignTools’ web interface always reports either “Waiting“ or “Failed“ four any given application. I’m using custom/explicit certificate and mobile provisioning files, with a password text file and then file included. The directory structure outlined in the advanced install guide was followed and all other functionality seems to be working as expected. I have done as much Googling and Stack Overflow’ing as I would find reasonable before posting this bug (colluding some research into node_fetch), but I feel they may just be an issue with my configuration of the whole setup. I have follow the advance, guide closely, as well as viewing the FAQ, I have not been able to find the answer to this issue. **To reproduce** Steps to reproduce the behavior: 1. Start an app-signing job via SignTools web interface. 2. Click ‘Status’. 3. Select the most recent CI job. 4. See error. **Expected behavior** I would expect the CI handler to successfully run `sign.py`, and furthermore sign the requested application. **Logs** Full Log: https://pastebin.com/fPb5PBD3 **Screenshots** ![IMG_0174](https://github.com/SignTools/SignTools/assets/33501061/e80ceeca-f9cb-4e43-8704-3ba6e440e19f) **System configuration** - SignTools version: 2.6.2 - Installation type: Raspberry Pi (self-hosted) → Caddy Reverse Proxy - Builder type: SignTools-CI via Semaphore CI - Builder version: 704d7be **Additional context** I am running SignTools on a Raspberry Pi 4 and run a reverse proxy through Caddy.

kerem

2026-03-04 00:23:51 +03:00

closed this issue
added the
bug
label

kerem commented

2026-03-04 00:23:52 +03:00

Author

Owner

@ViRb3 commented on GitHub (Nov 4, 2023):

Sorry for responding so late, not sure how I missed this. It looks to me that you're confusing how the CI works. The way you have it set up, it connects to itself, and it rightfully fails, as there is nothing to find there. The CI needs to connect to your SignTools server (where your web UI is hosted), and pull the files from there. Therefore, you'd need to put the server's public IP or a tunnel instead of localhost.

@ViRb3 commented on GitHub (Nov 4, 2023): Sorry for responding so late, not sure how I missed this. It looks to me that you're confusing how the CI works. The way you have it set up, it connects to itself, and it rightfully fails, as there is nothing to find there. The CI needs to connect to your SignTools server (where your web UI is hosted), and pull the files from there. Therefore, you'd need to put the server's public IP or a tunnel instead of localhost.