I also suggest you specify the service Type= explicitly. While the default is currently simple (which should work for what you're doing) older versions of systemd may have behaved differently.
[Service] Type = simple
Is there a better way to ensure these services get started when everything is available? And the python service won't start until the nodejs service is done? ,When I run the dashboard_display.service using systemctl start dashboard_display.service it runs for days. Running it at boot after enable, it crashes the pi somewhow., Can you please include output of systemctl status dashboard_display.service after boot? Also look at journalctl -b -u dashboard_display.service for the logs since last boot. If your home directory is on a separate partition, you might need RequiresMountsFor=/home to ensure that partition is mounted before systemd tries to start the service. – filbranden Mar 15, 2020 at 23:21 ,Server Fault is a question and answer site for system and network administrators. It only takes a minute to sign up.
python: dashboard.py
import Image
import time
from rgbmatrix
import Adafruit_RGBmatrix
# Rows and chain length are both required parameters:
matrix = Adafruit_RGBmatrix(32, 2)
matrix.SetWriteCycles(16)
while True:
try:
image = Image.open("/home/pi/dashboard.png")
image.load()
matrix.SetImage(image.im.id, 0, 0)
time.sleep(10)
matrix.Clear()
except:
print("Dashboard image could not be opened!")
time.sleep(5)systemd dashboard_display.service
[Unit]
Description = Dashboard Display Driver
#Requires = dashboard_png.service ?
After = multi - user.target
[Service]
Type = simple
ExecStart = /usr/bin / python / home / pi / src / drive - display / dashboard.py
Restart = on - failure
RestartSec = 10
[Install]
WantedBy = multi - user.targetSystemd is a system and service manager for Linux operating systems. It is designed to be backwards compatible with SysV init scripts, and provides a number of features such as parallel startup of system services at boot time, on-demand activation of daemons, or dependency-based service control logic. In Red Hat Enterprise Linux 7, systemd replaces Upstart as the default init system. , The systemd system and service manager is designed to be mostly compatible with SysV init and Upstart. The following are the most notable compatibility changes with regards to the previous major release of the Red Hat Enterprise Linux system: , Backwards compatibility with SysV init — Systemd supports SysV init scripts as described in the Linux Standard Base Core Specification, which eases the upgrade path to systemd service units. , In Red Hat Enterprise Linux 7, the systemd system and service manager provides the following main features:
For example, to override the default value of the timeout limit, which is set to 90 seconds, use the DefaultTimeoutStartSec parameter to input the required value in seconds.
DefaultTimeoutStartSec = required value
For clarity, all command examples in the rest of this section use full unit names with the .service file extension, for example:
~] # systemctl stop nfs - server.service
However, the file extension can be omitted, in which case the systemctl utility assumes the argument is a service unit. The following command is equivalent to the one above:
~] # systemctl stop nfs - server
Additionally, some units have alias names. Those names can have shorter names than units, which can be used instead of the actual unit names. To find all aliases that can be used for a particular unit, use:
~] # systemctl show nfs - server.service - p NamesTo list all currently loaded service units, type the following at a shell prompt:
systemctl list - units--type service
By default, the systemctl list-units command displays only active units. If you want to list all loaded units regardless of their state, run this command with the --all or -a command line option:
systemctl list - units--type service--allTo list all currently loaded service units, type the following at a shell prompt:
systemctl list - units--type service
By default, the systemctl list-units command displays only active units. If you want to list all loaded units regardless of their state, run this command with the --all or -a command line option:
systemctl list - units--type service--allYou can also list all available service units to see if they are enabled. To do so, type:
systemctl list - unit - files--type serviceTo list all installed service unit files to determine if they are enabled, type:
~] $ systemctl list - unit - files--type service UNIT FILE STATE abrt - ccpp.service enabled abrt - oops.service enabled abrt - vmcore.service enabled abrt - xorg.service enabled abrtd.service enabled ... wpa_supplicant.service disabled ypbind.service disabled 208 unit files listed.
To list all currently loaded service units, run the following command:
~] $ systemctl list - units--type service
UNIT LOAD ACTIVE SUB DESCRIPTION
abrt - ccpp.service loaded active exited Install ABRT coredump hook
abrt - oops.service loaded active running ABRT kernel log watcher
abrt - vmcore.service loaded active exited Harvest vmcores
for ABRT
abrt - xorg.service loaded active running ABRT Xorg log watcher
abrtd.service loaded active running ABRT Automated Bug Reporting Tool
...
systemd - vconsole - setup.service loaded active exited Setup Virtual Console
tog - pegasus.service loaded active running OpenPegasus CIM Server
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high - level unit activation state, i.e.generalization of SUB.
SUB = The low - level unit activation state, values depend on unit type.
46 loaded units listed.Pass--all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'To list all installed service unit files to determine if they are enabled, type:
~] $ systemctl list - unit - files--type service UNIT FILE STATE abrt - ccpp.service enabled abrt - oops.service enabled abrt - vmcore.service enabled abrt - xorg.service enabled abrtd.service enabled ... wpa_supplicant.service disabled ypbind.service disabled 208 unit files listed.
To display detailed information about a service unit that corresponds to a system service, type the following at a shell prompt:
systemctl status name.service
To only verify that a particular service unit is running, run the following command:
systemctl is - active name.service
Similarly, to determine whether a particular service unit is enabled, type:
systemctl is - enabled name.service
To determine what services are ordered to start before the specified service, type the following at a shell prompt:
~] # systemctl list - dependencies--after gdm.service
gdm.service├─ dbus.socket├─ getty @tty1.service├─ livesys.service├─ plymouth - quit.service├─ system.slice├─ systemd - journald.socket├─ systemd - user - sessions.service└─ basic.target[output truncated]To determine what services are ordered to start after the specified service, type the following at a shell prompt:
~] # systemctl list - dependencies--before gdm.service
gdm.service├─ dracut - shutdown.service├─ graphical.target│├─ systemd - readahead - done.service│├─ systemd - readahead - done.timer│└─ systemd - update - utmp - runlevel.service└─ shutdown.target├─ systemd - reboot.service└─ final.target└─ systemd - reboot.service
The service unit for the GNOME Display Manager is named gdm.service. To determine the current status of this service unit, type the following at a shell prompt:
~] # systemctl status gdm.service
gdm.service - GNOME Display Manager
Loaded: loaded(/usr/lib / systemd / system / gdm.service; enabled)
Active: active(running) since Thu 2013 - 10 - 17 17: 31: 23 CEST;
5 min ago
Main PID: 1029(gdm)
CGroup: /system.slice/gdm.service├─ 1029 / usr / sbin / gdm├─ 1037 / usr / libexec / gdm - simple - slave--display - id / org / gno...└─1047 / usr / bin / Xorg: 0 - background none - verbose - auth / r...
Oct 17 17: 31: 23 localhost systemd[1]: Started GNOME Display Manager.systemd-run may be used to create and start a transient .service or .scope unit and run the specified COMMAND in it. It may also be used to create and start a transient .path, .socket, or .timer unit, that activates a .service unit when elapsing.,Create a transient .scope unit instead of the default transient .service unit (see above). ,systemd-run — Run programs in transient scope units, service units, or path-, socket-, or timer-triggered service units,Make the new .service or .scope unit part of the specified slice, instead of system.slice (when running in --system mode) or the root slice (when running in --user mode).
# systemd - run env Running as unit: run - 19945. service # journalctl - u run - 19945. service Sep 08 07: 37: 21 bupkis systemd[1]: Starting / usr / bin / env... Sep 08 07: 37: 21 bupkis systemd[1]: Started / usr / bin / env. Sep 08 07: 37: 21 bupkis env[19948]: PATH = /usr/local / sbin: /usr/local / bin: /usr/sbin: /usr/bin Sep 08 07: 37: 21 bupkis env[19948]: LANG = en_US.UTF - 8 Sep 08 07: 37: 21 bupkis env[19948]: BOOT_IMAGE = /vmlinuz-3.11.0-0.rc5.git6.2.fc20.x86_64
# systemd - run - p BlockIOWeight = 10 updatedb
The following command will touch a file after 30 seconds.
# date; systemd - run--on - active = 30--timer - property = AccuracySec = 100 ms / bin / touch / tmp / foo Mon Dec 8 20: 44: 24 KST 2014 Running as unit: run - 71. timer Will run service as unit: run - 71. service # journalctl - b - u run - 71. timer --Journal begins at Fri 2014 - 12 - 05 19: 09: 21 KST, ends at Mon 2014 - 12 - 08 20: 44: 54 KST.-- Dec 08 20: 44: 38 container systemd[1]: Starting / bin / touch / tmp / foo. Dec 08 20: 44: 38 container systemd[1]: Started / bin / touch / tmp / foo. # journalctl - b - u run - 71. service --Journal begins at Fri 2014 - 12 - 05 19: 09: 21 KST, ends at Mon 2014 - 12 - 08 20: 44: 54 KST.-- Dec 08 20: 44: 48 container systemd[1]: Starting / bin / touch / tmp / foo... Dec 08 20: 44: 48 container systemd[1]: Started / bin / touch / tmp / foo.
The following command invokes bash(1) as a service passing its standard input, output and error to the calling TTY.
# systemd - run - t--send - sighup bash$ systemd - run--scope--user screen
Running scope as unit run - r14b0047ab6df45bfb45e7786cc839e76.scope.
$ screen - ls
There is a screen on:
492..laptop(Detached)
1 Socket in /var/run / screen / S - fatima.Enabling lingering allows the user to run processes without being logged in, for example to allow screen to persist after the user logs out, even if the session scope is terminated. In the default configuration, users can enable lingering for themselves:
$ loginctl enable - linger
$ systemd - run--user--wait true
$ systemd - run--user--wait - p SuccessExitStatus = 11 bash - c 'exit 11'
$ systemd - run--user--wait - p SuccessExitStatus = SIGUSR1 bash - c 'kill -SIGUSR1 $$$$'To launch a script at startup a proper service file have to be created and added to the systemd.,Let's create for example a service file to launch a Python program called blink.py. Create as root a file called blink.service in /lib/systemd/system directory.,Next systemd has to be configured, enabling the service so at the next reboot it will be started automatically. First off, though, the systemd itself has to be reloaded in order to detect the new service definition:,Then is your are using the same file of previous example disable the blink.service and enable just the blink.timer to start it after the bootstrap:
Let's create for example a service file to launch a Python program called blink.py. Create as root
a file called blink.service in /lib/systemd/system directory.
sudo nano / lib / systemd / system / blink.service
then save inside it this content:
[Unit]
Description = Blinking led
After = network.target
[Service]
Type = idle
ExecStart = /usr/bin / python / root / blink.py
Restart = always
User = root
[Install]
WantedBy = multi - user.targetNext systemd has to be configured, enabling the service so at the next reboot it will be started automatically. First off, though, the systemd itself has to be reloaded in order to detect the new service definition:
sudo systemctl daemon - reload
Check if it is enabled:
systemctl list - unit - files | grep enabled
Of course, it can be started manually just now:
sudo systemctl start blink