The wikis are now using the new authentication system.
If you did not migrate your account yet, visit

openSUSE:Systemd status

Ga naar: navigatie, zoeken
Systemd is een nieuw "init system" (initialisatiesysteem) dat wordt geschreven door Lennart, Kay en vele anderen. Als u wilt helpen systemd te integreren in openSUSE, lees dan deze pagina.

Lijst met open items voor integratie van systemd

Dit artikel is nog maar gedeeltelijk vertaald. Als u mee wilt helpen met vertalen lees dan Wiki vertalen naar het Nederlands.
  • We should have all services of a default installation handled with native systemd services.
  • SUSE's LSB extension $ALL is not supported. Need to find a solution for assumptions, which are no longer true, the firewall makes.
  • The YaST2 runlevel editor needs to be modified for systemd. The API of the runlevel editor is used by other YaST modules to enable/disable/query services.
  • system wide ulimits (/etc/sysconfig/ulimit, /etc/initscript)?
  • switch SUSE-specific config files to new cross-distro configs: /etc/os-release, /etc/locale, /etc/tmpfiles.d/, /etc/vconsole.conf, /etc/modules-load.d/
  • Fix bugs that are found (see below)

List of enabled services

Currently factory has the following systemd enabled services:

  • acpid
  • alsa (alsa-utils)
  • avahi
  • cron (cronie)
  • dbus (dbus-1)
  • udev
  • NetworkManager

(This is outdated and incomplete see /lib/systemd/system/ directory for the complete list in an openSUSE Factory installation)

List of services to enable

The following is a list of services of a default installation that are not yet handled natively by systemd (note this was on AJ's system, not everything might be in the default).

Fedora status:

  • apparmor
  • autofs
  • bluez-coldplug
  • cycle
  • fbset (Obsoleted by KMS)
  • haldaemon (deprecated)
  • ipconfig
  • kbd (replaced by vconsole.conf)
  • klog
  • loadmodules (replaced by modules-load.d/)
  • network-remotefs
  • nfs
  • ntp
  • proc
  • splash
  • splash_early
  • SuSEfirewall2
  • syslog
  • xdm
  • ypbind

List of issues and open bugs regarding systemd integration in openSUSE

Please help fixing these bugs: systemd bug in 12.1 systemd bug in 12.2

Please file general feature requests, or non-SUSE specific bugs in the systemd upstream bugzilla.

If filing openSUSE bugs, mark them as blocker of bnc#696902 - systemd as default boot handler bug report.


Creation of a service file

See Lennarts' systemd for admins, part 3 on how to create a service file.

Fedora has already a number of systemd files that we can just copy. So, before creating one, check Fedora and also Lennart's unit files.

Enabling services

Short list of differences with integration of systemd compared to SysVinit

Remember that one goal of systemd is collaboration between distributions so that we can share more than we do right now across distributions. Therefore some of the changes below are done to unify systems:

  • /var/run + /var/lock + /media are unconditionally mounted as tmpfs now
  • temporary files are created via /etc/tmpfiles.d thus obsoleting /etc/tmpdirs.d

(this clearly doesn't right, please correct).

  • agetty is used instead of mingetty
  • systemd does not support /etc/mtab being a regular file, and requires it to be symlink to /proc/self/mounts. systemd package creates the link. untrusted 'user' unmount is not supported by the kernel's mounts file, util-linux 2.19+ is required for support of a private mtab (available since openSUSE 11.4).
  • serial console setup using agetty is built into systemd and does not require any configuration
  • /etc/init.d/boot.d support will probably disappear in some future systemd release. It would be best to provide alternative unit files for those files.
  • systemd really respects noauto in /etc/fstab, even for crypted partitions (/home for instance). Either remove noauto or add "comment=systemd.automount" to have automount working

Open Questions that should be documented


  • My package has a sysconfig file which only takes a variable to modify

the daemon options. Can I use that for systemd as well? How to do that?

  • The daemon is currently started by default when installed. What happens

after the update to the new version which includes systemd files? Will it be enabled by default? (I've actually tried the update and the service was running afterwards so I guess it will be enabled in update case but not for a fresh installation?)

  • For the service it makes a lot of sense to use systemd's socket

activation feature. So what do I need to do exactly to have the service disabled but have the socket enabled to start the service automatically (in terms of system configuration)? Is the only way to have services/sockets enabled by default to modify some certain systemd package and not from within a package installation? This sounds strange and rather unfortunate so it's for example not possible to install/update a package which then starts a service by default w/o updating an official central distribution package?

  • When rolling back a systemd enabled service to a sysvinit based version some state in systemd is not updated apparently and therefore trying to use the sysvinit script fails as well. (That's probably more a bug than a documentation thing)

Using systemd

Conversion guide for users and third parties

Not an open question as such, but how about a direct comparison of user-related features and functionality? For example, with sysVinit, one could specify "init S" or "init 3" on the bootloader command line, how is that achieved with systemd? Second, for third party developers of scripts, a similar one-to-one comparison of init-script vs. service file features would be very useful.