systemd improvements

Enable systemd support if systemd is selected as init system (require systemd compatibility libraries).

Signed-off-by Eric Le Bihan <[email protected]>

---
 package/dbus/Config.in |    1 +
 package/dbus/dbus.mk   |    9 +++++++--
 2 files changed, 8 insertions(+), 2 deletions(-)

package/dbus/Config.in +1 -0

index 653f748..7d49ce5 100644
@@ -4,6 +4,7 @@ config BR2_PACKAGE_DBUS
 	# uses fork()
 	depends on BR2_USE_MMU
 	select BR2_PACKAGE_EXPAT
+	select BR2_PACKAGE_SYSTEMD_COMPAT if BR2_INIT_SYSTEMD
 	help
 	  The D-Bus message bus system.
 

package/dbus/dbus.mk +0 -0

index 0c8fcf3..de699fc 100644

package/dbus/dbus.mk +3 -0

+DBUS_DEPENDENCIES += systemd
+else
+DBUS_CONF_OPT += --disable-systemd
 endif
 
 # fix rebuild (dbus makefile errors out if /var/lib/dbus is a symlink)

Revert getty fixup from post installation hook to service installation, because service installation is performed before the installation of the package itself. The fixup will fail trying to delete a file that has not been installed yet.

Fixes http://autobuild.buildroot.net/results/5b03174318d8a6dc3112053ff141b70a90869c20/

Signed-off-by Eric Le Bihan <[email protected]>

---
 package/systemd/systemd.mk |   12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

package/systemd/systemd.mk +6 -6

index 95e7214..97fa61a 100644
@@ -138,6 +138,11 @@ define SYSTEMD_INSTALL_INIT_HOOK
 	ln -fs ../../../lib/systemd/system/multi-user.target $(TARGET_DIR)/etc/systemd/system/default.target
 endef
 
+define SYSTEMD_INSTALL_TTY_HOOK
+	rm -f $(TARGET_DIR)/etc/systemd/system/getty.target.wants/getty at tty1.service
+	ln -fs ../../../../lib/systemd/system/serial-getty at .service $(TARGET_DIR)/etc/systemd/system/getty.target.wants/serial-getty@$(BR2_TARGET_GENERIC_GETTY_PORT).service
+endef
+
 define SYSTEMD_INSTALL_MACHINEID_HOOK
 	touch $(TARGET_DIR)/etc/machine-id
 endef

@@ -149,6 +154,7 @@ endef
 
 SYSTEMD_POST_INSTALL_TARGET_HOOKS += \
 	SYSTEMD_INSTALL_INIT_HOOK \
+	SYSTEMD_INSTALL_TTY_HOOK \
 	SYSTEMD_INSTALL_MACHINEID_HOOK \
 	SYSTEMD_SANITIZE_PATH_IN_UNITS
 

@@ -158,13 +164,7 @@ define SYSTEMD_USERS
 	$(SYSTEMD_USER_TIMESYNC)
 endef
 
-define SYSTEMD_INSTALL_SERVICE_TTY
-	rm -f $(TARGET_DIR)/etc/systemd/system/getty.target.wants/getty at tty1.service
-	ln -fs ../../../../lib/systemd/system/serial-getty at .service $(TARGET_DIR)/etc/systemd/system/getty.target.wants/serial-getty@$(BR2_TARGET_GENERIC_GETTY_PORT).service
-endef
-
 define SYSTEMD_INSTALL_INIT_SYSTEMD
-	$(SYSTEMD_INSTALL_SERVICE_TTY)
 	$(SYSTEMD_INSTALL_SERVICE_NETWORK)
 endef
 

Signature · 6 lines

1.7.10.4

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

Eric, All,

On 2014-07-03 18:57 +0200, Eric Le Bihan spake thusly:

Quoted 5 lines

Revert getty fixup from post installation hook to service installation, because service installation is performed before the installation of the package itself. The fixup will fail trying to delete a file that has not been installed yet.

Quoted 1 line

Fixes http://autobuild.buildroot.net/results/5b03174318d8a6dc3112053ff141b70a90869c20/

Another, nore generic fix has just been committed:

    http://git.buildroot.org/buildroot/commit/?id=ea0f52fc3fca5e5ba3ea5cd46033df2f53e9b5a5

Would you care verify if this proposed patch is still valid now?

Quoted 1 line

Would you care verify if this proposed patch is still valid now?

This generic fix solves my issue: I will remove this patch.

Dear Eric Le Bihan,

Quoted 3 lines · Eric Le Bihan

Quoted 1 line

