[Buildroot] [PATCH] package/skeleton-init-systemd: create a symlink /var/run to ../run

[Buildroot] [PATCH] package/skeleton-init-systemd: create a symlink /var/run to ../run

[Romain Naour]

As reported by J?r?my Rosen [1] and Jan Kundr?t (RO case)[2], systemd
looks for the dbus socket in /run/dbus instead of /var/run/dbus which
is not where dbus puts the socket. This is a change introduced with
the last version bump v237 [3].

The file /usr/lib/tmpfiles.d/var.con will create automatically that
symlink at bootup /var/run doesn't exist yet. But dbus creates, at
install time, the directory /var/run/dbus without taking care of
/var/run. So we end up with two different directories /run and
/var/run. This bug affects more or less all systemd-provided
utilities, including logind and systemd itself.

This patch create the correct symlink run -> ../run when systemd
is used as init system.

[1] http://lists.busybox.net/pipermail/buildroot/2018-February/214129.html
[2] http://lists.busybox.net/pipermail/buildroot/2018-February/213420.html
[3] https://github.com/systemd/systemd/commit/15ca0a42c7db49146a7169dbcb0683f0836cf8c2

Reported-by: J?r?my Rosen <jeremy.rosen@smile.fr>
Signed-off-by: Romain Naour <romain.naour@gmail.com>
---
 package/skeleton-init-systemd/skeleton-init-systemd.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/package/skeleton-init-systemd/skeleton-init-systemd.mk b/package/skeleton-init-systemd/skeleton-init-systemd.mk
index 95142904f5..d435aa54ee 100644
--- a/package/skeleton-init-systemd/skeleton-init-systemd.mk
+++ b/package/skeleton-init-systemd/skeleton-init-systemd.mk
@@ -20,6 +20,7 @@ ifeq ($(BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW),y)
 define SKELETON_INIT_SYSTEMD_ROOT_RO_OR_RW
 	echo "/dev/root / auto rw 0 1" >$(TARGET_DIR)/etc/fstab
 	mkdir -p $(TARGET_DIR)/var
+	ln -s ../run $(TARGET_DIR)/var/run
 endef
 
 else
-- 
2.14.3

[Buildroot] [PATCH] package/skeleton-init-systemd: create a symlink /var/run to ../run

[Trent Piepho]

On Thu, 2018-02-22 at 23:10 +0100, Romain Naour wrote:
> As reported by J?r?my Rosen [1] and Jan Kundr?t (RO case)[2], systemd
> looks for the dbus socket in /run/dbus instead of /var/run/dbus which
> is not where dbus puts the socket. This is a change introduced with
> the last version bump v237 [3].
> 
> The file /usr/lib/tmpfiles.d/var.con will create automatically that
> symlink at bootup /var/run doesn't exist yet. But dbus creates, at
> install time, the directory /var/run/dbus without taking care of
> /var/run. So we end up with two different directories /run and
> /var/run. This bug affects more or less all systemd-provided
> utilities, including logind and systemd itself.
> 
> This patch create the correct symlink run -> ../run when systemd
> is used as init system.

This doesn't work in the RO root case.  I described this in another
mail to the list, but in the RO root case target/var is a symlink to
target/usr/share/factory/var.  Thus this link is actually created as:

target/usr/share/factory/var/run -> ../run

It points to target/usr/share/factory/run, which is wrong.  In order to
get it to work in the RO case, instead create this link.

define SKELETON_INIT_SYSTEMD_VAR_RUN_LINK
       ln -sf ../../../../run $(TARGET_DIR)/usr/share/factory/var/run
endef
 
SKELETON_INIT_SYSTEMD_POST_INSTALL_TARGET_HOOKS += \
       SKELETON_INIT_SYSTEMD_VAR_RUN_LINK

Then you get a target that looks like this:
                                                                 
lrwxrwxrwx    1 root     root  29 Feb 23 02:35 /var/run -> ../usr/share/factory//var/run
lrwxrwxrwx    1 root     root  15 Feb 23 00:51 /usr/share/factory/var/run -> ../../../../run

On the target, /var/run ends up pointing to /run and also on the host
$TARGET_DIR/var/run points to $TARGET_DIR/run.

[Buildroot] [PATCH] package/skeleton-init-systemd: create a symlink /var/run to ../run

