/run should be cleaned on boot

  • Done
  • quality assurance status badge
Details
7 participants
  • brian
  • Hilton Chain
  • Ludovic Courtès
  • Maxim Cournoyer
  • Csepp
  • Saku Laesvuori
  • Vagrant Cascadian
Owner
unassigned
Submitted by
Vagrant Cascadian
Severity
important
Merged with
V
V
Vagrant Cascadian wrote on 21 Jul 2023 21:23
(address . bug-guix@gnu.org)
878rb9ysol.fsf@wireframe
So, if there are files sitting around in /run, they do not get cleaned
up unless it is something guix is already aware of
(e.g. /run/setuid-programs).

I noticed this when experimenting with:

Add support for file capabilities(7)

Even after a reboot, the leftovers from that experimental patchset were
still present in /run...

While I know that Guix does not really follow the FHS in most respects,
maybe the intention of /run defined there should still be respected?


3.15. /run : Run-time variable data
3.15.1. Purpose

This directory contains system information data describing the system
since it was booted. Files under this directory must be cleared
(removed or truncated as appropriate) at the beginning of the boot
process.
...

Many distros implement this by having /run on a tmpfs, but making sure
to clean up /run at boot seems like a reasonable thing to do at the very
least.

I am not sure if it makes sense to do housecleaning of /run from guix
system reconfigure ... as there may be legitimate uses for other
processes to write there.


live well,
vagrant
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCZLrbSwAKCRDcUY/If5cW
qjKlAPwJdVVa3gKlW/InWq2SNmS0BHsc0p8Q+R9Wv92zNvqsSAD+P6XLOsrXQ9zO
Gqa0J9FfURexfFuW1xMwHf+E9LtySgM=
=307A
-----END PGP SIGNATURE-----

C
C
Csepp wrote on 21 Jul 2023 21:36
(name . Vagrant Cascadian)(address . vagrant@debian.org)
87y1j9njij.fsf@riseup.net
Vagrant Cascadian <vagrant@debian.org> writes:

Toggle quote (41 lines)
> [[PGP Signed Part:Undecided]]
> So, if there are files sitting around in /run, they do not get cleaned
> up unless it is something guix is already aware of
> (e.g. /run/setuid-programs).
>
> I noticed this when experimenting with:
>
> https://issues.guix.gnu.org/61462
> Add support for file capabilities(7)
>
> Even after a reboot, the leftovers from that experimental patchset were
> still present in /run...
>
> While I know that Guix does not really follow the FHS in most respects,
> maybe the intention of /run defined there should still be respected?
>
> https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html
>
> 3.15. /run : Run-time variable data
> 3.15.1. Purpose
>
> This directory contains system information data describing the system
> since it was booted. Files under this directory must be cleared
> (removed or truncated as appropriate) at the beginning of the boot
> process.
> ...
>
> Many distros implement this by having /run on a tmpfs, but making sure
> to clean up /run at boot seems like a reasonable thing to do at the very
> least.
>
> I am not sure if it makes sense to do housecleaning of /run from guix
> system reconfigure ... as there may be legitimate uses for other
> processes to write there.
>
>
> live well,
> vagrant
>
> [[End of PGP Signed Part]]

I vote for TMPFS, since that would also reduce flash wear.
Honestly I don't get why it's not already using TMPFS.
V
V
Vagrant Cascadian wrote on 21 Jul 2023 21:57
(name . Csepp)(address . raingloom@riseup.net)(address . 64775@debbugs.gnu.org)
875y6dyr4l.fsf@wireframe
On 2023-07-21, Csepp wrote:
Toggle quote (22 lines)
> Vagrant Cascadian <vagrant@debian.org> writes:
>> While I know that Guix does not really follow the FHS in most respects,
>> maybe the intention of /run defined there should still be respected?
>>
>> https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s15.html
>>
>> 3.15. /run : Run-time variable data
>> 3.15.1. Purpose
>>
>> This directory contains system information data describing the system
>> since it was booted. Files under this directory must be cleared
>> (removed or truncated as appropriate) at the beginning of the boot
>> process.
>> ...
>>
>> Many distros implement this by having /run on a tmpfs, but making sure
>> to clean up /run at boot seems like a reasonable thing to do at the very
>> least.
>>
>> I am not sure if it makes sense to do housecleaning of /run from guix
>> system reconfigure ... as there may be legitimate uses for other
>> processes to write there.
...
Toggle quote (3 lines)
> I vote for TMPFS, since that would also reduce flash wear.
> Honestly I don't get why it's not already using TMPFS.