Would you care verify if this proposed patch is still valid now?

This generic fix solves my issue: I will remove this patch.

Thanks. I've therefore marked http://patchwork.ozlabs.org/patch/366936/
as Rejected.

Could you take care of respining the other patches in your systemd series, i.e:

http://patchwork.ozlabs.org/patch/366938/ (good on the principle, but I think it doesn't apply properly on top of master, and there were minor comments from Arnout)

http://patchwork.ozlabs.org/patch/366939/ (some real concerns on this patch, maybe it should be last in the series, or reworked by a complete revamp of the skeleton strategy)

http://patchwork.ozlabs.org/patch/366940/ (looks good, with a suggestion from Arnout).

This patch bumps systemd to version 214.

Changes:

- add new users: systemd-bus-proxy, systemd-network and systemd-resolve.
- remove gtk-doc patch, as it is no longer needed.
- remove attr dependency.
- enable nss-myhostname.

Signed-off-by Eric Le Bihan <[email protected]>

Add a post installation hook to fix target runtime data directories /var/{lock,run,tmp} and /run. Theses directories will be populated by systemd according to the configuration files from /usr/lib/tmpfiles.d.

Signed-off-by Eric Le Bihan <[email protected]>

---
 package/systemd/systemd.mk |   13 +++++++++++++
 1 file changed, 13 insertions(+)

package/systemd/systemd.mk +13 -0

index 25bea0b..2da65e6 100644
@@ -149,11 +149,24 @@ define SYSTEMD_SANITIZE_PATH_IN_UNITS
 		-exec $(SED) 's,$(HOST_DIR),,g' {} \;
 endef
 
+# /var/{lock,run,tmp} and /run will be populated at runtime by Systemd
+# according to the configuration files from /usr/lib/tmpfiles.d/.
+define SYSTEMD_FIX_RUNTIME_DIRS_HOOK
+	$(RM) -rf $(TARGET_DIR)/var/lock
+	$(RM) -rf $(TARGET_DIR)/var/run
+	$(RM) -rf $(TARGET_DIR)/var/tmp
+	ln -sf ../run $(TARGET_DIR)/var/run
+	ln -sf ../run $(TARGET_DIR)/var/lock
+	$(RM) -rf $(TARGET_DIR)/run
+	mkdir -p $(TARGET_DIR)/run
+endef
+
 SYSTEMD_POST_INSTALL_TARGET_HOOKS += \
 	SYSTEMD_INSTALL_INIT_HOOK \
 	SYSTEMD_INSTALL_TTY_HOOK \
 	SYSTEMD_INSTALL_MACHINEID_HOOK \
 	SYSTEMD_INSTALL_RESOLVCONF_HOOK \
+	SYSTEMD_FIX_RUNTIME_DIRS_HOOK \
 	SYSTEMD_SANITIZE_PATH_IN_UNITS
 
 define SYSTEMD_USERS

Quoted 3 lines · Eric Le Bihan

Add a post installation hook to fix target runtime data directories /var/{lock,run,tmp} and /run. Theses directories will be populated by systemd according to the configuration files from /usr/lib/tmpfiles.d.

I don't understand why this is needed, or how this can work...

Currently, /run, /var/run, /var/lock, and /var/tmp are all symlinks to /tmp
where a tmpfs is mounted. I would expect that this is OK for systemd.

With this change, /run no longer links to /tmp, but it becomes a directory on
the rootfs. So unless systemd mounts a tmpfs on /run, this won't work at all. And on my Debian sid system which uses systemd, I see that /run is mounted in /init in the initramfs, so before systemd is started. We don't do that in buildroot, so how can this work?

Hi!

Quoted 7 lines · Arnout Vandecappelle

Quoted 3 lines · Eric Le Bihan

Add a post installation hook to fix target runtime data directories /var/{lock,run,tmp} and /run. Theses directories will be populated by systemd according to the configuration files from /usr/lib/tmpfiles.d.

I don't understand why this is needed, or how this can work...

Quoted 8 lines

Currently, /run, /var/run, /var/lock, and /var/tmp are all symlinks to /tmp
where a tmpfs is mounted. I would expect that this is OK for systemd.

With this change, /run no longer links to /tmp, but it becomes a directory on
the rootfs. So unless systemd mounts a tmpfs on /run, this won't work at all. And on my Debian sid system which uses systemd, I see that /run is mounted in /init in the initramfs, so before systemd is started. We don't do that in buildroot, so how can this work?

When started, systemd will mount /run as tmpfs. Search for mount_table in src/core/mount-setup.c in the source tree to see all the mount operations performed.

