Hi This is my first post to a debian-* list even though I have been a (happy) user for many years, both on the desktop and on embedded devices. I am currently looking at the implications that running systemd on some of our products will have, and while many things seem like they will get simpler, other things seem harder, much harder.
I am posting this to try and learn from other users who have similar use cases. I am breaking this into a few different topics/questions to keep the conversation a bit more focused. I am the first to admit that I don't have much experience with systemd and I have only installed a VM with it recently, so if I missed the easy answer in any of the topics, I will take no offence at being told to RTFM. I am cross-posting to debian-user since I expect that there will be more experienced systemd users there. Thanks for your thoughts, Robert I originally had these as separate emails, but the listmaster has requested that I combine them --- they are included below ----------------------------------------------- Embedded with systemd: systemd and SIL By choosing packages carefully, it is possible to use linux in applications that need to meet SIL1 or SIL2 criteria [1]. I personally don't have any applications that need to meet SIL2, but it is possible to meet SIL1 by taking a normal installation and removing a bunch of stuff (initramfs, udev and inetd amongst others) until the system is deterministic enough (see the methodology in [2]). /sbin/init functions OK with a few static devices in/dev Given the tight udev/systemd marriage and the undeterministic nature of socket activation, I suspect that systemd will never be suitable for SIL applications. Are there any other debian embedded developers that need to meet SIL criteria? How are you planning to manage the fact that there are very few non-systemd distros left, or do we have to resign ourselves to a life of OpenEmbedded and buildroot? [1] http://www.reliableembeddedsystems.com/pdfs/2010_03_04_rt_linux.pdf [2] http://www.hse.gov.uk/research/rrpdf/rr011.pdf -------------------------------------------------- Embedded with systemd: systemd and different modes I have a use case where I have a logging unit with a few buttons that are available to the user. The buttons are read via the kernel GPIO methods. There is no display, no keyboard, only 802.11. Normally the unit starts a few daemons and starts the 802.11 in client (wpa_supplicant) mode. To help with field debugging I currently check the state of one of the buttons at startup and if it is pressed, the unit starts the 802.11 in host (hostapd) mode and starts sshd. This was trivial to configure with /sbin/init calling a shellscript that checks the GPIO and then chooses between two different runlevels. The runlevels are setup by making a few symlinks in rcx.d. Since it is not possible to make decisions in systemd unit files, this has become much harder. I have a solution for this, but it is smelly. How would you solve this? This is quite a common use case (at least in the world I live in), and I will post my solution later but I don't want to poison anybodies thinking right now. b.t.w I asked this question in #systemd a few nights ago and was told my use case was "bizarre" -------------------------------------------------- Embedded with systemd: systemd and weird triggers Sometimes you only want services to start based on a "weird" trigger. I have one use case where I only want a service to start once we have received a valid GPS lock. With /sbin/init it looked like this: #!/bin/bash while [ <some bash that figures out if we have a lock> ]; do sleep 5; #wait for lock done; service & with systemd I have to have waitforgps.sh waitforgps.service (Exec=waitforgps.sh) service.service (After=waitforgps.service) Is this really the best way? -------------------------------------------------- Embedded with systemd: systemd and kernel upgrades This was recently posted on #systemd-devel: "To make this clear, we expect that systemd and kernels are updated in lockstep. We explicitly do not support really old kernels with really new systemd. So far we had the focus to support up to 2y old kernels (which means 3.4 right now), but even that should be taken with a grain of salt, as we already made clear that soon after kdbus is merged into the kernel we'll probably make a hard requirement on it from the systemd side." This is a very onerous requirement in the embedded world. There are many embedded platforms sold today that only have 2.6.X BSPs. While I agree that the BSP from vendors should be better (and it is getting better thanks to devicetree), it seems that we are doomed to run ancient userspace to match our ancient kernels. This change will probably hit me the hardest and for me it really cuts into what linux means. It used to be that I could run the same userspace on my tiny embedded device, my desktop or on the server --- the only difference being the kernel. It seems like the only solution here is to abandon debian and fall back to OpenEmbedded or buildroot. -------------------------------------------------- Embedded with systemd: systemd and realtime Given the existence of (http://www.freedesktop.org/wiki/Software/systemd/MyServiceCantGetRealtime/), it seems that realtime and systemd is problematic. Has anyone tried the workarounds mentioned with a PREEMPT_RT kernel? How did it go? -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
