[Bug]: Only on first startup after server reboot: Stirling-PDF-Security exited with code 143

[Kofl]

Installation Method

Docker

The Problem

On the first startup of the docker container I get:

Stirling-PDF-Security exited with code 143

on the second startup, it works fine.

Version of Stirling-PDF

0.36.2

Last Working Version of Stirling-PDF

No response

Page Where the Problem Occurred

No response

Docker Configuration

version: '3.3'
services:
  stirling-pdf:
    container_name: Stirling-PDF-Security
    image: frooodle/s-pdf:latest
    deploy:
      resources:
        limits:
          memory: 4G
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:8080/api/v1/info/status | grep -q 'UP' && curl -fL http://localhost:8080/ | grep -q 'Please sign in'"]
      interval: 5s
      timeout: 10s
      retries: 16
    ports:
      - 8087:8080
    volumes:
      - /opt/docker/stirling/data:/usr/share/tessdata:rw
      - /opt/docker/stirling/config:/configs:rw
      - /opt/docker/stirling/logs:/logs:rw
    environment:
      DOCKER_ENABLE_SECURITY: "true"
      SECURITY_ENABLELOGIN: "true"
      PUID: 1002
      PGID: 1002
      UMASK: "022"
      SYSTEM_DEFAULTLOCALE: en-US
      UI_APPNAME: Stirling-PDF
      UI_HOMEDESCRIPTION: powered by Stirling-PDF Latest with Security
      UI_APPNAMENAVBAR: Stirling-PDF Latest
      SYSTEM_MAXFILESIZE: "100"
      METRICS_ENABLED: "false"
      SYSTEM_GOOGLEVISIBILITY: "false"
      restart: unless-stopped
~

Relevant Log Output

Stirling-PDF-Security | 07:37:44.918 [main] INFO  s.s.S.config.EndpointConfiguration - Total disabled endpoints: 3. Disabled endpoints: book-to-pdf, pdf-to-book, pdf-to-pdfa
Stirling-PDF-Security | 07:37:45.534 [main] INFO  s.s.S.c.s.d.DatabaseBackupHelper - Deleted oldest backup: backup_202411170000.sql
Stirling-PDF-Security | 07:37:45.549 [main] INFO  s.s.S.c.s.d.DatabaseBackupHelper - Database export completed: configs/db/backup/backup_202412160737.sql
Stirling-PDF-Security | 07:37:50.760 [main] INFO  s.software.SPDF.SPdfApplication - Started SPdfApplication in 23.718 seconds (process running for 27.328)
Stirling-PDF-Security | 07:37:50.774 [scheduling-1] WARN  s.software.SPDF.utils.FileMonitor - not monitoring any directory, even the root directory itself: ./pipeline/watchedFolders
Stirling-PDF-Security | 07:37:50.778 [main] INFO  s.software.SPDF.SPdfApplication - Stirling-PDF Started.
Stirling-PDF-Security | 07:37:50.778 [scheduling-1] INFO  s.software.SPDF.utils.FileMonitor - Registered directory: ./pipeline/watchedFolders
Stirling-PDF-Security | 07:37:50.778 [main] INFO  s.software.SPDF.SPdfApplication - Navigate to http://localhost:8080
Stirling-PDF-Security exited with code 143

Additional Information

No response

Browsers Affected

No response

No Duplicate of the Issue

• I have verified that there are no existing issues raised related to my problem.

[dosubot]

Hey @Kofl! I'm here to help you with any bugs, questions, or contributions you have for Stirling-PDF-Security. Let's squash those bugs together!

The exit code 143 typically indicates that the service was terminated by a SIGTERM signal, which is often sent when a container is stopped. This can happen due to several reasons, such as a manual stop, a system shutdown, or a healthcheck failure that triggers a restart.

In your Docker configuration, the healthcheck is set to run every 5 seconds, with a timeout of 10 seconds, and it will retry up to 16 times if the check fails. If the healthcheck fails consistently during the first startup, it could lead to the container being stopped and restarted, resulting in an exit code 143 ^[1].

Additionally, Stirling-PDF relies on several external dependencies during startup. If these dependencies are not available or not properly configured, it could cause issues during the initial startup. Ensure that all required dependencies are installed and accessible ^[2][3][4].

To troubleshoot, you might want to:

1. Verify that all dependencies are correctly installed and accessible.
2. Check if the healthcheck command is correctly configured and that the service is actually up and running before the healthcheck is executed.
3. Consider increasing the initial delay for the healthcheck to give the service more time to start up on the first attempt.

To continue talking to Dosu, mention @dosu.

---

^{Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other}