Archive:Systemd status
List of open items for systemd integration
- 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 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).
- apparmor
- cycle
- ipconfig
- nfs
- ntp
- xdm
List of issues and open bugs regarding systemd integration in openSUSE
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.
Recipes
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
https://fedoraproject.org/wiki/Packaging:Guidelines:Systemd
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
Packaging
- 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.