This page is about the Service unit type of SystemD .service (ie about systemd.service)
It is designed to replace and be backwards compatible with SysV init scripts. Traditional init scripts continue to function on a systemd system. An init script /etc/rc.d/init.d/foobar is implicitly mapped into a service unit foobar.service during system initialization.
In Red Hat Enterprise Linux 7, systemd replaces Upstart as the default init system.
Units are representations of resources that systemd knows about.
A Systemd output may show the following columns
- UNIT: The systemd unit name
- LOAD: Loaded in memory ?
- ACTIVE: Does the unit has been successfuly processed ?
- SUB: State information that varies by unit
- DESCRIPTION: description of the unit
- STATE: state of a unit file:
- ie the unit file does not contain an “install” section and therefore the unit cannot be enabled
- used for single action or as a dependency of another units
- or “masked”.
systemctl cat foobar.service
[Unit] Description=foobar daemon After=network.target [Service] Type=forking User=infa ; sleep for 5 minutes to ensure headnode is up and running ExecStartPre=/bin/sleep 300 ExecStart=/usr/bin/daemon startup ExecStop=/usr/bin/daemon shutdown TimeoutSec=infinity TimeoutStartSec=10min 10sec [Install] WantedBy=multi-user.target
Example for java with redirections
ExecStart=/bin/sh -c 'exec /bin/java -jar xxx.jar -Xmx512M -Xms32M >> /data/logs/xxx.log 2>&1'
Unit file path
- /usr/lib/systemd/ for files that ships with packages
- /etc/systemd/system/ for admin modification
- /lib/systemd/ ??
- The process started by the command is the main process
- The process should not be run in the background but in the foreground
- The service is considered up immediately
- The command will create a child process that will run as the main service process,
- The service manager will consider the unit started when the parent process exits.
- same as simple but the service considered up after the systemd terminate the launch.
Environment variable possibilities can be seen here: SystemD - Environment Variable for a service
Redirection of the standard stream of the application.
To query it, see SystemD - Journalctl
- Create a new file
- query the state of all services, both systemd native and SysV/LSB services
- List services
systemctl list-units --all --type=service #-all because list-units command shows only active units by default # State systemctl list-units --all --state=inactive
- To see every unit file if something goes wrong
- unit file
systemctl cat foobar.service
- Service properties
systemctl show sshd.service
You cannot used infinity for the timeout everywhere
# all timeout property systemctl show node.service | grep -i Timeout* # By property systemctl show node.service -p TimeoutStartSec systemctl show node.service -p TimeoutStopSec systemctl show node.service -p TimeoutSec # A shorthand for configuring both TimeoutStartSec= and TimeoutStopSec= to the specified value # ''-p --property=NAME'' Show only properties by this name
- TimeoutStartSec Configures the time to wait for start-up. If a daemon service does not signal start-up completion within the configured time, the service will be considered failed and will be shut down again. Default to DefaultTimeoutStartSec from the manager configuration file, except when Type=oneshot is used, in which case the timeout is disabled by default . Takes a unit-less value in seconds, or a time span value such as “5min 20s”. Pass “infinity” to disable the timeout logic.
; 15 min TimeoutSec=900
systemctl list-dependencies sshd.service
sshd.service ├─system.slice └─basic.target ├─microcode.service ├─rhel-autorelabel-mark.service ├─rhel-autorelabel.service ├─rhel-configure.service ├─rhel-dmesg.service ├─rhel-loadmodules.service ├─paths.target ├─slices.target . . .
sudo systemctl start foobar.service # as systemd knows to look for *.service files for service management commands sudo systemctl start foobar
Fail If the start fails, systemctl will give you a generic error message:
systemctl start foo.service
Job failed. See system journal and 'systemctl status' for details.
- the stdout, stderr of services are directed to the systemd journal (journalctl command)
- the logs that services produce via syslog go by default to /var/log/messages and to the SystemD Journal
- systemd stores the exit code of failed services.
- Run systemctl status as root or as a user from the adm group to get a journal extract
systemctl status foo.service
- or list the journal with the journalctl command.
journalctl --unit foo
- or list the syslog message (default to /var/log/messages)
systemctl stop foobar.service
sudo systemctl restart foobar.service # if you don't know sudo systemctl reload-or-restart application.service
- Reload config file
sudo systemctl reload foobar.service
systemctl is-active application.service
systemctl is-failed application.service
Whether the service should start on boot.
sudo systemctl enable foobar.service # isEnabled systemctl is-enabled application.service
sudo systemctl disable foobar.service
Ansible - Disable if exists
- name: Populate service facts service_facts: - name: Disable firewalld when: "'firewalld.service' in services" systemd: name: firewalld enabled: no state: stopped
systemctl status application.service
Example with cron
systemctl status crond.service
● crond.service - Command Scheduler Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled) Active: active (running) since Wed 2019-02-20 14:56:00 UTC; 1 weeks 6 days ago Main PID: 6339 (crond) CGroup: /system.slice/crond.service └─6339 /usr/sbin/crond -n
- Copy the unit script to /etc/systemd/system/
cp foobar.service /etc/systemd/system/
- Restart systemd:
- Enable het script voor autorun:
systemctl enable infaservice
- The service can be managed via
systemctl [start|stop|status] foobar