* 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.

* 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.

There's a minimal UI, <code>systemadm</code> that allows to start/stop/introspect services. It is part of the systemd-gtk package It's a work in progress and is not functional yet, but useful as a debugging tool. It's written in Vala. Do not use it for now unless you are a developer}}

* 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.

* 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.

* <code>systemadm</code>: a graphical frontend for the systemd system and service manager that allows introspection and control of systemd. Part of the systemd-gtk page. This is a early version and needs more work. Do not use it for now unless you are a developer.

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.

Many of the core services (/lib/systemd/system has them and you can check status at http://fedoraproject.org/wiki/User:Johannbg/QA/Systemd/compatability) have been converted but not all of them yet. The transition is planned for Fedora 16. Details at http://fedoraproject.org/wiki/Features/SysVtoSystemd. systemd is fully compatible with the legacy init scripts

systemctl is the primary tool to use. It combines the functionality of both service and chkconfig into a single tool that you can use for instance to enable/disable services permanently or only for the current session.

Refer to man systemctl for more details. systemd-cgls lists the running process in a tree format. It can recursively show the content of any given control group. Refer to man systemd-cgls for more details.

Run level 3 is emulated by multi-user.target. Run level 5 is emulated by graphical.target. runlevel3.target is a symbolic link to multi-user.target and runlevel5.target is a symbolic link to graphical.target.

runlevel command still works with systemd. You can continue using that however runlevels is a legacy concept in systemd and is emulated via 'targets' and multiple targets can be active at the same time. So the equivalent in systemd terms is

Note that <code>halt</code> used to work the same as <code>poweroff</code> in previous Fedora releases, but systemd distinguishes between the two, so <code>halt</code> without parameters now does exactly what it says - it merely stops the system without turning it off.

Yes, for turning on/off services, compatibility has been provided both ways. chkconfig has been modified to call systemctl when dealing with systemd service files. Also systemctl automatically calls chkconfig when dealing with a traditional sysv init file.

Note that if you exit tty8 session, you wont be able to use it until next reboot or manual start by systemctl, except if you leave Restart as ‘always’, but I highly recommend to avoid this according to security reasons.

If a line starts with <code>.include</code> followed by a file name, the specified file will be parsed at this point. Make sure that the file that is included has the appropiate section headers before any directives.

You should use <code>.include</code> statement instead of copying the whole unit file from /lib/systemd/system to /etc/systemd/system if possible. This will enable to update the unchanged directives correctly during future package updates.

Be careful when using <code>.include</code> together with directives that can be defined multiple times (like <code>EnvironmentFile=</code>), since we can only add new directives, but we can't remove already defined ones. We have to copy the whole file from /lib/systemd/system to /etc/systemd/system in this case.

Let's say we use a lighttpd server and we want to lower its niceness value. All we need to do is to add <code>Nice=-5</code> to the lighttpd.service file. We can do this by either copying the whole file from /lib/systemd/system/lighttpd.service to /etc/systemd/system/lighttpd.service or creating the following file in /etc/systemd/system/lighttpd.service:

{{admon/note|When modifying an unit that has an symlink pointing to that unit for example like the display-manager.service -> prefdm.service does, the symlink should be copied instead of the actual unit as in display-manager.service should be copied to the /etc/systemd/system directory or a new unit created with .includes that bears that name .}}