* Systemd *
Systemd is a new, faster, system and service manager for Linux, compatible with SysV and LSB init scripts. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux cgroups, supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic. It can work as a drop-in replacement for sysvinit.
to list all running systems
$ systemctl -t service | less
boot-up services
To display a list of all active system services, use the following command:
$ systemctl list-units --type=service
To see the boot-up processes that are the slowest,
# yum install systemd-analyze
To list the services started at boot-up in order of slowest services first,
$ systemd-analyze blame
systemd-analyze plot > [filename].svg
eog [filename].svg
a built-in complement for bootchart
It shows, charts, the time services spent to start up in relation to the other services and then, eog displays the chart.
Bootchart is by far the more powerful tool. It plots in all detail what is happening during the boot, how much CPU and IO is used. systemd-analyze plot shows more high-level data: which service took how much time to initialize, and what needed to wait for it. If you use them both together you’ll have a wonderful toolset to figure out why your boot is not as fast as it could be.
For more “fast booting” options, see
http://www.harald-hoyer.de/personal/blog/fedora-17-boot-optimization-from-15-to-3-seconds
Using systemd — systemctl
systemctl: used to introspect and control the state of the systemd system and service manager
systemd-cgls: recursively shows the contents of the selected Linux control group hierarchy in a tree
systemadm: a graphical frontend for the systemd system and service manager that allows introspection and control of systemd (avaiable via the systemd-ui-git package from the AUR).
View the man pages for more details.
List all services:
$ systemctl
or:
$ systemctl list-units –type=service
To show the status of a service, including whether it is running or not.
# systemctl status {service}.service
examples:
# systemctl status httpd.service
# systemctl status sendmail.service
Check whether a service is already enabled or not:
# systemctl is-enabled {service}.service
example: # systemctl is-enabled sshd.service
The available services or units can be seen in /usr/lib/systemd/system/ and /etc/systemd/system/ (the latter takes precedence).
Activate a service immediately:
# systemctl start {service}.service
Deactivate a service immediately:
# systemctl stop {service}.service
Restart a service:
# systemctl restart {service}.service
Reload the configuration of a service:
# systemctl reload {service}.service
Enable a service to be started on bootup:
# systemctl enable {service}.service
Disable a service to not start during bootup:
# systemctl disable {service}.service
Refer to man systemctl for more details.
Notice that you need to use the full name of a service file. Example, in order to restart the avahi daemon, issue:
# systemctl restart avahi-daemon.service
Shut down and reboot the system:
# systemctl reboot
Shut down and power-off the system:
# systemctl poweroff
Shut down and halt the system:
# systemctl halt
runlevels
runlevels/targets
Runlevels is a legacy concept in systemd. Systemd uses targets which serve a similar purpose as runlevels but act a little different. Each target is named instead of numbered and is intended to serve a specific purpose with the possibility of having multiple ones active at the same time. Some targets are implemented by inheriting all of the services of another target and adding additional services to it. There are systemd targets that mimic the common SystemVinit runlevels so you can still switch targets using the familiar telinit RUNLEVEL command.
Get current runlevel/targets
The following should be used under systemd instead of runlevel:
# systemctl list-units --type=target
Create custom target
The runlevels that are assigned a specific purpose on vanilla Fedora installs; 0, 1, 3, 5, and 6; have a 1:1 mapping with a specific systemd target. Unfortunately, there is no good way to do the same for the user-defined runlevels like 2 and 4.
Change default runlevel/target to boot into
The standard target is default.target, which is aliased by default to graphical.target (which roughly corresponds to the old runlevel 5). To change the default target at boot-time, append one of the following kernel parameters to your bootloader:
systemd.unit=multi-user.target (which roughly corresponds to the old runlevel 3),
systemd.unit=rescue.target (which roughly corresponds to the old runlevel 1).
Configure kernel modules to load during boot
systemd uses /etc/modules-load.d/ to configure kernel modules to load during boot in a static list. Each configuration file is named in the style of /etc/modules-load.d/
Example:
the file-name:
/etc/modules-load.d/virtio-net.conf
the contents:
# Load virtio-net.ko at boot
virtio-net
Describe temporary files
Systemd-tmpfiles uses the configuration files in /etc/tmpfiles.d/ to describe the creation, cleaning and removal of volatile and temporary files and directories which usually reside in directories such as /run or /tmp. Each configuration file is named in the style of /etc/tmpfiles.d/
see full article at
wiki.archlinux.org/index.php/Systemd
the three most relevant init systems for Linux: sysvinit, Upstart and systemd.
Why systemd?
I am of course one of the creators of systemd. I will try my best to be fair to the other two contenders, but in the end, take it with a grain of salt. I am sure though that should I be grossly unfair or otherwise incorrect somebody will point it out in the comments of this story …
systemd is in the process of becoming a comprehensive, integrated and modular platform providing everything needed to bootstrap and maintain an operating system’s userspace. It includes C rewrites of all basic early boot init scripts that are shipped with the various distributions. Especially for the embedded case adopting systemd provides you in one step with almost everything you need, and you can pick the modules you want. The other two init systems are singular individual components, which to be useful need a great number of additional components with differing interfaces. The emphasis of systemd to provide a platform instead of just a component allows for closer integration, and cleaner APIs. Sooner or later this will trickle up to the applications. Already, there are accepted XDG specifications (e.g. XDG basedir spec, more specifically XDG_RUNTIME_DIR) that are not supported on the other init systems.
systemd is also a big opportunity for Linux standardization. Since it standardizes many interfaces of the system that previously have been differing on every distribution, on every implementation, adopting it helps to work against the balkanization of the Linux interfaces. Choosing systemd means redefining more closely what the Linux platform is about. This improves the lifes of programmers, users and administrators alike.
General Features
| sysvinit | Upstart | systemd | |
|---|---|---|---|
| Interfacing via D-Bus | no | yes | yes |
| Shell-free bootup | no | no | yes |
| Modular C coded early boot services included | no | no | yes |
| Read-Ahead | no | no[1] | yes |
| Socket-based Activation | no | no[2] | yes |
| Socket-based Activation: inetd compatibility | no | no[2] | yes |
| Bus-based Activation | no | no[3] | yes |
| Device-based Activation | no | no[4] | yes |
| Configuration of device dependencies with udev rules | no | no | yes |
| Path-based Activation (inotify) | no | no | yes |
| Timer-based Activation | no | no | yes |
| Mount handling | no | no[5] | yes |
| fsck handling | no | no[5] | yes |
| Quota handling | no | no | yes |
| Automount handling | no | no | yes |
| Swap handling | no | no | yes |
| Snapshotting of system state | no | no | yes |
| XDG_RUNTIME_DIR Support | no | no | yes |
| Optionally kills remaining processes of users logging out | no | no | yes |
| Linux Control Groups Integration | no | no | yes |
| Audit record generation for started services | no | no | yes |
| SELinux integration | no | no | yes |
| PAM integration | no | no | yes |
| Encrypted hard disk handling (LUKS) | no | no | yes |
| SSL Certificate/LUKS Password handling, including Plymouth, Console, wall(1), TTY and GNOME agents | no | no | yes |
| Network Loopback device handling | no | no | yes |
| binfmt_misc handling | no | no | yes |
| System-wide locale handling | no | no | yes |
| Console and keyboard setup | no | no | yes |
| Infrastructure for creating, removing, cleaning up of temporary and volatile files | no | no | yes |
| Handling for /proc/sys sysctl | no | no | yes |
| Plymouth integration | no | yes | yes |
| Save/restore random seed | no | no | yes |
| Static loading of kernel modules | no | no | yes |
| Automatic serial console handling | no | no | yes |
| Unique Machine ID handling | no | no | yes |
| Dynamic host name and machine meta data handling | no | no | yes |
| Reliable termination of services | no | no | yes |
| Early boot /dev/log logging | no | no | yes |
| Minimal kmsg-based syslog daemon for embedded use | no | no | yes |
| Respawning on service crash without losing connectivity | no | no | yes |
| Gapless service upgrades | no | no | yes |
| Graphical UI | no | no | yes |
| Built-In Profiling and Tools | no | no | yes |
| Instantiated services | no | yes | yes |
| PolicyKit integration | no | no | yes |
| Remote access/Cluster support built into client tools | no | no | yes |
| Can list all processes of a service | no | no | yes |
| Can identify service of a process | no | no | yes |
| Automatic per-service CPU cgroups to even out CPU usage between them | no | no | yes |
| Automatic per-user cgroups | no | no | yes |
| SysV compatibility | yes | yes | yes |
| SysV services controllable like native services | yes | no | yes |
| SysV-compatible /dev/initctl | yes | no | yes |
| Reexecution with full serialization of state | yes | no | yes |
| Interactive boot-up | no[6] | no[6] | yes |
| Container support (as advanced chroot() replacement) | no | no | yes |
| Dependency-based bootup | no[7] | no | yes |
| Disabling of services without editing files | yes | no | yes |
| Masking of services without editing files | no | no | yes |
| Robust system shutdown within PID 1 | no | no | yes |
| Built-in kexec support | no | no | yes |
| Dynamic service generation | no | no | yes |
| Upstream support in various other OS components | yes | no | yes |
| Service files compatible between distributions | no | no | yes |
| Signal delivery to services | no | no | yes |
| Reliable termination of user sessions before shutdown | no | no | yes |
| utmp/wtmp support | yes | yes | yes |
| Easily writable, extensible and parseable service files, suitable for manipulation with enterprise management tools | no | no | yes |
see full article by Lennart Poettering at
0pointer.de/blog/projects/why.html
The old * chkconfig *
chkconfig from SysVInit is still used on Redhat and Centos
examples:
list all processes that are running:
# chkconfig --list | grep ":on"
Disabling daemons
# chkconfig [name] off
example:
if the firewall (iptables) is on levels 3 and 5, turn it off with
# chkconfig --level 35 iptables off
to start a deamon at boot-up and set its run levels
examples mysql and http:
# chkconfig --add mysqld
# chkconfig --level 35 mysqld on
# chkconfig --add httpd
# chkconfig --level 35 httpd on
to restart a deamon
examples:
# service sshd restart
# service httpd restart
# service mysqld restart
to check if a service is running
example (apache):
# service httpd status