|
|
| (39 intermediate revisions by 7 users not shown) |
| Line 1: |
Line 1: |
| {{header|docs}} | | {{header|docs}} |
| {{Docs_beat_open}}
| |
| {{Draft| '''NEED rewrite''': insert the '''boot options''', remove or move some contents to other places, perhaps split it}}
| |
| = systemd =
| |
|
| |
|
| '''systemd''' is a system and service manager, replacement for SysVinit and Upstart. After a six months shift, during which it has been more granulary tested, F15 brings in, by default, a new system daemon whose code is designed from scratch, with the objective to take the maximum advantage offered by modern Linux kernel.
| | {{Docs_beat_closed}} |
| | |
| With '''systemd''', Fedora 15 boots-up faster, particularly on SSD; native systemd service configuration files (or units) are much easier to understand and configure compared to sysvinit scripts, as systemd uses <code>.service</code> files instead of bash script; all daemons are sorted into their own Linux cgroups, which you may explore beneath <code>/cgroup/systemd</code> in the file system hierarchy; administrative features of the init system are considerably extended.
| |
| | |
| ?!!? Insert here the daemons updated to ship native service files ?!!?
| |
| | |
| == systemd units ==
| |
| | |
| '''(clean up)'''
| |
| | |
| systemd starts up and supervises the entire system and is based around the notion of ''units'' composed of a name and a type and matching a configuration file with the same name and type (e.g. a unit avahi.service has a configuration file with the same name and is a unit encapsulating the Avahi daemon). There are seven types of unit:
| |
| | |
| # <code>service</code>: these are the most obvious kind of unit: daemons that can be started, stopped, restarted, reloaded.
| |
| # <code>socket</code>: this unit encapsulates a socket in the file-system or on the Internet. systemd currently support AF_INET, AF_INET6, AF_UNIX sockets of the types stream, datagram, and sequential packet. It can also support classic FIFOs as transport. Each socket unit has a matching service unit, that is started if the first connection comes in on the socket or FIFO (e.g. nscd.socket starts nscd.service on an incoming connection).
| |
| # <code>device</code>: this unit encapsulates a device in the Linux device tree. If a device is marked for this via udev rules, it will be exposed as a device unit in systemd. Properties set with udev can be used as configuration source to set dependencies for device units.
| |
| # <code>mount</code>: this unit encapsulates a mount point in the file system hierarchy.
| |
| # <code>automount</code>: this unit type encapsulates an automount point in the file system hierarchy. Each automount unit has a matching mount unit, which is started (i.e. mounted) as soon as the automount directory is accessed.
| |
| # target: this unit type is used for logical grouping of units: instead of actually doing anything by itself it simply references other units, which thereby can be controlled together. (e.g. multi-user.target, which is a target that basically plays the role of run-level 5 on classic SysV system; or bluetooth.target which is requested as soon as a bluetooth dongle becomes available and which simply pulls in bluetooth related services that otherwise would not need to be started: bluetoothd and obexd and suchlike).
| |
| # <code>snapshot</code>: similar to target units snapshots do not actually do anything themselves and their only purpose is to reference other units.
| |
| | |
| == systemd features ==
| |
| '''(remove to other place)'''
| |
| | |
| '''systemd''' provides the following:
| |
| * aggressive parallelization capabilities using socket: To speed up the entire boot and start more processes in parallel, systemd creates the listening sockets before actually starting the daemon, and then just passes the socket to it. All sockets for all daemons are created in one step in the init system, and then in a second step run all daemons at once. If a service needs another, and it is not fully started up, what will happen is that the connection is queued in the providing service and the client will potentially block on that single request. But only that one client will block and only on that one request. Also, dependencies between services no longer have to be configured to allow proper parallelized start-up: starting all sockets at once and a service needing another, it surely can connect to its socket.
| |
| | |
| * D-Bus activation for starting services: Using bus activation, a service can be started the first time it is accessed. Bus activation also gives the minimal per-request synchronisation needed for starting up the providers and the consumers of D-Bus services at the same time: starting a service at the same time as another, if one is quicker, than via the bus activation logic the D-Bus queues the request until the other manages to establish its service name.
| |
|
| |
| * offers on-demand starting of daemons
| |
| | |
| * keeps track of processes using Linux [http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt cgroups]: Every executed process gets its own cgroup and it is very easy to configure systemd to place services in cgroups that have been configured externally, for example via the libcgroups utilities.
| |
| | |
| * supports snapshotting and restoring of the system state: Snapshots can be used to save/rollback the state of all services and units of the init system. Primarily it has two intended use cases: to allow the user to temporarily enter a specific state such as "Emergency Shell", terminating current services, and provide an easy way to return to the state before, pulling up all services again that got temporarily pulled down.
| |
|
| |
| * maintains mount and automount points: Systemd monitors all mount points how they come and go, and can also be used to mount or unmount mount-points. /etc/fstab can be used here as an additional configuration source for these mount points. Using the <code>comment=</code> fstab option you can even mark <code>/etc/fstab</code> entries to become systemd controlled automount points..
| |
|
| |
| * implements an elaborate transactional dependency-based service control logic: Systemd supports several kinds of dependencies between services (or units), using ''After''/''Before'', ''Requires'' and ''Wants'' options in the unit configuration files to fix the ordering how units are activated. ''Requires'' and ''Wants'', express a positive requirement dependency, either mandatory, or optional. There is ''Conflicts'' which expresses a negative requirement dependency, and others less used. As a transactional control, if a unit is requested to start up or shut down, systemd will add it and all its dependencies to a temporary transaction, verifing if the transaction is consistent (or the ordering via After/Before of all units is cycle-free). If it is not, systemd will try to fix it up, and removes non-essential jobs from the transaction that might remove the loop.
| |
| | |
| and:
| |
| | |
| * For each process spawned, it controls: The environment, resource limits, working and root directory, umask, OOM killer adjustment, nice level, IO class and priority, CPU policy and priority, CPU affinity, timer slack, user id, group id, supplementary group ids, readable/writable/inaccessible directories, shared/private/slave mount flags, capabilities/bounding set, secure bits, CPU scheduler reset of fork, private /tmp name-space, cgroup control for various subsystems. Also, you can easily connect <code>stdin/stdout/stderr</code> of services to <code>syslog</code>, <code>/dev/kmsg</code>, arbitrary TTYs. If connected to a TTY for input systemd will make sure a process gets exclusive access, optionally waiting or enforcing it.
| |
| | |
| * The native configuration files use a syntax that closely follows the well-known <code>.desktop</code> files: It is a simple syntax for which parsers exist already in many software frameworks. Also, this allows to rely on existing tools for i18n for service descriptions, and similar, without for admins the need to learn a new syntax.
| |
| | |
| {{admon/note|systemadm | | |
| There's a minimal UI, <code>systemadm</code> that allows to start/stop/introspect services. It's a work in progress, but useful as a debugging tool. It's written in Vala.}}
| |
| | |
| (... and more advanced)
| |
| | |
| * Compatibility with SysV init scripts: It takes advantages of LSB and Red Hat chkconfig headers if they are available, if not, it uses otherwise available information, such as the start priorities in /etc/rc.d. These init scripts are simply considered a different source of configuration, easing the upgrade path to proper systemd services.
| |
| | |
| * /etc/fstab configuration file: it just another source of configuration. Using the comment= fstab option it is possible to mark /etc/fstab entries to become systemd controlled automount points.
| |
| | |
| * Support a simple templating/instance mechanism: For example, instead of having six configuration files for six gettys, it has only one getty@.service file which gets instantiated to getty@tty2.service and suchlike. The interface part can even be inherited by dependency expressions, i.e. it is easy to encode that a service dhcpcd@eth0.service pulls in avahi-autoipd@eth0.service, while leaving the eth0 string wild-carded.
| |
| | |
| * Compatibility, to a certain extent, with <code>/dev/initctl</code>. This compatibility is in fact implemented with a FIFO-activated service, which simply translates these legacy requests to D-Bus requests. Effectively this means the old shutdown, poweroff and similar commands from Upstart and sysvinit continue to work with systemd.
| |
| | |
| * Compatibility with <code>utmp</code> and <code>wtmp</code> (To an extent that is far more than healthy, given how crufty <code>utmp</code> and <code>wtmp</code> today are).
| |
| | |
| {{admon/note|For system administrators|
| |
| System administrators can visit [[SysVinit_to_Systemd_Cheatsheet| this page]], to understand how to use the native <code>systemctl</code> calls that replace their old workflow in SysVinit. Note that the <code>service</code> and <code>chkconfig</code> commands will continue to work as expected in the '''systemd''' world.}}
| |
| | |
| For all details view [http://0pointer.de/blog/projects/systemd.html A short list of other features] on the developer blog.
| |
| | |
| == Tools == (remove to other place)
| |
| * <code>systemctl</code>: used to introspect and control the state of the systemd system and service manager
| |
| * <code>systemd-cgls</code>: recursively shows the contents of the selected Linux control group hierarchy in a tree
| |
| * <code>systemadm</code>: a graphical frontend for the systemd system and service manager that allows introspection and control of systemd
| |
| | |
| View the man pages for more details.
| |
| | |
| = Boot Kernel Command Line =
| |
| On boot '''systemd''' activates (by default), the target unit ''default.target'' whose job is to activate services and other units by pulling them in via dependencies.
| |
| | |
| To override the unit to activate, '''systemd''' parses its own kernel command line arguments via the <code>systemd.unit=</code> command line option. This may be used to temporarily boot into a different boot unit. The classical run-levels are replaced as following:
| |
| | |
| <code>systemd.unit=rescue.target</code> is a special target unit for setting up the base system and a rescue shell (similar to run level 1); <code>systemd.unit=emergency.target</code>, is very similar to passing <code>init=/bin/sh</code> but with the option to boot the full system from there; <code>systemd.unit=multi-user.target</code> for setting up a non-graphical multi-user system; <code>systemd.unit=graphical.target</code> for setting up a graphical login screen.
| |
| | |
| For details about these special systemd boot units, view the man <code>systemd.special</code> page.
| |
| | |
| = References =
| |
| * [[Features/systemd | Features F15:systemd]]
| |
| * [http://www.freedesktop.org/wiki/Software/systemd Project homepage]
| |
| * [http://fosdem.org/2011/interview/lennart-poettering Interview with the developer]
| |
| * [http://www.kernel.org/doc/Documentation/cgroups/cgroups.txt cgroups]
| |
| | |
| | |
| = Developer =
| |
| Lennart Poettering (lpoetter@redhat.com)
| |
|
| |
|
| [[Category:Docs Project]] | | [[Category:Docs Project]] |
| [[Category:Draft documentation]] | | [[Category:Draft documentation]] |
| [[Category:Documentation beats]] | | [[Category:Documentation beats]] |
