Interest in systemd as a replacement for Sys V init is growing but it may not be appropriate for deeply embedded systems. I\'d like to investigate a crop of service based and process monitoring init systems and compare them on a variety of criteria as determined by the community. Furthermore I would like to investigate supporting multiple init systems, the current SysV system, systemd and possibly others. As part of this work, and because increasingly many upstreams support systemd (no doubt thanks to its adoption in Fedora) I would like to investigate implementing some infrastructure which translates from systemd units to the appropriate init format for the supported init systems.
We need to look into replacing sysvinit, or at the very least allowing users to easily replace sysvinit. This task will involve reviewing the new world order of init systems and figuring out what the cost/benefit ratio is. Key factors will include: * on disk size footprint * boot speed wins * sysvinit compatibility * kernel requirements * ease of adoption (debugging, switching from sysvinit compatibility) At the very least this task will produce documentation and configuration options to enable the use of alternatives to sysvinit.
What we decide with regards init will likely impact device management (bug 1608) and syslog (bug 717). Switch milestones of the mentioned bugs so that init is handled first and its impact will be known.
After discussion with various folks the design for 1.1 work on init is to enable the init daemon to be easily switched and provide recipes for alternative init systems (upstart and systemd, most likely). Deliverables will be: 1) Upstart recipe created and available, possibly in meta-oe with Systemd? - alternatively in OE-Core and work with Koen to move systemd to OE-Core? 2) Enable init system to be easily switched for core-image-* 3) Integrate a boot profiling tool into the system 4) Benchmark the init systems: - sysvinit - upstart + sysvinit scripts - systemd + sysvinit scripts - upstart + upstart events - systemd + systemd units 5) Write a paper/presentation/blog post/all of the above on our decisions and discoveries.
As we'll not be changing the default init in 1.2 the QA impact should be negligible.
bug #1608 has a "stop-gap" fix in alsa-state so this bug no longer blocks it
Is there a document/blog/wiki describing the work done so far?
There is not existing info beyond, this bug and people. Additionally, this should address re-packaging of scripts to split out existing sysvinit scripts into separate packages, since the systemd, and possibly other init systems will have packages.
just a short status update: I managed to get meta-openembedded/meta-systemd merged into oe-core and brought to a state where it builds fine for both core-image-minimal and core-image-sato. For the time being I changed my focus on core-image-minimal. At this point I am able to build sysvinit or systemd enabled images just by setting VIRTUAL-RUNTIME_init_manager accordingly Working to enable run-postinsts.service and change default init without graphical support (for core-image-minimal). My poky-contrib branch is rmoisan/systemd
I've changed default.target to multi-user.target It used to be graphical.target but I talked with Richard about this and we decided it would be best to start without graphical support (for embedded use) and then people will enable it as needed. Also received some review from Richard today so I started taking action on that. For now I just cleaned up the code a little and removed some old style programming.
I'm looking after mountall.service and a bunch of others failing which all source rcS-default script, and failing because it's missing (being provided by sysvinit). Initially I was considering packing separately all the scripts the sysvinit provides and placing a dependence on it in initscripts package. However, I'm not that sure that we need these scripts pulled in, so now I'm considering just patching all the scripts that source rcS-default not to source it anymore.
disabled rcS-default in all initscripts becase we don't need rcS-default's environment while running systemd. also switched from VIRTUAL-RUNTIME_init_manager to DISTRO_FEATURES_INITMAN as init scheme switch, as Richard suggested.
* rebased to master and remove a dependency on cairo (since appears to be broken) * removed gitpckgv.bbclass as Richard suggested * systemd-native failed becase of incomplete FILESPATH, fixed that.
* disabled sysfs.service because the operations in sysfs.sh are already handled by systemd * disabled acl support in systemd; I've seen that udev-acl in udev recipe si packed in a separate package and not loaded into traditional targets, so I assume it would be safe here to disable it(enabled it gives some warnings about Operation not permitted) since I don't have an option to package it separately. This options leaves room for future optimization, but for now I don't see a reason to leave it enabled. * I still have some warnings from systemd-tmpfiles complaining that it cannot create some files/dirs
Still fighting to understand why I get this failures from systemd-tmpfiles: systemd-udevd[58]: IMPORT{builtin}: 'uaccess' unknown /lib/udev/rules.d/73-seat-late.rules:15 systemd-tmpfiles[90]: Failed to create directory /var/cache/man: No such file or directory systemd-tmpfiles[90]: Failed to create file /var/run/utmp: No such file or directory /var/run/utmp for instance it exists. I'll look more into it tomorrow. THe failure from systemd-udev is because I disabled acl in systemd, I need to look over it again. I also built and booted sato, and appears to be fine. No other failures than above, although I'm a little intrigued it actually butted graphically since I have my default target set to multi-user instead of graphical. I'll look into this tomorrow as well.
* Investigated the problem with ACL support. As far as I can tell devtmpfs does not have support for ACL, and thus the warnings when systemd-udev is trying to access /dev/snd/seq, /dev/sequencer and /dev/snd/timer. I can't think of other solution for this but to disable those from their respective init scripts. A second opinion on this will be much appreciated. * Rebased my branch to master, and applied Martin's patch on initscripts * took a look over meta-openembedded and noticed a few new patches that need to be brought in. * Ross mentioned a failure on atom-pc, didn't get to look over yet.
Ignore my moans about it not working for now, that was probably due to meta-oe sneaking in and breaking it.
New commits: * xserver-nodm-init: add systemd support * util-linux: Enable systemd support * lighttpd: Enable systemd support Pulled in a few more patches from meta-openembedded. Current issues: * service 9oprofileui-server failing * dropbear.service - complains about not being able to write bropbear_rsa_host_key because it already exists * var-volatile.mount - complains about /var/volatile not empty when mounting
I dug a little after the 9oprofileui-server issue. I couldn't find anything wrong except it does not exist. We have however oprofileui-server file which is the script intended to run.Both /etc/init.d/oprofileui-server script and /usr/bin/oprofile-server binary exists.I don't understand where the "9" comes from. I'm leaving aside this issue for now, I'm moving in circles. Updated systemd to v196 and gave it a shoot but I'm facing a problem which might not have an easy fix. dbus-daemon is not started and thus dbus.socket is failing. Starting from this point several services depending on dbus activation are failing to. The problem arose in the past as a dependency problem among sysvinit services that systemd was trying to start. However, the issue I'm dealing with did not appear with previous version of systemd so I'm thinking this is not the same issue.
Ross submitted a pull request on the mailing list.
systemd changes merged into master
I could build a core-image-minimal, core-image-sato image with SystemD, install, boot, start/stop and enable/disable services. I am setting this feature to Verified.
Following Testopia test cases are created for this feature: https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=549 https://bugzilla.yoctoproject.org/tr_show_case.cgi?case_id=724