2

I created an application that I want to start on boot for the raspberry.

I had already set up a service for wvdial by hand to make it start on boot and it works like a charm so I then started working on this application of mine. It's no fancy stuff, it's a "simple" service with a command to start, I defined the working directory and the user that will run it.

[Unit]
Description=Blah Blah

[Service]
Type=simple
WorkingDirectory=/home/pi/appdir
ExecStart=/home/pi/appdir/the-script-to-start.py
Restart=always
RestartSec=60
User=pi

When booting, it's not started (systemd says it's inactive (dead)). No output about it on journalctl. If I then try starting by hand with systemctl, it works.

What am I missing?

PS1

Ok.... I think python (or the basic set up to get it working) is not to blame. I switched to configuring a very simple bash script that just prints a line and nothing else... so it goes out with exit code 0.

After rebooting:

● my-service.service - some Service
   Loaded: loaded (/etc/systemd/system/my-service.service; static; vendor preset: enabled)
   Active: inactive (dead)

When I run it manually:

● my-service.service - some Service
   Loaded: loaded (/etc/systemd/system/my-service.service; static; vendor preset: enabled)
   Active: activating (auto-restart) since Wed 2018-04-11 16:00:55 UTC; 2s ago
  Process: 744 ExecStart=/home/pi/blahblah/prueba.sh (code=exited, status=0/SUCCESS)
 Main PID: 744 (code=exited, status=0/SUCCESS)

Is there something I can do in systemd configuration so that I can see more debugging information about how it's working on boot?

PS2

After modifying LogLevel to debug and reboot, I can see that for wvdial, we have this info from journalctl about 22 seconds into boot process (for starters, there's more stuff ):

Apr 11 16:53:06 raspberrypi systemd[1]: wvdial.service: Trying to enqueue job wvdial.service/start/replace
Apr 11 16:53:06 raspberrypi systemd[1]: wvdial.service: Installed new job wvdial.service/start as 182
Apr 11 16:53:06 raspberrypi systemd[1]: wvdial.service: Enqueued job wvdial.service/start as 182
Apr 11 16:53:06 raspberrypi systemd[1]: wvdial.service: Passing 0 fds to service
Apr 11 16:53:06 raspberrypi systemd[1]: wvdial.service: About to execute: /usr/bin/wvdial
Apr 11 16:53:06 raspberrypi systemd[1]: wvdial.service: Forked /usr/bin/wvdial as 498
Apr 11 16:53:06 raspberrypi systemd[1]: wvdial.service: Changed dead -> running
Apr 11 16:53:06 raspberrypi systemd[1]: wvdial.service: Job wvdial.service/start finished, result=done
Apr 11 16:53:06 raspberrypi systemd[1]: Started wvdial service.
Apr 11 16:53:06 raspberrypi systemd[498]: wvdial.service: Executing: /usr/bin/wvdial

But no word about my service.

4
  • It doesn't meet your needs exactly but maybe you can find some hints at Running a script after an internet connection is established.
    – Ingo
    Commented Apr 11, 2018 at 17:07
  • Please check the FAQ *Why do things behave differently under systemd?. Also, is your service trying to do something graphical, like launch a desktop app? Commented Apr 11, 2018 at 18:11
  • 1
    @MarkStosberg Will take a look. And no, it's a pure shell based application that uses a GPS device attached to the raspberry.
    – eftshift0
    Commented Apr 11, 2018 at 18:37
  • when I ask systemctl to list units (--all), I can see wvdial, but I can't see anything about the other service. Grrrrrrr
    – eftshift0
    Commented Apr 11, 2018 at 18:52

3 Answers 3

2

Seems this is already solved, but wanted to add an alternative solution for starting a Python program (or any program for that matter) at boot time:

open crontab as follows:

crontab -e

the crontab will be opened in your chosen editor (default is nano)

Add a line to the end of your crontab file that looks like this:

@reboot /usr/bin/python3 /home/pi/any-program.py > /home/pi/cronjoblog 2>&1

Your program named any-program.py will execute during the boot sequence, and any issues will be recorded in the file cronjoblog

1
  • Didn't know about this possibility. Nice touch! It's still more flexible with systemd because it's possible to stop/start at will but still nice to know.
    – eftshift0
    Commented Apr 14, 2018 at 5:25
1

[Unit] After=?

[Install] WantedBy=?

Or // does the script have the python shebang? is it +x? if both are set and still not working try to add the /usr/bin/python infront to the ExecStart // But i think its After=/Before= // WantedBy=

[Unit]
Description=Scanner Script Service
After=server.service multi-user.target

[Service]
Type=simple
WorkingDirectory=/opt/files/
ExecStart=/usr/bin/python /opt/files/scanner.py
Restart=always

[Install]
WantedBy=multi-user.target

(working, server.service is a selfmade too)

2
  • Script does have shebang. It's also set with +x. Let me try adding the python binary to the call to see if that solves it.
    – eftshift0
    Commented Apr 11, 2018 at 15:27
  • Ok.... I think python (or the basic set up to get it working) is not to blame. I switched to configuring a very simple bash script that just prints a line and nothing else... so it goes out with exit code 0. If I run it manually.... I'll add a comment.... I know that formatting does't work here
    – eftshift0
    Commented Apr 11, 2018 at 15:58
-1

Seems like adding the section [Install] and enabling the service, it starts working (I didn't have to do it with wvdial but....).

Thanks for your attention.

1
  • No need to add this as new answer, this is what @ghost advised. Adding the [Install] section and running 'enable' is what sets the service to be started at boot time. Commented Apr 12, 2018 at 13:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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