Once running, systemd will start the service systemd-tmpfiles [1], which is in charge of populating the volatile and temporary files and directories, according to configuration files [2] located in /usr/lib/tmpfiles.d/.

The link from /run to /var/run is mentioned in var.conf:

L /var/run - - - - ../run

/var/tmp is handled from tmp.conf:

d /tmp 1777 root root 10d
d /var/tmp 1777 root root 30d

/var/lock is handled from legacy.conf

L /var/lock - - - - ../run/lock

And I've just noticed etc.conf will handle the creation of the symlink for /etc/resolv.conf, so I can simplify my post installation hook :-)

L /etc/resolv.conf - - - - ../run/systemd/resolve/resolv.conf

We can see that for /var/run and /var/tmp, the types 'd' and 'L' are used, which means that if the directories/symlinks exist (created by the target skeleton), systemd-tmpfiles will not touch them. /var/run not being a symlink to /run made systemd-networkd not work properly on my system.

Best regards,
ELB

[1] http://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html
[2] http://www.freedesktop.org/software/systemd/man/tmpfiles.d.html

Quoted 18 lines · Eric Le Bihan

Hi!

Quoted 7 lines · Arnout Vandecappelle

Quoted 3 lines · Eric Le Bihan

Add a post installation hook to fix target runtime data directories /var/{lock,run,tmp} and /run. Theses directories will be populated by systemd according to the configuration files from /usr/lib/tmpfiles.d.

I don't understand why this is needed, or how this can work...

Quoted 8 lines

Currently, /run, /var/run, /var/lock, and /var/tmp are all symlinks to /tmp
where a tmpfs is mounted. I would expect that this is OK for systemd.

With this change, /run no longer links to /tmp, but it becomes a directory on
the rootfs. So unless systemd mounts a tmpfs on /run, this won't work at all. And on my Debian sid system which uses systemd, I see that /run is mounted in /init in the initramfs, so before systemd is started. We don't do that in buildroot, so how can this work?

Quoted 3 lines

When started, systemd will mount /run as tmpfs. Search for mount_table in src/core/mount-setup.c in the source tree to see all the mount operations performed.

It will not mount /run if it already is a mountpoint (after dereffing
symlinks). At least, that's what it looks like to me. So in our case, /run -> /tmp and tmp being a tmpfs, it should be OK the way it is now.

But indeed, making /run a real directory doesn't break anything, because
systemd will mount a tmpfs on it. However, do we really want two separate tmpfses, one for /run and a different one for /tmp?

Quoted 13 lines

Once running, systemd will start the service systemd-tmpfiles [1], which is in charge of populating the volatile and temporary files and directories, according to configuration files [2] located in /usr/lib/tmpfiles.d/.

The link from /run to /var/run is mentioned in var.conf:

L /var/run - - - - ../run

/var/tmp is handled from tmp.conf:

d /tmp 1777 root root 10d
d /var/tmp 1777 root root 30d

Quoted 8 lines

/var/lock is handled from legacy.conf

L /var/lock - - - - ../run/lock

And I've just noticed etc.conf will handle the creation of the symlink for /etc/resolv.conf, so I can simplify my post installation hook :-)

L /etc/resolv.conf - - - - ../run/systemd/resolve/resolv.conf

Er, no: /etc may be readonly, so systemd-tmpfiles can't create the symlink.

Quoted 5 lines

We can see that for /var/run and /var/tmp, the types 'd' and 'L' are used, which means that if the directories/symlinks exist (created by the target skeleton), systemd-tmpfiles will not touch them. /var/run not being a symlink to /run made systemd-networkd not work properly on my system.

OK, so the fact that /var/run is a symlink to /tmp and /run is also a symlink
to /tmp is not enough?

Conclusions:

- This patch does seem to work after all.

- I personally don't like how it messes with the skeleton.

- I don't really like having two tmpfses (one for /tmp and a different one for /run) either.

- Maybe it's better to make part of these changes in the default skeleton instead. E.g., changing the symlink of /var/run to point to /run instead of /tmp would be fine. Making /run a directory would not be OK, so if that is really necessary for systemd, then a fixup like this is needed.

Regards,
Arnout

Quoted 8 lines

Best regards,
ELB

[1] http://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html
[2] http://www.freedesktop.org/software/systemd/man/tmpfiles.d.html

--

Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot

If support for systemd-timesyncd is selected, install the associated service.

Signed-off-by Eric Le Bihan <[email protected]>