One argument could be how much ram it takes:

$ du -sc /run/*
12 /run/blkid
0 /run/booted-system
0 /run/current-system
1312 /run/setuid-programs
524 /run/udev
1848 total

That is with no explicit setuid programs configured, on a machine with a
fairly minimal configuration.

Not a *huge* amount of ram, but not nothing, either...

live well,
vagrant
-----BEGIN PGP SIGNATURE-----

iHQEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCZLrjKgAKCRDcUY/If5cW
qj7pAQDrIgz6i0S36bLiL49S6CGkKCOEmcR0eR21jGB03PkhjwD1FKQ2K6aP8Idn
Nzj4CxpnE7VUqm7GWYhFAn72toTyAg==
=KJXs
-----END PGP SIGNATURE-----

S
S
Saku Laesvuori wrote on 21 Jul 2023 22:24
(name . Vagrant Cascadian)(address . vagrant@debian.org)
20230721202417.6kfmen37cc2h25ko@X-kone
Toggle quote (18 lines)
> > I vote for TMPFS, since that would also reduce flash wear.
> > Honestly I don't get why it's not already using TMPFS.
>
> One argument could be how much ram it takes:
>
> $ du -sc /run/*
> 12 /run/blkid
> 0 /run/booted-system
> 0 /run/current-system
> 1312 /run/setuid-programs
> 524 /run/udev
> 1848 total
>
> That is with no explicit setuid programs configured, on a machine with a
> fairly minimal configuration.
>
> Not a *huge* amount of ram, but not nothing, either...

I'd say it's effectively nothing for almost all devices capable of
running Guix. On my laptop the size of /run is 4804 (4.7M). In a quick
test one terminal window with only zsh running in it took almost 10
times as much ram.
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEoMkZR3NPB29fCOn/JX0oSiodOjIFAmS66XEACgkQJX0oSiod
OjLyGg/9HNBsRuEUSMC3dhK6I3EHmdFfkgpH8venf5YTy4Hm6jg1xTEmgNhsxfvl
fuJa3JyQVE2aoaMQBfsZYy0GhlS8/S5mQkByrOlhA9RP6/IxCrUJqsPa8ZFvjF2h
XKB7aLnSgfdW2GWvy7nzdt+qvymwcRv1nLXXTWpl5rBJyI6AGxOlqBkaU1SDTRV+
LVMyc+rq+TXkPIyblv8fP3uPdIVm7+io9u0o9XMv27jUS8bd+NueWoF7ECgrRm5z
aNMA4YdYjxYtOPSE9XzU1tEHvXctd3jBYzTowh+AbuC8QCY1ScQLBA8OptgQ0zGk
EGzoOak2QNu+W1bxFZE6+Pw80Ooyd54v5BB6gyIeTm4LYEkp0hqKvkiP1XlJWFVc
1VNx8Fl2uqQYc9eyidxg7HUvEsRcBbMq0nN0zdtkLaWT4uwomfmysZ1dj4lWtJ2E
Ny79wMRJebIgMvO8np6mEqD0KGvs0/ewaNck537mC1Ivd9O4qonQ8adzVRhid4kc
Mmo7uGB9vymR+4rO0SI+GpUA0c3MEtkKi2vNh27MIaC0t2HbF8X4YyI0BtuVS88+
Pb09Q5q+Et1EMke5skSJ/L1IbCEqEyQKhp8KV9uY9WACoD2ddgUkzHl4Ph+mCKt1
AvQ+8WXDnZwpptRmg/5jiUF6ci2PKcorq/je/Z6ELUBfygM14y4=
=gZUj
-----END PGP SIGNATURE-----


H
H
Hilton Chain wrote on 6 Aug 2023 15:18
(address . 64775@debbugs.gnu.org)
87wmy848d0.wl-hako@ultrarare.space
Hi all,

On Sat, 22 Jul 2023 04:24:17 +0800,
Saku Laesvuori via Bug reports for GNU Guix wrote:
Toggle quote (27 lines)
>
> [1 <text/plain; us-ascii (quoted-printable)>]
> > > I vote for TMPFS, since that would also reduce flash wear.
> > > Honestly I don't get why it's not already using TMPFS.
> >
> > One argument could be how much ram it takes:
> >
> > $ du -sc /run/*
> > 12 /run/blkid
> > 0 /run/booted-system
> > 0 /run/current-system
> > 1312 /run/setuid-programs
> > 524 /run/udev
> > 1848 total
> >
> > That is with no explicit setuid programs configured, on a machine with a
> > fairly minimal configuration.
> >
> > Not a *huge* amount of ram, but not nothing, either...
>
> I'd say it's effectively nothing for almost all devices capable of
> running Guix. On my laptop the size of /run is 4804 (4.7M). In a quick
> test one terminal window with only zsh running in it took almost 10
> times as much ram.
> [2 signature.asc <application/pgp-signature (7bit)>]
> No public key for 257D284A2A1D3A32 created at 2023-07-22T04:24:17+0800 using RSA

I'm currently using tmpfs for /tmp, /run and /var/run on my Guix
Systems.

If you are interested, this is my base file systems:
Toggle snippet (24 lines)
(cons* (file-system
(device "none")
(mount-point "/tmp")
(type "tmpfs")
(check? #f))

(file-system
(device "none")
(mount-point "/run")
(type "tmpfs")
(needed-for-boot? #t)
(check? #f))

(file-system
(device "none")
(mount-point "/var/run")
(type "tmpfs")
(needed-for-boot? #t)
(check? #f))

(delete %debug-file-system
%base-file-systems))

Thanks
V
V
Vagrant Cascadian wrote on 6 Aug 2023 22:06
878raoylyq.fsf@wireframe
On 2023-08-06, Hilton Chain wrote:
Toggle quote (54 lines)
> On Sat, 22 Jul 2023 04:24:17 +0800,
> Saku Laesvuori via Bug reports for GNU Guix wrote:
>>
>> [1 <text/plain; us-ascii (quoted-printable)>]
>> > > I vote for TMPFS, since that would also reduce flash wear.
>> > > Honestly I don't get why it's not already using TMPFS.
>> >
>> > One argument could be how much ram it takes:
>> >
>> > $ du -sc /run/*
>> > 12 /run/blkid
>> > 0 /run/booted-system
>> > 0 /run/current-system
>> > 1312 /run/setuid-programs
>> > 524 /run/udev
>> > 1848 total
>> >
>> > That is with no explicit setuid programs configured, on a machine with a
>> > fairly minimal configuration.
>> >
>> > Not a *huge* amount of ram, but not nothing, either...
>>
>> I'd say it's effectively nothing for almost all devices capable of
>> running Guix. On my laptop the size of /run is 4804 (4.7M). In a quick
>> test one terminal window with only zsh running in it took almost 10
>> times as much ram.
>> [2 signature.asc <application/pgp-signature (7bit)>]
>> No public key for 257D284A2A1D3A32 created at 2023-07-22T04:24:17+0800 using RSA
>
> I'm currently using tmpfs for /tmp, /run and /var/run on my Guix
> Systems.
>
> If you are interested, this is my base file systems:
> --8<---------------cut here---------------start------------->8---
> (cons* (file-system
> (device "none")
> (mount-point "/tmp")
> (type "tmpfs")
> (check? #f))
>
> (file-system
> (device "none")
> (mount-point "/run")
> (type "tmpfs")
> (needed-for-boot? #t)
> (check? #f))
>
> (file-system
> (device "none")
> (mount-point "/var/run")
> (type "tmpfs")
> (needed-for-boot? #t)
> (check? #f))

You probably want to restrict permissions on /run and /var/run, as the
defaults for tmpfs are world-writeable, allowing any user or process to
create files or directories in potentially harmful ways...

For /tmp, these defaults are appropriate, however tricky a
world-writeable directory is...

Although I rarely have enough spare ram on a system to have /tmp be
tmpfs for Guix System because builds happen there by default, and
occasionally I need a lot more space than available ram in some cases.


live well,
vagrant
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCZM/9TQAKCRDcUY/If5cW
qqILAQDuw5mBcUClgZnzly9bjaOpcOZjJzCwPwoV+VjXCl+tlQEAht8Snx+h7LpV
LIP51+eJgrP5038zMj5W5gbuPt2u2Qs=
=B3Di
-----END PGP SIGNATURE-----

H
H
Hilton Chain wrote on 7 Aug 2023 03:33
(name . Vagrant Cascadian)(address . vagrant@debian.org)
875y5rws9y.wl-hako@ultrarare.space
On Mon, 07 Aug 2023 04:06:37 +0800,
Vagrant Cascadian wrote:
Toggle quote (64 lines)
>
> [1 <text/plain (7bit)>]
> On 2023-08-06, Hilton Chain wrote:
> > On Sat, 22 Jul 2023 04:24:17 +0800,
> > Saku Laesvuori via Bug reports for GNU Guix wrote:
> >>
> >> [1 <text/plain; us-ascii (quoted-printable)>]
> >> > > I vote for TMPFS, since that would also reduce flash wear.
> >> > > Honestly I don't get why it's not already using TMPFS.
> >> >
> >> > One argument could be how much ram it takes:
> >> >
> >> > $ du -sc /run/*
> >> > 12 /run/blkid
> >> > 0 /run/booted-system
> >> > 0 /run/current-system
> >> > 1312 /run/setuid-programs
> >> > 524 /run/udev
> >> > 1848 total
> >> >
> >> > That is with no explicit setuid programs configured, on a machine with a
> >> > fairly minimal configuration.
> >> >
> >> > Not a *huge* amount of ram, but not nothing, either...
> >>
> >> I'd say it's effectively nothing for almost all devices capable of
> >> running Guix. On my laptop the size of /run is 4804 (4.7M). In a quick
> >> test one terminal window with only zsh running in it took almost 10
> >> times as much ram.
> >> [2 signature.asc <application/pgp-signature (7bit)>]
> >> No public key for 257D284A2A1D3A32 created at 2023-07-22T04:24:17+0800 using RSA
> >
> > I'm currently using tmpfs for /tmp, /run and /var/run on my Guix
> > Systems.
> >
> > If you are interested, this is my base file systems:
> > --8<---------------cut here---------------start------------->8---
> > (cons* (file-system
> > (device "none")
> > (mount-point "/tmp")
> > (type "tmpfs")
> > (check? #f))
> >
> > (file-system
> > (device "none")
> > (mount-point "/run")
> > (type "tmpfs")
> > (needed-for-boot? #t)
> > (check? #f))
> >
> > (file-system
> > (device "none")
> > (mount-point "/var/run")
> > (type "tmpfs")
> > (needed-for-boot? #t)
> > (check? #f))
>
> You probably want to restrict permissions on /run and /var/run, as the
> defaults for tmpfs are world-writeable, allowing any user or process to
> create files or directories in potentially harmful ways...
>
> For /tmp, these defaults are appropriate, however tricky a
> world-writeable directory is...

I have set the mode and size limit on them.

Thank you so much! Otherwise I won't notice that...

Toggle quote (4 lines)
> Although I rarely have enough spare ram on a system to have /tmp be
> tmpfs for Guix System because builds happen there by default, and
> occasionally I need a lot more space than available ram in some cases.

I have enough RAM for builds I currently do on my laptop and it's the
builder for other systems, so tmpfs is fine for me.

Thanks
M
M
Maxim Cournoyer wrote on 7 Aug 2023 16:39
(name . Hilton Chain via Bug reports for GNU Guix)(address . bug-guix@gnu.org)
87wmy6ex2r.fsf@gmail.com
Hi,

Hilton Chain via Bug reports for GNU Guix <bug-guix@gnu.org> writes:

Toggle quote (34 lines)
> Hi all,
>
> On Sat, 22 Jul 2023 04:24:17 +0800,
> Saku Laesvuori via Bug reports for GNU Guix wrote:
>>
>> [1 <text/plain; us-ascii (quoted-printable)>]
>> > > I vote for TMPFS, since that would also reduce flash wear.
>> > > Honestly I don't get why it's not already using TMPFS.
>> >
>> > One argument could be how much ram it takes:
>> >
>> > $ du -sc /run/*
>> > 12 /run/blkid
>> > 0 /run/booted-system
>> > 0 /run/current-system
>> > 1312 /run/setuid-programs
>> > 524 /run/udev
>> > 1848 total
>> >
>> > That is with no explicit setuid programs configured, on a machine with a
>> > fairly minimal configuration.
>> >
>> > Not a *huge* amount of ram, but not nothing, either...
>>
>> I'd say it's effectively nothing for almost all devices capable of
>> running Guix. On my laptop the size of /run is 4804 (4.7M). In a quick
>> test one terminal window with only zsh running in it took almost 10
>> times as much ram.
>> [2 signature.asc <application/pgp-signature (7bit)>]
>> No public key for 257D284A2A1D3A32 created at 2023-07-22T04:24:17+0800 using RSA
>
> I'm currently using tmpfs for /tmp, /run and /var/run on my Guix
> Systems.

Without reviewing how our code base uses /run, it seems reasonable that
this should be on a tmpfs. Can anyone think of a reason not to do so?
Otherwise, I suggest we make it so.

--
Thanks,
Maxim
V
V
Vagrant Cascadian wrote on 29 Aug 2023 22:29
/run should be cleaned on boot
(name . Ludovic Courtès)(address . ludo@gnu.org)
87o7ipvbhh.fsf@wireframe
On 2023-08-08, Ludovic Courtès wrote:
Toggle quote (14 lines)
> Vagrant Cascadian <vagrant@debian.org> skribis:
>> Oh, I noticed on reconfiguring back to a system without the patches to
>> support /run/privileged configurations ... the /run/privileged directory
>> is still present, with all those files sitting there in their previous
>> state.
>>
>> This is why I think at least by default, many other distros implement
>> /run as a tmpfs or similar, so that it at least gets thrown out at
>> reboot. Though this is obviously a deeper problem than just this patch
>> series... I will file a separate bug about that.
>
> We could try to make that change: /run as tmpfs, or wiped by
> ‘cleanup-service-type’.

Or both, really!

Filed:


live well,
vagrant
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCZO5VGgAKCRDcUY/If5cW
qscTAP46tqkiBHdLjKXzI/n7Wg8wMKgBEhcxQtxMKNw7eoCpkAD+IqMp4nRebmnS
XOMfX+y15RPUb2AQl3ZgzB7GbtJI/w8=
=/Tnj
-----END PGP SIGNATURE-----

B
B
brian wrote on 29 Aug 2023 23:21
(name . Vagrant Cascadian)(address . vagrant@debian.org)
87ttshilxw.fsf@spork.org
Vagrant Cascadian <vagrant@debian.org> writes:

Toggle quote (10 lines)
> On 2023-08-08, Ludovic Courtès wrote:
>> We could try to make that change: /run as tmpfs, or wiped by
>> ‘cleanup-service-type’.
>
> Or both, really!
>
> Filed:
>
> https://issues.guix.gnu.org/64775

I tried this a while ago, and the trivial case of mounting /run as tmpfs
in the operating-system definition causes errors during activation. It
turns out that the /run/current-system symlink is activated before all
non-root mounts, so mounting /run afterwards causes everything to break.

I don't have a solution, and haven't even looked at it past this, but
maybe this report will help.

-bjc
L
L
Ludovic Courtès wrote on 18 Aug 22:48 +0200
control message for bug #64775
(address . control@debbugs.gnu.org)
87r0al4kxk.fsf@gnu.org
merge 64775 72670
quit
L
L
Ludovic Courtès wrote on 18 Aug 22:48 +0200
(address . control@debbugs.gnu.org)
87plq54kxf.fsf@gnu.org
severity 64775 important
quit
L
L
Ludovic Courtès wrote on 16 Sep 00:29 +0200
Re: bug#64775: /run should be cleaned on boot
(name . Vagrant Cascadian)(address . vagrant@debian.org)
87msk8a6v9.fsf@gnu.org
Hi,

Vagrant Cascadian <vagrant@debian.org> skribis:

Toggle quote (21 lines)
> On 2023-08-08, Ludovic Courtès wrote:
>> Vagrant Cascadian <vagrant@debian.org> skribis:
>>> Oh, I noticed on reconfiguring back to a system without the patches to
>>> support /run/privileged configurations ... the /run/privileged directory
>>> is still present, with all those files sitting there in their previous
>>> state.
>>>
>>> This is why I think at least by default, many other distros implement
>>> /run as a tmpfs or similar, so that it at least gets thrown out at
>>> reboot. Though this is obviously a deeper problem than just this patch
>>> series... I will file a separate bug about that.
>>
>> We could try to make that change: /run as tmpfs, or wiped by
>> ‘cleanup-service-type’.
>
> Or both, really!
>
> Filed:
>
> https://issues.guix.gnu.org/64775

This went unnoticed but here’s a patch:


I’ll apply it soon if there are no objections.

Ludo’.
V
V
Vagrant Cascadian wrote on 20 Sep 23:26 +0200
Re: [bug#72920] [PATCH 0/3] Clean out /run upon boot
8734lukoev.fsf@wireframe
On 2024-08-31, Ludovic Courtès wrote:
Toggle quote (5 lines)
> Ludovic Courtès (3):
> services: cleanup: Run under C.UTF-8 locale.
> services: cleanup: Create directories with the right mode upfront.
> services: cleanup: Delete /run upon boot.

As they say, Looks Good To Me. :)

live well,
vagrant
-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCZu3oaAAKCRDcUY/If5cW
qmR4AP0d/G8/mlAelJUR8hv4R4Bbpws/YhbEef9A0J7ret+shAD6ArNIowpg4bCH
6kLn33u7J+854xvPpJtWlj6PR2nCYwE=
=STTZ
-----END PGP SIGNATURE-----

L
L
Ludovic Courtès wrote on 25 Sep 16:26 +0200
(name . Vagrant Cascadian)(address . vagrant@debian.org)
8734lnu7we.fsf@gnu.org
Vagrant Cascadian <vagrant@debian.org> skribis:

Toggle quote (8 lines)
> On 2024-08-31, Ludovic Courtès wrote:
>> Ludovic Courtès (3):
>> services: cleanup: Run under C.UTF-8 locale.
>> services: cleanup: Create directories with the right mode upfront.
>> services: cleanup: Delete /run upon boot.
>
> As they say, Looks Good To Me. :)

Thanks, pushed as c250033aa69f35e64949a87fd8482b253dd416b4, except for
the first one because I remembered that C.UTF-8 is unavailable in
cross-compiled programs.

Ludo’.
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 64775@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 64775
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch