I am trying to build a custom service at the system level.  I have a script that runs successfully when run directly from the terminal.  This script activates a specific Conda environment and then uses a CLI to start a local instance of a web application.

On to the problem...  When I start the service, it activates the Conda environment and calls the CLI to start the application.  The application starts completely and then it is stopped within 30 seconds.  I am using a simple typed service.  From what I've read, this type should be used if the service starts and keeps running, and the prompt does not return until you press Control+C or stop the service in some other way.

The journalctl -u my_service.service shows the logs for the application (getting the data from the database, starting, and the port it runs on) then the shutdown logs are pushed (stopping application...).

Here is my service:


ExecStart=/path/to/insightd.sh start
ExecStop=/path/to/insightd.sh stop
ExecReload=/path/to/insightd.sh restart

  • 1
    What does journalctl -u your.service say?
    – balki
    Commented May 10, 2023 at 21:05
  • @jubilatious1:  abc ```def``` ghi is harmless;   changing it to abc `def` ghi  is not really an improvement.  If you’re going to edit a post to fix formatting, look out for ```First line and Last line```, which are actually wrong. Commented May 14, 2023 at 4:06
  • @G-ManSays'ReinstateMonica' the post needed attention. It got attention. Commented May 14, 2023 at 19:39

1 Answer 1


If /path/tp/insightd.sh is a legacy system-v style init script, it probably starts the command in the background. From the perspective of systemd, with Type=simple, this looks like your service starts up and then exits immediately.

With Type=simple, systemd expects the process started by ExecStart to keep running in the foreground.

You have two ways to resolve this issue:

  1. Instead of using /path/to/insightd.sh, inspect the script and extract the necessary command to start the service in the foreground.

  2. Change Type=simple to Type-forking. From the documentation:

    If set to forking, it is expected that the process configured with ExecStart= will call fork() as part of its start-up. The parent process is expected to exit when start-up is complete and all communication channels are set up. The child continues to run as the main service process, and the service manager will consider the unit started when the parent process exits. This is the behavior of traditional UNIX services. If this setting is used, it is recommended to also use the PIDFile= option, so that systemd can reliably identify the main process of the service. systemd will proceed with starting follow-up units as soon as the parent process exits.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .