Identify the Init bin? systemd or upstart:
Open terminal (ctrl+alt+t) and checks for the long listing for the /sbin/init file. The sample output is shown below (I run in my ubuntu 16.04)
This has changed as part of the Ubuntu 15.04 devel cycle.
Open terminal (ctrl+alt+t) and checks for the long listing for the /sbin/init file. The sample output is shown below (I run in my ubuntu 16.04)
lrwxrwxrwx 1 root root 20 Jan 19 03:34 /sbin/init -> /lib/systemd/systemd
How to understand a systemd service?
System Init Daemon
This has changed as part of the Ubuntu 15.04 devel cycle.
Ubuntu 15.04 (using Systemd by default):
Systemd runs with PID 1 as /sbin/init.
Upstart runs with PID 1 as /sbin/upstart.
Prior versions (using Upstart by default):
Upstart runs with PID 1 as /sbin/init.
Systemd runs with PID 1 as /lib/systemd/systemd.
High-level startup concept
Upstart's model for starting processes (jobs) is "greedy event-based", i. e. all available jobs whose startup events happen are started as early as possible. During boot, upstart synthesizes some initial events like startup or rcS as the "tree root", the early services start on those, and later services start when the former are running. A new job merely needs to install its configuration file into /etc/init/ to become active.
systemd's model for starting processes (units) is "lazy dependency-based", i. e. a unit will only start if and when some other starting unit depends on it. During boot, systemd starts a "root unit" (default.target, can be overridden in grub), which then transitively expands and starts its dependencies. A new unit needs to add itself as a dependency of a unit of the boot sequence (commonly multi-user.target) in order to become active.
Invalid configurations
- upstart
- Refuses to start a job if it contains invalid syntax.
- systemd
Ignores invalid directives and starts the service. Note that you must test your configuration carefully since a typo will not be detected! Use systemd-analyze verify <unit> file to get warnings on typos and badly formatted option
Override Files
- upstart
Create file "/etc/init/$job.override" containing one or more stanzas which take priority over their counterparts from the original "$job.conf" file.
- systemd
- Systemd allows a similar facility via "drop-ins": a drop-in allows a directive to be modified without changing the original unit file. To create a drop-in:
- Create a subdirectory below either "/etc/systemd/system/" or "/lib/systemd/system/" called "${unit}.d/".
- Create files called <something>.conf in the "${unit}.d/" directory containing the directives that you wish to overriden.
Commands
Note that these are commands for interactive human usage. Package maintainer scripts, ifupdown hooks and similar must always use the init system agnostic abstractions like invoke-rc.d.
Operation
|
Upstart Command
|
Systemd equivalent
| |
Start service
|
start $job
|
systemctl start $unit
| |
Stop service
|
stop $job
|
systemctl stop $unit
| |
Restart service
|
restart $job
|
systemctl restart $unit
| |
See status of services
|
initctl list
|
systemctl status
| |
Check configuration is valid
|
init-checkconf /tmp/foo.conf
|
systemd-analyze verify <unit_file>
| |
Show job environment
|
initctl list-env
|
systemctl show-environment
| |
Set job environment variable
|
initctl set-env foo=bar
|
systemctl set-environment foo=bar
| |
Remove job environment variable
|
initctl unset-env foo
|
systemctl unset-environment foo
| |
View job log
|
cat /var/log/upstart/$job.log
|
sudo journalctl -u $unit
| |
tail -f job log
|
tail -f /var/log/upstart/$job.log
|
sudo journalctl -u $unit -f
| |
Show relationship between services
|
initctl2dot
|
systemctl list-dependencies --all
|
Example Services
Example Upstart Service
/etc/init/foo.conf:
description "Job that runs the foo daemon"# start in normal runlevels hen disks are mounted and networking is availablestart on runlevel [2345]# stop on shutdown/halt, single-user mode and rebootstop on runlevel [016]env statedir=/var/cache/foo# create a directory needed by the daemonpre-start exev mkdir -p "$statedir"exec /usr/bin/foo-daemon --arg1 "hello world" --statedir "$statedir"
Example Systemd service
/lib/systemd/system/foo.service:
[Unit]Description=Job that runs the foo daemonDocumentation=man:fll(1)[Service]Type=forkingEnvironment=statedir=/var/cache/fooExecStartPre=/usr/bin/mkdir -p ${statedir}ExecStart=/usr/bin/foo-daemon --arg1 "hello world" --statedir ${statedir}[Install]WantedBy=multi-user.target
Why don't some commands (like grep) work in /lib/systemd/system ?
If you hit this problem...
$ cd /lib/systemd/system $ grep foo * grep: invalid option -- '.' Usage: grep [OPTION]... PATTERN [FILE]... Try 'grep --help' for more information.
... you need to add "--" to the grep(1) call:
$ cd /lib/systemd/system $ grep foo -- *
This is required since systemd provides a file called "-.slice". After the shell has expanded the asterisk ("*"), that file gets passed to the command in question (grep, cat, etc) and that command will then attempt to interpret "-.slice" as a command-line option rather than a filename.
Alternative work-around:
$ cd /lib/systemd/system $ POSIXLY_CORRECT=1 grep foo *
To view the pesky file:
$ cd /lib/systemd/system $ cat -- -.slice
Note that this issue only occurs when your current working directory is the directory containing "-.slice". The simplest work-around is to make the grep or cat call from a different directory:
$ grep foo /lib/systemd/system/* $ cat /lib/systemd/system/-.slice
From a running system
Upstart
To switch to debug mode for the system init (PID 1):
$ sudo initctl log-priority debug
To switch to debug mode for a session init (init PID != 1):
$ initctl log-priority debug $ tail -f ~/.xsession-errors
Appendix
- systemd manpages for service writers:
-
No comments:
Post a Comment