[Buildroot] [PATCH] system/skeleton: make /var/run a symlink to /run

[Buildroot] [PATCH] system/skeleton: make /var/run a symlink to /run

[Norbert Lange]

both systemd and FHS3 denote /var/run as a compatibility directory,
new systems should use /run.

There seems to be little reason to not switch to the new FHS layout
with buildroot, and adding the compatibility symlink.

[1] - https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s13.html

Signed-off-by: Norbert Lange <nolange79@gmail.com>
---
 package/skeleton-init-systemd/skeleton-init-systemd.mk | 2 --
 system/skeleton/var/run                                | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)
 create mode 120000 system/skeleton/var/run

diff --git a/package/skeleton-init-systemd/skeleton-init-systemd.mk b/package/skeleton-init-systemd/skeleton-init-systemd.mk
index 5d6b716f7a..528cf43e61 100644
--- a/package/skeleton-init-systemd/skeleton-init-systemd.mk
+++ b/package/skeleton-init-systemd/skeleton-init-systemd.mk
@@ -60,8 +60,6 @@ endif
 define SKELETON_INIT_SYSTEMD_INSTALL_TARGET_CMDS
 	mkdir -p $(TARGET_DIR)/home
 	mkdir -p $(TARGET_DIR)/srv
-	mkdir -p $(TARGET_DIR)/var
-	ln -s ../run $(TARGET_DIR)/var/run
 	$(SKELETON_INIT_SYSTEMD_ROOT_RO_OR_RW)
 endef
 
diff --git a/system/skeleton/var/run b/system/skeleton/var/run
new file mode 120000
index 0000000000..84ba55b912
--- /dev/null
+++ b/system/skeleton/var/run
@@ -0,0 +1 @@
+../run
\ No newline at end of file
-- 
2.27.0

[Buildroot] [PATCH] system/skeleton: make /var/run a symlink to /run

[Norbert Lange]

Am Mo., 29. Juni 2020 um 12:47 Uhr schrieb Norbert Lange <nolange79@gmail.com>:
>
> both systemd and FHS3 denote /var/run as a compatibility directory,
> new systems should use /run.
>
> There seems to be little reason to not switch to the new FHS layout
> with buildroot, and adding the compatibility symlink.
>
> [1] - https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s13.html
>
> Signed-off-by: Norbert Lange <nolange79@gmail.com>
> ---
>  package/skeleton-init-systemd/skeleton-init-systemd.mk | 2 --
>  system/skeleton/var/run                                | 1 +
>  2 files changed, 1 insertion(+), 2 deletions(-)
>  create mode 120000 system/skeleton/var/run
>
> diff --git a/package/skeleton-init-systemd/skeleton-init-systemd.mk b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> index 5d6b716f7a..528cf43e61 100644
> --- a/package/skeleton-init-systemd/skeleton-init-systemd.mk
> +++ b/package/skeleton-init-systemd/skeleton-init-systemd.mk
> @@ -60,8 +60,6 @@ endif
>  define SKELETON_INIT_SYSTEMD_INSTALL_TARGET_CMDS
>         mkdir -p $(TARGET_DIR)/home
>         mkdir -p $(TARGET_DIR)/srv
> -       mkdir -p $(TARGET_DIR)/var
> -       ln -s ../run $(TARGET_DIR)/var/run
>         $(SKELETON_INIT_SYSTEMD_ROOT_RO_OR_RW)
>  endef
>
> diff --git a/system/skeleton/var/run b/system/skeleton/var/run
> new file mode 120000
> index 0000000000..84ba55b912
> --- /dev/null
> +++ b/system/skeleton/var/run
> @@ -0,0 +1 @@
> +../run
> \ No newline at end of file
> --
> 2.27.0
>

Some future change would be to change relative symlinks touching the
target root to absolutes.
potentially as last step after the fakeroot scripts.
Reasoning can be found at the debian manual (allowing symlinks in root).

Norbert

[1] - https://www.debian.org/doc/debian-policy/ch-files.html#symbolic-links

[Buildroot] [PATCH] system/skeleton: make /var/run a symlink to /run

[Thomas Petazzoni]

Hello Norbert,

On Mon, 29 Jun 2020 12:47:49 +0200
Norbert Lange <nolange79@gmail.com> wrote:

> both systemd and FHS3 denote /var/run as a compatibility directory,
> new systems should use /run.
> 
> There seems to be little reason to not switch to the new FHS layout
> with buildroot, and adding the compatibility symlink.
> 
> [1] - https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s13.html

The commit log is a bit confusing here, especially when looking at the
patch. Indeed, we see you are *removing* code that creates /var/run as
a symlink to /run, but you're saying that you're making /var/run a
symlink to /run.

However, what really happens is that /var/run was already a symlink to
/run when the selected init system is systemd, but not with other init
systems. What your patch does is that it moves all init system to this
convention.

So perhaps a better commit title would be:

===

system/skeleton: always make /var/run a symlink to /run

While Buildroot was already making /var/run a symlink to /run when
systemd was selected as the init system, it was not the case with other
init systems.

However, FHS3 denotes /var/run as a compatibility directory, and new
systems should use /run. So let's switch to this convention regardless
of the init system being used.

===

Also, was there any specific motivation/issue for this change, or just
make things "nicer" ?

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH] system/skeleton: make /var/run a symlink to /run

[Norbert Lange]

Am Di., 14. Juli 2020 um 15:15 Uhr schrieb Thomas Petazzoni
<thomas.petazzoni@bootlin.com>:
>
> Hello Norbert,
>
> On Mon, 29 Jun 2020 12:47:49 +0200
> Norbert Lange <nolange79@gmail.com> wrote:
>
> > both systemd and FHS3 denote /var/run as a compatibility directory,
> > new systems should use /run.
> >
> > There seems to be little reason to not switch to the new FHS layout
> > with buildroot, and adding the compatibility symlink.
> >
> > [1] - https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch05s13.html
>
> The commit log is a bit confusing here, especially when looking at the
> patch. Indeed, we see you are *removing* code that creates /var/run as
> a symlink to /run, but you're saying that you're making /var/run a
> symlink to /run.
>
> However, what really happens is that /var/run was already a symlink to
> /run when the selected init system is systemd, but not with other init
> systems. What your patch does is that it moves all init system to this
> convention.
>
> So perhaps a better commit title would be:
>
> ===
>
> system/skeleton: always make /var/run a symlink to /run
>
> While Buildroot was already making /var/run a symlink to /run when
> systemd was selected as the init system, it was not the case with other
> init systems.
>
> However, FHS3 denotes /var/run as a compatibility directory, and new
> systems should use /run. So let's switch to this convention regardless
> of the init system being used.
>
> ===

Fine with that, can you change that pls?

>
> Also, was there any specific motivation/issue for this change, or just
> make things "nicer" ?

Removal of stuff like this:
ifeq ($(BR2_INIT_SYSTEMD),y)
LTTNG_LIBUST_CONF_OPTS += --with-lttng-system-rundir=/run/lttng
endif

You get warnings everytime you start systemd with units using a
var/run directory
(eg. dbus). So cleaning that up would be the next step once this
change is accepted.

Norbert

[Buildroot] [PATCH] system/skeleton: make /var/run a symlink to /run

[Thomas Petazzoni]

On Tue, 14 Jul 2020 15:35:22 +0200
Norbert Lange <nolange79@gmail.com> wrote:

> > Also, was there any specific motivation/issue for this change, or just
> > make things "nicer" ?  
> 
> Removal of stuff like this:
> ifeq ($(BR2_INIT_SYSTEMD),y)
> LTTNG_LIBUST_CONF_OPTS += --with-lttng-system-rundir=/run/lttng
> endif

I'm confused, this snippet of code is for systemd configurations only,
and your patch doesn't change anything for systemd-based systems, where
/var/run was already a symlink to /run.

Could you clarify ?

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH] system/skeleton: make /var/run a symlink to /run

[Norbert Lange]

Am Di., 14. Juli 2020 um 15:52 Uhr schrieb Thomas Petazzoni
<thomas.petazzoni@bootlin.com>:
>
> On Tue, 14 Jul 2020 15:35:22 +0200
> Norbert Lange <nolange79@gmail.com> wrote:
>
> > > Also, was there any specific motivation/issue for this change, or just
> > > make things "nicer" ?
> >
> > Removal of stuff like this:
> > ifeq ($(BR2_INIT_SYSTEMD),y)
> > LTTNG_LIBUST_CONF_OPTS += --with-lttng-system-rundir=/run/lttng
> > endif
>
> I'm confused, this snippet of code is for systemd configurations only,
> and your patch doesn't change anything for systemd-based systems, where
> /var/run was already a symlink to /run.
>
> Could you clarify ?

chronological:

-   Buildroot uses /var/run as RUNTIME directory for SysV, and /run for systemd.
-   I add the lttng patch above to use either /var/run/lttng or /run/lttng
-   I consider doing the same for dbus as I get warnings otherwise
(actually have a post_install script replacing /var/run with /run)
-   I consider it would be alot easier to just use /run everywhere and
add this patch to see if that's accepted, before doing more
if-butt-ing like with lttng

So the end result should be that /var/run is treated as legacy
unconditionally, and packages would always use /run,
and don't depend on a symlink (potentially on a network drive). the
symlink schoul just be a safety net.

Norbert

[Buildroot] [PATCH] system/skeleton: make /var/run a symlink to /run

[Thomas Petazzoni]

On Tue, 14 Jul 2020 16:22:25 +0200
Norbert Lange <nolange79@gmail.com> wrote:

> chronological:
> 
> -   Buildroot uses /var/run as RUNTIME directory for SysV, and /run for systemd.
> -   I add the lttng patch above to use either /var/run/lttng or /run/lttng
> -   I consider doing the same for dbus as I get warnings otherwise
> (actually have a post_install script replacing /var/run with /run)
> -   I consider it would be alot easier to just use /run everywhere and
> add this patch to see if that's accepted, before doing more
> if-butt-ing like with lttng

But then, you have to anyway tweak lttng to pass:

LTTNG_LIBUST_CONF_OPTS += --with-lttng-system-rundir=/run/lttng

but unconditionally, and no longer depending on whether systemd is used
or not. Correct ?

But... /run is already a tmpfs in sysv-based systems, so what prevents
today from using /run/lttng even for sysv based systems ?

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH] system/skeleton: make /var/run a symlink to /run

[Norbert Lange]

Am Mi., 15. Juli 2020 um 15:43 Uhr schrieb Thomas Petazzoni
<thomas.petazzoni@bootlin.com>:
>
> On Tue, 14 Jul 2020 16:22:25 +0200
> Norbert Lange <nolange79@gmail.com> wrote:
>
> > chronological:
> >
> > -   Buildroot uses /var/run as RUNTIME directory for SysV, and /run for systemd.
> > -   I add the lttng patch above to use either /var/run/lttng or /run/lttng
> > -   I consider doing the same for dbus as I get warnings otherwise
> > (actually have a post_install script replacing /var/run with /run)
> > -   I consider it would be alot easier to just use /run everywhere and
> > add this patch to see if that's accepted, before doing more
> > if-butt-ing like with lttng
>
> But then, you have to anyway tweak lttng to pass:
>
> LTTNG_LIBUST_CONF_OPTS += --with-lttng-system-rundir=/run/lttng
>
> but unconditionally, and no longer depending on whether systemd is used
> or not. Correct ?

That's the idea, yes.

> But... /run is already a tmpfs in sysv-based systems, so what prevents
> today from using /run/lttng even for sysv based systems ?

Ok, I missed that bit, thought it would have unrelated /run and
/var/run directories.
So this patch is just a cleanup then, and buildroot already *always*
uses a tmpfs /run (with compatibilty symlink /var/run),
and I can use /run with lttng and dbus whether this cleanup is merged or not?

I'd redo the patch with those removed, if you agree:

package/skeleton-init-openrc/skeleton/var/run
package/skeleton-init-sysv/skeleton/var/run

Or do nothing if you dont ;)
My new argument would be that this would prevent false assumptions (like mine).

Norbert

[Buildroot] [PATCH] system/skeleton: make /var/run a symlink to /run

[Thomas Petazzoni]

On Wed, 15 Jul 2020 15:53:12 +0200
Norbert Lange <nolange79@gmail.com> wrote:

> > But... /run is already a tmpfs in sysv-based systems, so what prevents
> > today from using /run/lttng even for sysv based systems ?  
> 
> Ok, I missed that bit, thought it would have unrelated /run and
> /var/run directories.
> So this patch is just a cleanup then, and buildroot already *always*
> uses a tmpfs /run (with compatibilty symlink /var/run),
> and I can use /run with lttng and dbus whether this cleanup is merged or not?
> 
> I'd redo the patch with those removed, if you agree:
> 
> package/skeleton-init-openrc/skeleton/var/run
> package/skeleton-init-sysv/skeleton/var/run
> 
> Or do nothing if you dont ;)
> My new argument would be that this would prevent false assumptions (like mine).

OK, the more I look into this, the more I'm confused. To me, it seems
like in both systemd *and* non-systemd cases, /var/run is already a
symlink to /run, but just implemented in a different way.

For the systemd case, we have:

        ln -s ../run $(TARGET_DIR)/var/run

in package/skeleton-init-systemd/skeleton-init-systemd.dmk.

For the sysv/openrc case, we have the skeleton itself that contains:

$ ls -l package/skeleton-init-sysv/skeleton/var/run 
lrwxrwxrwx 1 thomas thomas 6 26 mars  17:10 package/skeleton-init-sysv/skeleton/var/run -> ../run
$ ls -l package/skeleton-init-openrc/skeleton/var/run 
lrwxrwxrwx 1 thomas thomas 6 18 mai   17:32 package/skeleton-init-openrc/skeleton/var/run -> ../run

So, it all cases, /var/run is already a symlink to /run. Am I missing
something here ?

So, if anything needs to be done, it's just cleaning up that and doing
it in the same way for all init systems, perhaps in a common place. But
we need to be careful, skeleton-init-systemd.mk has some
special/complex logic to handle /var and generate a
/etc/tmpfiles.d/var-factory.conf to generate the contents of /var at
boot time when the rootfs is read only and therefore the entire /var is
in tmpfs.

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

[Buildroot] [PATCH] system/skeleton: make /var/run a symlink to /run

[Norbert Lange]

Am Mi., 15. Juli 2020 um 17:38 Uhr schrieb Thomas Petazzoni
<thomas.petazzoni@bootlin.com>:
>
> On Wed, 15 Jul 2020 15:53:12 +0200
> Norbert Lange <nolange79@gmail.com> wrote:
>
> > > But... /run is already a tmpfs in sysv-based systems, so what prevents
> > > today from using /run/lttng even for sysv based systems ?
> >
> > Ok, I missed that bit, thought it would have unrelated /run and
> > /var/run directories.
> > So this patch is just a cleanup then, and buildroot already *always*
> > uses a tmpfs /run (with compatibilty symlink /var/run),
> > and I can use /run with lttng and dbus whether this cleanup is merged or not?
> >
> > I'd redo the patch with those removed, if you agree:
> >
> > package/skeleton-init-openrc/skeleton/var/run
> > package/skeleton-init-sysv/skeleton/var/run
> >
> > Or do nothing if you dont ;)
> > My new argument would be that this would prevent false assumptions (like mine).
>
> OK, the more I look into this, the more I'm confused. To me, it seems
> like in both systemd *and* non-systemd cases, /var/run is already a
> symlink to /run, but just implemented in a different way.
>
> For the systemd case, we have:
>
>         ln -s ../run $(TARGET_DIR)/var/run
>
> in package/skeleton-init-systemd/skeleton-init-systemd.dmk.
>
> For the sysv/openrc case, we have the skeleton itself that contains:
>
> $ ls -l package/skeleton-init-sysv/skeleton/var/run
> lrwxrwxrwx 1 thomas thomas 6 26 mars  17:10 package/skeleton-init-sysv/skeleton/var/run -> ../run
> $ ls -l package/skeleton-init-openrc/skeleton/var/run
> lrwxrwxrwx 1 thomas thomas 6 18 mai   17:32 package/skeleton-init-openrc/skeleton/var/run -> ../run
>
> So, it all cases, /var/run is already a symlink to /run. Am I missing
> something here ?
>
> So, if anything needs to be done, it's just cleaning up that and doing
> it in the same way for all init systems, perhaps in a common place.

I thought about it some more, I think it's fine the way it is for now.
Sometime later I'd remove the logic in systemd as tmpfilesd already
will create the link - but only if sysv compatibility is enabled.
(Still working on a systemd patch to allow tmpfilesd be executed safely
on the host, then this can be cleaned up).

> But
> we need to be careful, skeleton-init-systemd.mk has some
> special/complex logic to handle /var and generate a
> /etc/tmpfiles.d/var-factory.conf to generate the contents of /var at
> boot time when the rootfs is read only and therefore the entire /var is
> in tmpfs.

Yeah.. about that...

First it's weird that a generic option (REMOUNT_ROOTFS_RW) does more than
just remounting the rootfs. This should be its own option.

Then it is already broken or atleast insanely fragile.

-   it kills previous files in /usr/share/factory/var
-   it doesn't handle symlinks (just think of /var already containing
a symlink into that factory),
    especially relative ones.
-   it has sideeffects with tmpfile .confs that are ordered before and
touch /var
-   it has sideeffects with other PRE_CMD_HOOKS touching /var

Whatever the reason was, that this got included, it seems to be a very
narrow and specialised usecase,
and hurting everything else.

With systemd 246 it's possible to boot into a complete ro rootfs,
basic services will work (course you can't write to /var).
A tmpfs overlay or a script + service that creates a bind mount seems
a way better solution to me.

Norbert.

PS.
I tried to ping you in regards to the fakeroot 1.24 upgrade:
http://lists.busybox.net/pipermail/buildroot/2020-May/282161.html