3

This is my systemd service on ubuntu 16.04:

[Unit]
Description=Starts Caspar CG

[Service]
Type=forking
WorkingDirectory=/home/broadcastingza/CasparCG/Server
Environment=DISPLAY=:0
ExecStart=/bin/sh ./run.sh --watch
StandardOutput=null
Restart=on-failure

[Install]
WantedBy=multi-user.target graphical.target

EDIT: This is the output of sudo systemctl status -l

sudo systemctl status start-caspar.service -l
● start-caspar.service - Starts Caspar CG
       Loaded: loaded (/etc/systemd/system/start-caspar.service; enabled; vendor preset: enabled)
       Active: inactive (dead) since Tue 2017-03-21 17:04:28 SAST; 1 day 16h ago
Process: 5198 ExecStart=/bin/bash -c ./run.sh --watch (code=exited, status=0/SUCCESS)

Mar 21 17:04:14 ZAPS001 systemd[1]: Starting Starts Caspar CG...
Mar 21 17:04:28 ZAPS001 systemd[1]: Started Starts Caspar CG.

This service gets enabled and runs fine. No problems with starting it manually either. The only issue I'm having is that as soon as the shell script runs ("run.sh"), the server it starts up then receives an EXIT signal, and exits with EXIT code 0. It's almost as if the server requires the console to be open all the time.

When I run the exact same script from the console it runs perfectly fine.

Is there a way to start the service without exiting the console immediately, or is there a way to start the service independent of the console in the first place?

  • Could you show the output of sudo systemctl status <yourservice> -l? – 13dimitar Mar 23 '17 at 7:43
  • @13nilux Hi, I've added the info to the original post above. Thanks! – string theorist Mar 23 '17 at 8:04
  • Comment out the StandardOutput= line and check for messages from your command. If you want to use the X11 display you may need to set more in the environment, and wait longer for X11 to be ready. – meuh Mar 23 '17 at 12:00
  • @meuh If by "messages from your command" you mean the data log of the script, it writes its own log as well, and in that log it says that the server receives the command EXIT, and so it shuts down everything immediately. I know that it's not a matter of waiting for the X11 display to start, because even after logging in and starting the service manually through the terminal emulator, I have the same problem. – string theorist Mar 23 '17 at 12:17
  • So from where is your server getting an exit command? Is it reading stdin? If you ./run.sh <&- or ./run.sh </dev/null does it die too? If your server is a binary, not a script, you can try using strace to see what system calls it does and so perhaps find the one making it decide to exit. – meuh Mar 23 '17 at 12:26
2

My apologies everyone. This seems to be a known issue in the binary that I'm trying to run headless (casparcg). See: https://github.com/CasparCG/Server/issues/529

The suggested workaround is to install screen (or tmux) to run the terminal in detached mode. I've got it working using screen.

  1. Install screen:

    sudo apt install screen

  2. This is the line of code to use in the systemd service after installation:

    screen -d -m /path/to/your/script.sh

-d detaches terminal, -m ignores $STY.

  1. Adjust systemd service accordingly:

    [Unit]
    Description=Starts Caspar CG

    [Service]
    Type=forking
    Environment=DISPLAY=:0
    StandardOutput=null
    ExecStart=/bin/sh -c "screen -d -m /usr/bin/start_caspar.sh" --watch
    Restart=on-failure
    User=broadcastingza

    [Install]
    WantedBy=multi-user.target graphical.target

I'm now able to run the server detached.

Thanks for the help!

  • It's not a known issue in the binary, it's a fundamental flaw in the design if you want it to run as a daemon. The program expects itself to be running interactively, talking to the user (receiving commands, sending responses) on a terminal device. Ironically, this interactive mode seems to comprise solely stuff labelled "This is just dummy code for testing". Your ExecStart setting has an unnecessary extra shell process in the mix, and an extra argument that gets ignored, by the way. And if start_caspar.sh is anything like that run.sh it too is itself entirely superfluous. – JdeBP Mar 25 '17 at 8:06
  • Thanks for the reply. Yes, I agree. The program I'm running is still in beta, so I hope they fix this in the next release. Are you saying that the --watch is ignored? . . Could you please suggest the improvements I can make on my side? Your help is appreciated. – string theorist Mar 25 '17 at 8:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.