/run should be cleaned on boot

Open

Details

6 participants

brian
Hilton Chain
Maxim Cournoyer
Csepp
Saku Laesvuori
Vagrant Cascadian

Owner: unassigned

Submitted by: Vagrant Cascadian

Severity: normal

Vagrant Cascadian wrote on 21 Jul 21:23 +0200

Recipients:(address . bug-guix@gnu.org)

Message-ID: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:

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

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCZLrbSwAKCRDcUY/If5cW

qjKlAPwJdVVa3gKlW/InWq2SNmS0BHsc0p8Q+R9Wv92zNvqsSAD+P6XLOsrXQ9zO

Gqa0J9FfURexfFuW1xMwHf+E9LtySgM=

=307A

-----END PGP SIGNATURE-----

Csepp wrote on 21 Jul 21:36 +0200

Recipients:(name . Vagrant Cascadian)(address . vagrant@debian.org)

Message-ID: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.

Vagrant Cascadian wrote on 21 Jul 21:57 +0200

Recipients:(name . Csepp)(address . raingloom@riseup.net)(address . 64775@debbugs.gnu.org)

Message-ID: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-----

Saku Laesvuori wrote on 21 Jul 22:24 +0200

Recipients:(name . Vagrant Cascadian)(address . vagrant@debian.org)

Message-ID: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.

Hilton Chain wrote on 6 Aug 15:18 +0200

Recipients:(address . 64775@debbugs.gnu.org)

Message-ID: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

Vagrant Cascadian wrote on 6 Aug 22:06 +0200

Recipients:

Message-ID: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-----

Hilton Chain wrote on 7 Aug 03:33 +0200

Recipients:(name . Vagrant Cascadian)(address . vagrant@debian.org)

Message-ID: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

Maxim Cournoyer wrote on 7 Aug 16:39 +0200

Recipients:(name . Hilton Chain via Bug reports for GNU Guix)(address . bug-guix@gnu.org)

Message-ID: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

Vagrant Cascadian wrote on 29 Aug 22:29 +0200

/run should be cleaned on boot

Recipients:(name . Ludovic Courtès)(address . ludo@gnu.org)

Message-ID: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:

https://issues.guix.gnu.org/64775

live well,

vagrant

-----BEGIN PGP SIGNATURE-----

iHUEARYKAB0WIQRlgHNhO/zFx+LkXUXcUY/If5cWqgUCZO5VGgAKCRDcUY/If5cW

qscTAP46tqkiBHdLjKXzI/n7Wg8wMKgBEhcxQtxMKNw7eoCpkAD+IqMp4nRebmnS

XOMfX+y15RPUb2AQl3ZgzB7GbtJI/w8=

=/Tnj

-----END PGP SIGNATURE-----

brian wrote on 29 Aug 23:21 +0200

Recipients:(name . Vagrant Cascadian)(address . vagrant@debian.org)

Message-ID: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

Your comment

Commenting via the web interface is currently disabled.

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

is:open	open issues
is:done	closed issues
submitter:<who>	search issue submitter
author:<who>	search by message author
date:yesterday..now	search by issue date
mdate:3m..2d	search by message date