Embedded with systemd
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?
Reply to: