● myApplication.service - myApplication Java application Loaded: loaded (/etc/systemd/system/myApplication.service_4.1-RELEASE; bad) Active: failed (Result: start-limit-hit) since Wed 2020-03-04 10:19:40 UTC; 7s ago Process: 103744 ExecStop=/bin/kill -15 $(systemctl status myApplication.service | awk /Main PID/ {print $3}) (code=exited, status=1/FAILURE) Process: 103742 ExecStart=/usr/bin/java -jar myApplication.jar --spring.config.location=classpath:/,file:application.yaml (code=exited, status=1/FAILURE) Main PID: 103742 (code=exited, status=1/FAILURE)
[Unit] Description=myApplication Java application [Service] WorkingDirectory=/path/to/myApplication ExecStart=/usr/bin/java -jar myApplication.jar --spring.config.location=classpath:/,file:application.yaml ExecStop=/bin/kill -15 $(systemctl status myApplication.service | awk '/Main PID/ {print $3}') User=kevin Group=robots Restart=on-failure [Install] WantedBy=multi-user.target
Mar 04 10:34:21 myServer systemd[1]: Started myApplication Java application. Mar 04 10:34:21 myServer systemd[1]: myApplication.service: Main process exited, code=exited, status=1/FAILURE the startup fails Mar 04 10:34:21 myServer kill[104802]: kill: failed to parse argument: 'status' the ExecStop command fails too (but this is "normal" here) Mar 04 10:34:21 myServer systemd[1]: myApplication.service: Control process exited, code=exited status=1 Mar 04 10:34:21 myServer systemd[1]: myApplication.service: Unit entered failed state. Mar 04 10:34:21 myServer systemd[1]: myApplication.service: Failed with result 'exit-code'. Mar 04 10:34:21 myServer systemd[1]: myApplication.service: Service hold-off time over, scheduling restart. Mar 04 10:34:21 myServer systemd[1]: Stopped myApplication Java application. Mar 04 10:34:21 myServer systemd[1]: Started myApplication Java application. (looping 4 more times)
● varnishncsa.service - Varnish Cache HTTP accelerator NCSA logging daemon Loaded: loaded (/etc/systemd/system/varnishncsa.service; enabled; vendor preset: enabled) Active: active (running) since Thu 2020-02-20 02:16:03 CET; 1 weeks 4 days ago Main PID: 3309 (varnishncsa) CGroup: /system.slice/varnishncsa.service └─3309 /usr/bin/varnishncsa [options...] Mar 02 10:39:12 myServer systemd[1]: varnishncsa.service: Failed to set invocation ID on control group /system.slice/varnishncsa.service, ignoring: Operation not permitted
ssh
ssh.service enabled ssh@.service static sshd.service enabled ssh.socket disabled
/ssh.*enabled
/ {print $1}' | xargs systemctl status● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled) Active: inactive (dead) since Tue 2016-12-06 15:36:52 CET; 16min ago Main PID: 662 (code=exited, status=0/SUCCESS) Dec 02 17:23:45 caramba sshd[662]: Server listening on 0.0.0.0 port 22. Dec 02 17:23:45 caramba sshd[662]: Server listening on :: port 22. Dec 02 17:23:45 caramba systemd[1]: Reloaded OpenBSD Secure Shell server. ● ssh.service - OpenBSD Secure Shell server Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled) Active: inactive (dead) since Tue 2016-12-06 15:36:52 CET; 16min ago Main PID: 662 (code=exited, status=0/SUCCESS) Dec 02 17:23:45 caramba sshd[662]: Server listening on 0.0.0.0 port 22. Dec 02 17:23:45 caramba sshd[662]: Server listening on :: port 22. Dec 02 17:23:45 caramba systemd[1]: Reloaded OpenBSD Secure Shell server.
Same PID, so ssh.service == sshd.service
Alias
/lib/systemd/system/ssh.serviceAlias=sshd.service
lrwxrwxrwx 1 root root 31 Mar 27 2017 /etc/systemd/system/sshd.service -> /lib/systemd/system/ssh.service
Service | unit configuration file |
---|---|
syslog | /etc/systemd/system/syslog.service |
LogLevelMax=errdon't know in which section yet : Unit / Service ?
Directive | Default value | Description |
---|---|---|
LogLevelMax=level | debug | Per-unit setting defining the maximum log level (i.e. verbosity) of log messages. level is one of syslog log levels :
|
This article is about :
Instead of runlevels, systemd allows you to create different states, which gives you a flexible mechanism for creating different configurations to boot into. These states are composed of multiple unit files bundled into targets. Targets have nice descriptive names instead of numbers. Unit files control services, devices, sockets, and mounts.
With systemd :ll /etc/systemd/system/multi-user.target.wants/ lrwxrwxrwx 1 root root 35 nov. 23 21:01 anacron.service -> /lib/systemd/system/anacron.service lrwxrwxrwx 1 root root 31 nov. 23 21:01 atd.service -> /lib/systemd/system/atd.service lrwxrwxrwx 1 root root 32 nov. 23 20:24 cron.service -> /lib/systemd/system/cron.service lrwxrwxrwx 1 root root 40 nov. 23 21:02 ModemManager.service -> /lib/systemd/system/ModemManager.service lrwxrwxrwx 1 root root 42 nov. 23 21:02 NetworkManager.service -> /lib/systemd/system/NetworkManager.service lrwxrwxrwx 1 root root 31 nov. 23 21:02 ssh.service -> /lib/systemd/system/ssh.service ...
Not sure if this is a general rule, but many systemd services are now called "daemon.service" : ssh.service, tomcat8.service, ...
(nothing)
mysql.service loaded active running LSB: Start and stop the mysql database server daemon
http://forums.fedoraforum.org/showthread.php?t=261945 'service' operates on the files in /etc/init.d and was used in conjunction with the old init system. 'systemctl' operates on the files in /lib/systemd If there is a file for your service in /lib/systemd, it will use that first. Otherwise it will fall back to the file in /etc/init.d In theory service is supposed to be linked to systemctl but in the F16 branch it looks like they are starting to disable that.