---
 package/systemd/systemd.mk |    6 ++++++
 1 file changed, 6 insertions(+)

package/systemd/systemd.mk +0 -0

index 2da65e6..3454e43 100644

package/systemd/systemd.mk +1 -0

 else
 SYSTEMD_CONF_OPT += --disable-timesyncd
 endif

@@ -180,6 +185,7 @@ endef
 
 define SYSTEMD_INSTALL_INIT_SYSTEMD
 	$(SYSTEMD_INSTALL_SERVICE_NETWORK)
+	$(SYSTEMD_INSTALL_SERVICE_TIMESYNC)
 endef
 
 $(eval $(autotools-package))

Quoted 4 lines · Eric Le Bihan

If support for systemd-timesyncd is selected, install the associated service.

Signed-off-by Eric Le Bihan <[email protected]>

Reviewed-by Arnout Vandecappelle (Essensium/Mind) <[email protected]>

Quoted 9 lines

---
 package/systemd/systemd.mk |    6 ++++++
 1 file changed, 6 insertions(+)

package/systemd/systemd.mk +0 -0

index 2da65e6..3454e43 100644

package/systemd/systemd.mk endif · line 119

Quoted 8 lines

package/systemd/systemd.mk +5 -0

@@ -112,6 +112,11 @@ endif
 
 ifeq ($(BR2_PACKAGE_SYSTEMD_TIMESYNCD),y)
 SYSTEMD_CONF_OPT += --enable-timesyncd
+define SYSTEMD_INSTALL_SERVICE_TIMESYNC
+	mkdir -p $(TARGET_DIR)/etc/systemd/system/sysinit.target.wants
+	ln -sf ../../../../lib/systemd/system/systemd-timesyncd.service \
+		$(TARGET_DIR)/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service
+endef

Not for this patch, but perhaps a cleaner way to do this would be to add

SYSTEMD_INSTALL_INIT_SYSTEMD += $(SYSTEMD_INSTALL_SERVICE_TIMESYNC)

instead having the list explicit below? Or wouldn't that work because there is no separator between networkd and timesync?

Quoted 28 lines · Arnout Vandecappelle

Quoted 4 lines · Eric Le Bihan

If support for systemd-timesyncd is selected, install the associated service.

Signed-off-by Eric Le Bihan <[email protected]>

Reviewed-by Arnout Vandecappelle (Essensium/Mind) <[email protected]>

Quoted 9 lines

---
 package/systemd/systemd.mk |    6 ++++++
 1 file changed, 6 insertions(+)

package/systemd/systemd.mk +0 -0

index 2da65e6..3454e43 100644

package/systemd/systemd.mk endif · line 119

Quoted 8 lines

package/systemd/systemd.mk +5 -0

@@ -112,6 +112,11 @@ endif
 
 ifeq ($(BR2_PACKAGE_SYSTEMD_TIMESYNCD),y)
 SYSTEMD_CONF_OPT += --enable-timesyncd
+define SYSTEMD_INSTALL_SERVICE_TIMESYNC
+	mkdir -p $(TARGET_DIR)/etc/systemd/system/sysinit.target.wants
+	ln -sf ../../../../lib/systemd/system/systemd-timesyncd.service \
+		$(TARGET_DIR)/etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service
+endef

Not for this patch, but perhaps a cleaner way to do this would be to add

Quoted 4 lines

SYSTEMD_INSTALL_INIT_SYSTEMD += $(SYSTEMD_INSTALL_SERVICE_TIMESYNC)

instead having the list explicit below? Or wouldn't that work because there is no separator between networkd and timesync?

Exactly! I tried the proposed solution and it does not work because of the missing separator.

In order to have such a way of installing systemd unit files, we should do the same as for the pre/post installation hooks.

The following change should be done in package/pkg-generic.mk:

   	$(if $(BR2_INIT_SYSTEMD),\
  -		$($(PKG)_INSTALL_INIT_SYSTEMD))
  +		$(foreach hook,$($(PKG)_INIT_SYSTEMD_HOOKS),$(call $(hook))$(sep)))

Then, we could use:

SYSTEMD_INIT_SYSTEMD_HOOKS += SYSTEMD_INSTALL_SERVICE_TIMESYNC

This would require updating all the Makefiles of the packages installing systemd unit files (and maybe do the same for SysV/Busybox to be coherent).

Eric Le Bihan (6):
dbus: enable systemd support

systemd: revert getty service installation

systemd: fix path for kmod in service files

systemd: bump to version 214

systemd: add hook to fix /run, /var

systemd: install timesync service if selected