[Arnout Vandecappelle]

On 23-02-18 19:25, Trent Piepho wrote:
> On Thu, 2018-02-22 at 23:10 +0100, Romain Naour wrote:
>> As reported by J?r?my Rosen [1] and Jan Kundr?t (RO case)[2], systemd
>> looks for the dbus socket in /run/dbus instead of /var/run/dbus which
>> is not where dbus puts the socket. This is a change introduced with
>> the last version bump v237 [3].
>>
>> The file /usr/lib/tmpfiles.d/var.con will create automatically that
>> symlink at bootup /var/run doesn't exist yet. But dbus creates, at
>> install time, the directory /var/run/dbus without taking care of
>> /var/run. So we end up with two different directories /run and
>> /var/run. This bug affects more or less all systemd-provided
>> utilities, including logind and systemd itself.
>>
>> This patch create the correct symlink run -> ../run when systemd
>> is used as init system.
> 
> This doesn't work in the RO root case.  I described this in another
> mail to the list, but in the RO root case target/var is a symlink to
> target/usr/share/factory/var.  Thus this link is actually created as:
> 
> target/usr/share/factory/var/run -> ../run
> 
> It points to target/usr/share/factory/run, which is wrong.

 Well, as such it is not wrong. What is wrong IMO is that we do:

        for i in $(TARGET_DIR)/usr/share/factory/var/*; do \
                j="$${i#$(TARGET_DIR)/usr/share/factory}"; \
                if [ -L "$${i}" ]; then \
                        printf "L+! %s - - - - %s\n" \
                                "$${j}" "../usr/share/factory/$${j}" \
                        || exit 1; \
                else \
...

 The correct thing to do would be to copy the symlink I think, so something like:

                if [ -L "$${i}" ]; then \
			target=`readlink $${i}`
                        printf "L+! %s - - - - %s\n" \
                                "$${j}" "$${target}" \
                        || exit 1; \


 However, I believe our var-factory.conf is even more wrong. systemd already
supplies /usr/lib/tmpfiles.d/var.conf for exactly this purpose. That one already
has the stanza to create the correct /var/run symlink. That var.conf is not
complete though. For example, mysql expects /var/lib/mysql to exist while
var.conf just creates /var/lib. So we do indeed need something like
var-factory.conf, but I think that it should take into account anything that is
already created by other tmpfiles configurations. So it should search each
file/directory that it finds in /usr/share/factory/var in all of the existing
tmpfiles.d entries, and if it is found there and it is not a C entry, it should
recurse.

 Well, that's my feeling, but I'm not a systemd expert :-)

 Regards,
 Arnout

>  In order to
> get it to work in the RO case, instead create this link.
> 
> define SKELETON_INIT_SYSTEMD_VAR_RUN_LINK
>        ln -sf ../../../../run $(TARGET_DIR)/usr/share/factory/var/run
> endef
>  
> SKELETON_INIT_SYSTEMD_POST_INSTALL_TARGET_HOOKS += \
>        SKELETON_INIT_SYSTEMD_VAR_RUN_LINK
> 
> Then you get a target that looks like this:
>                                                                  
> lrwxrwxrwx    1 root     root  29 Feb 23 02:35 /var/run -> ../usr/share/factory//var/run
> lrwxrwxrwx    1 root     root  15 Feb 23 00:51 /usr/share/factory/var/run -> ../../../../run
> 
> On the target, /var/run ends up pointing to /run and also on the host
> $TARGET_DIR/var/run points to $TARGET_DIR/run.
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
> 

-- 
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:  7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF

[Buildroot] [PATCH] package/skeleton-init-systemd: create a symlink /var/run to ../run

[Trent Piepho]

On Sat, 2018-02-24 at 19:15 +0100, Arnout Vandecappelle wrote:
> 
> > target/usr/share/factory/var/run -> ../run
> > 
> > It points to target/usr/share/factory/run, which is wrong.
> 
>  Well, as such it is not wrong. What is wrong IMO is that we do:
> 
>         for i in $(TARGET_DIR)/usr/share/factory/var/*; do \
>                 j="$${i#$(TARGET_DIR)/usr/share/factory}"; \
>                 if [ -L "$${i}" ]; then \
>                         printf "L+! %s - - - - %s\n" \
>                                 "$${j}" "../usr/share/factory/$${j}" \
>                         || exit 1; \
>                 else \
> ...
> 
>  The correct thing to do would be to copy the symlink I think, so something like:
> 
>                 if [ -L "$${i}" ]; then \
> 			target=`readlink $${i}`
>                         printf "L+! %s - - - - %s\n" \
>                                 "$${j}" "$${target}" \
>                         || exit 1; \

But that ends up with another problem.  While the var-factory.conf file
will be ok:
/var/run - - - - ../run

The target tree in the build area is not ok:

$ mkdir -p target/var/run/nginx
mkdir: cannot create directory ?target/var/run?: File exists

The problem is like I said, ${TARGET_DIR}/var is a symlink to
${TARGET_DIR}/usr/share/factory/var.  This means the link
${TARGET_DIR}/var/run -> ../run actually points to
${TARGET_DIR}/usr/share/factory/run, which does not exist.

So while you do get a valid /var on the target when tmpfiles is
creating things, the tree in the build area is broken and any package
that tries to create things in ${TARGET_DIR}/var/run (like nginx) will
break at target install time.

The double symlink that the current tmpfile code in buildroot makes
actually works.  I suspect that's why it was written that way to begin
with.

When building, you get:
${TARGET_DIR}/var -> ../usr/share/factory/var
${TARGET_DIR)/usr/share/factory/var/run -> ../../../../run
Producing, as desired:
${TARGET_DIR)/var/run -> ${TARGET_DIR}/run

Then on the target after tmpfiles has created the links:
/var is a directory
/var/run -> ../usr/share/factory/var/run
/usr/share/factory/var/run -> ../../../../run
Producing, again as desired:
/var/run -> /run

It would be simpler to just use explicit tmpfiles entries to make
everything, but one needs a valid target tree when building too.  Thus
the process of creating tmpfiles entries from the target tree.

>  However, I believe our var-factory.conf is even more wrong. systemd already
> supplies /usr/lib/tmpfiles.d/var.conf for exactly this purpose. That one already
> has the stanza to create the correct /var/run symlink. That var.conf is not
> complete though. For example, mysql expects /var/lib/mysql to exist while
> var.conf just creates /var/lib. So we do indeed need something like
> var-factory.conf, but I think that it should take into account anything that is
> already created by other tmpfiles configurations. So it should search each
> file/directory that it finds in /usr/share/factory/var in all of the existing
> tmpfiles.d entries, and if it is found there and it is not a C entry, it should
> recurse.

If buildroot were to create /etc/tmpfile.d/var.conf, instead of var-
factory.conf, it would override the systemd supplied var.conf rather
than augmenting it.

This is what I do to make RO rootfs work.  In my overlay, I have an my
own var.conf file in /etc to override the systemd one.  Mine does not
have the /var/run symlink, since buildroot will produces this.

A useful RO root likely also needs a persistent writable partition, for
 instance to store logs.  So I also have lines to make /var/log
persistent in the replacement for the systemd var.conf file.

[Buildroot] [PATCH] package/skeleton-init-systemd: create a symlink /var/run to ../run

[Romain Naour]

Hi Trent,

Le 23/02/2018 ? 19:25, Trent Piepho a ?crit?:
> On Thu, 2018-02-22 at 23:10 +0100, Romain Naour wrote:
>> As reported by J?r?my Rosen [1] and Jan Kundr?t (RO case)[2], systemd
>> looks for the dbus socket in /run/dbus instead of /var/run/dbus which
>> is not where dbus puts the socket. This is a change introduced with
>> the last version bump v237 [3].
>>
>> The file /usr/lib/tmpfiles.d/var.con will create automatically that
>> symlink at bootup /var/run doesn't exist yet. But dbus creates, at
>> install time, the directory /var/run/dbus without taking care of
>> /var/run. So we end up with two different directories /run and
>> /var/run. This bug affects more or less all systemd-provided
>> utilities, including logind and systemd itself.
>>
>> This patch create the correct symlink run -> ../run when systemd
>> is used as init system.
> 
> This doesn't work in the RO root case.

Indeed, but I'm testing/fixing the RW case with this patch
(BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW).

> I described this in another
> mail to the list, but in the RO root case target/var is a symlink to
> target/usr/share/factory/var.  Thus this link is actually created as:
> 
> target/usr/share/factory/var/run -> ../run

The symlink is only created when BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW is set.
The RO behavior is left unchanged.

> 
> It points to target/usr/share/factory/run, which is wrong.  In order to
> get it to work in the RO case, instead create this link.
> 
> define SKELETON_INIT_SYSTEMD_VAR_RUN_LINK
>        ln -sf ../../../../run $(TARGET_DIR)/usr/share/factory/var/run
> endef
>  
> SKELETON_INIT_SYSTEMD_POST_INSTALL_TARGET_HOOKS += \
>        SKELETON_INIT_SYSTEMD_VAR_RUN_LINK
> 
> Then you get a target that looks like this:
>                                                                  
> lrwxrwxrwx    1 root     root  29 Feb 23 02:35 /var/run -> ../usr/share/factory//var/run
> lrwxrwxrwx    1 root     root  15 Feb 23 00:51 /usr/share/factory/var/run -> ../../../../run
> 
> On the target, /var/run ends up pointing to /run and also on the host
> $TARGET_DIR/var/run points to $TARGET_DIR/run.
> 

The RO case can be fixed in a follow up patch or you can rework this patch with
your modifications. Maybe Adam can help here.

Adam, you bumped systemd to v237 can you have a look ?

Best regards,
Romain

[Buildroot] [PATCH] package/skeleton-init-systemd: create a symlink /var/run to ../run

[Trent Piepho]

On Sun, 2018-02-25 at 20:16 +0100, Romain Naour wrote:
> The file /usr/lib/tmpfiles.d/var.con will create automatically that
> > > symlink at bootup /var/run doesn't exist yet. But dbus creates, at
> > > install time, the directory /var/run/dbus without taking care of
> > > /var/run. So we end up with two different directories /run and
> > > /var/run. This bug affects more or less all systemd-provided
> > > utilities, including logind and systemd itself.
> > > 
> > > This patch create the correct symlink run -> ../run when systemd
> > > is used as init system.
> > 
> > This doesn't work in the RO root case.
> 
> Indeed, but I'm testing/fixing the RW case with this patch
> (BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW).

I should have said that differently.  RO root has the same problem, but
this link will not solve it.

I believe the link:
ln -sf ../../../../run $(TARGET_DIR)/usr/share/factory/var/run

will fix the RO case.  But of course does not work in the RW case.

I can send a follow on patch to add this link for RO.

But I wish there was some other method that could solve the problem for
both RW and RO, without needing to add special cases like this link.

[Buildroot] [PATCH] package/skeleton-init-systemd: create a symlink /var/run to ../run

[Pierre]

On Tuesday, February 27, 2018 7:37:54 PM CET Trent Piepho wrote:
> On Sun, 2018-02-25 at 20:16 +0100, Romain Naour wrote:
> > The file /usr/lib/tmpfiles.d/var.con will create automatically that
> > 
> > > > symlink at bootup /var/run doesn't exist yet. But dbus creates, at
> > > > install time, the directory /var/run/dbus without taking care of
> > > > /var/run. So we end up with two different directories /run and
> > > > /var/run. This bug affects more or less all systemd-provided
> > > > utilities, including logind and systemd itself.
> > > > 
> > > > This patch create the correct symlink run -> ../run when systemd
> > > > is used as init system.
> > > 
> > > This doesn't work in the RO root case.
> > 
> > Indeed, but I'm testing/fixing the RW case with this patch
> > (BR2_TARGET_GENERIC_REMOUNT_ROOTFS_RW).
> 
> I should have said that differently.  RO root has the same problem, but
> this link will not solve it.
> 
> I believe the link:
> ln -sf ../../../../run $(TARGET_DIR)/usr/share/factory/var/run
> 
> will fix the RO case.  But of course does not work in the RW case.
> 
> I can send a follow on patch to add this link for RO.
> 
> But I wish there was some other method that could solve the problem for
> both RW and RO, without needing to add special cases like this link.

I'm new to buildroot but got hit by that bug and after reading this thread I 
don't really understand why this would not work with RW.
It's quite dirty, but a link to ../../../{repeat?}/run will end up linking to 
/run since /.. is a link to /
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20180227/9df6d8ba/attachment.asc>