[RFC] systemd units packaging

* [RFC] systemd units packaging
@ 2011-05-06 13:39 Koen Kooi
  2011-05-06 13:51 ` Chris Larson
                   ` (2 more replies)
  0 siblings, 3 replies; 12+ messages in thread
From: Koen Kooi @ 2011-05-06 13:39 UTC (permalink / raw)
  To: Patches and discussions about the oe-core layer

Hi,

The past few days I have gotten systemd to work in OE.dev and I have some questions on how to do in the oe-core universe. First some background:

Systemd is a /sbin/init replacement using ideas from apples launchd like socket activation. Startup scripts are replaced by .ini like files:

sshd.socket:
------------------------------------------
[Unit]
Description=OpenSSH Server Socket.
Conflicts=sshd.service

[Socket]
ListenStream=22
Accept=yes

[Install]
WantedBy=sockets.target
------------------------------------------

sshd@.service
------------------------------------------
[Unit]
Description=OpenSSH per connection server daemon.
After=syslog.target 

[Service]
ExecStartPre=/usr/sbin/sshd -t
ExecStart=-/usr/sbin/sshd -i
StandardInput=socket
------------------------------------------

The above 2 units combined will start openssh as soon as port 22 is being accessed. This is comparable with inetd. For sysV style init you can use something like this:

sshd.service:
------------------------------------------
[Unit]
Description=OpenSSH server daemon.
After=syslog.target network.target

[Service]
Type=forking
PIDFile=/var/run/sshd.pid
EnvironmentFile=/etc/sysconfig/sshd
ExecStartPre=/usr/sbin/sshd -t
ExecStart=/usr/sbin/sshd $OPTIONS

[Install]
WantedBy=multi-user.target
------------------------------------------

All those files are placed in /lib/systemd/system. You can make those exec the old sysv scripts if you wish.

Now onto my issues:

packaging:
	In OE .dev I added FILES_${PN} += "${base_libdir}/systemd" to udev, dbus, rsyslog and avahi. This means we end up with both sysV script and systemd units. What I would like to have is ${PN}-sysvinit and ${PN}-systemd and the image recipe can choose which init systems gets used. Is something like that possible? Are there better ways? Note that systemd support sysV initscripts as well, but it needs some care with naming. As I understand it, if a unit is found with the same name as a sysV script, only the unit will get used.
A rootfs postprocess command that deletes /etc/init.d won't work, since it will come back when upgrading the packages.

building:
	At the moment systemd enabled software installs the units regardless or config options. What should be do with software that has an option for that? And what if we need to patch the units files in? The initsystem is a choice at the image level, so artificially limiting it to a distro choice is not a good idea.

sharing:
	The Arch people have a github with their custom units: https://github.com/falconindy/systemd-arch-units/ Do we use those? Do we use fedora ones https://bugzilla.redhat.com/show_bug.cgi?id=697698 ? People on #systemd are talking about a shared repo on fd.o, but nothing tangible yet.

And related to this: how do I get the "installed but not packaged" output back? The bitbake logging changes are hiding it now, which is counterproductive. 

So, what are your thoughts on all this?

regards,

Koen

^ permalink raw reply	[flat|nested] 12+ messages in thread