GNU bug report logs - #64775
/run should be cleaned on boot

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 64775 in the body.
You can then email your comments to 64775 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Vagrant Cascadian <vagrant <at> debian.org>
To: bug-guix <at> gnu.org
Subject: /run should be cleaned on boot
Date: Fri, 21 Jul 2023 12:23:54 -0700

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, inline)]

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Csepp <raingloom <at> riseup.net>
To: Vagrant Cascadian <vagrant <at> debian.org>
Cc: 64775 <at> debbugs.gnu.org, bug-guix <at> gnu.org
Subject: Re: bug#64775: /run should be cleaned on boot
Date: Fri, 21 Jul 2023 21:36:40 +0200

Vagrant Cascadian <vagrant <at> debian.org> writes:

> [[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.

Message #14 received at 64775 <at> debbugs.gnu.org (full text, mbox):

From: Vagrant Cascadian <vagrant <at> debian.org>
To: Csepp <raingloom <at> riseup.net>
Cc: 64775 <at> debbugs.gnu.org
Subject: Re: bug#64775: /run should be cleaned on boot
Date: Fri, 21 Jul 2023 12:57:30 -0700

[Message part 1 (text/plain, inline)]

On 2023-07-21, Csepp wrote:
> Vagrant Cascadian <vagrant <at> 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.
...
> 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

[signature.asc (application/pgp-signature, inline)]

Message #17 received at 64775 <at> debbugs.gnu.org (full text, mbox):

From: Saku Laesvuori <saku <at> laesvuori.fi>
To: Vagrant Cascadian <vagrant <at> debian.org>
Cc: 64775 <at> debbugs.gnu.org, Csepp <raingloom <at> riseup.net>
Subject: Re: bug#64775: /run should be cleaned on boot
Date: Fri, 21 Jul 2023 23:24:17 +0300

[Message part 1 (text/plain, inline)]

> > 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.

[signature.asc (application/pgp-signature, inline)]

Message #20 received at 64775 <at> debbugs.gnu.org (full text, mbox):

From: Hilton Chain <hako <at> ultrarare.space>
To: 64775 <at> debbugs.gnu.org
Cc: Vagrant Cascadian <vagrant <at> debian.org>, Saku Laesvuori <saku <at> laesvuori.fi>,
 Csepp <raingloom <at> riseup.net>
Subject: Re: bug#64775: /run should be cleaned on boot
Date: Sun, 06 Aug 2023 21:18:35 +0800

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.

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))

       (delete %debug-file-system
               %base-file-systems))
--8<---------------cut here---------------end--------------->8---

Thanks

Message #23 received at 64775 <at> debbugs.gnu.org (full text, mbox):

From: Vagrant Cascadian <vagrant <at> debian.org>
To: Hilton Chain <hako <at> ultrarare.space>, 64775 <at> debbugs.gnu.org
Cc: Saku Laesvuori <saku <at> laesvuori.fi>, Csepp <raingloom <at> riseup.net>
Subject: Re: bug#64775: /run should be cleaned on boot
Date: Sun, 06 Aug 2023 13:06:37 -0700

[Message part 1 (text/plain, inline)]

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...

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

[signature.asc (application/pgp-signature, inline)]

Message #26 received at 64775 <at> debbugs.gnu.org (full text, mbox):

From: Hilton Chain <hako <at> ultrarare.space>
To: Vagrant Cascadian <vagrant <at> debian.org>
Cc: 64775 <at> debbugs.gnu.org, Saku Laesvuori <saku <at> laesvuori.fi>,
 Csepp <raingloom <at> riseup.net>
Subject: Re: bug#64775: /run should be cleaned on boot
Date: Mon, 07 Aug 2023 09:33:13 +0800

On Mon, 07 Aug 2023 04:06:37 +0800,
Vagrant Cascadian wrote:
>
> [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...

> 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

Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Hilton Chain via Bug reports for GNU Guix <bug-guix <at> gnu.org>
Cc: Vagrant Cascadian <vagrant <at> debian.org>, Hilton Chain <hako <at> ultrarare.space>,
 64775 <at> debbugs.gnu.org, Saku Laesvuori <saku <at> laesvuori.fi>,
 Csepp <raingloom <at> riseup.net>
Subject: Re: bug#64775: /run should be cleaned on boot
Date: Mon, 07 Aug 2023 10:39:08 -0400

Hi,

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

> 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

Message #35 received at 64775 <at> debbugs.gnu.org (full text, mbox):

From: Vagrant Cascadian <vagrant <at> debian.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 64775 <at> debbugs.gnu.org, 61462 <at> debbugs.gnu.org
Subject: /run should be cleaned on boot
Date: Tue, 29 Aug 2023 13:29:14 -0700

[Message part 1 (text/plain, inline)]

On 2023-08-08, Ludovic Courtès wrote:
> Vagrant Cascadian <vagrant <at> 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

[signature.asc (application/pgp-signature, inline)]

Message #38 received at 64775 <at> debbugs.gnu.org (full text, mbox):

From: brian <bjc <at> spork.org>
To: Vagrant Cascadian <vagrant <at> debian.org>
Cc: Ludovic Courtès <ludo <at> gnu.org>, 64775 <at> debbugs.gnu.org,
 61462 <at> debbugs.gnu.org
Subject: Re: bug#64775: /run should be cleaned on boot
Date: Tue, 29 Aug 2023 17:21:47 -0400

Vagrant Cascadian <vagrant <at> debian.org> writes:

> 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

Message #45 received at 64775 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Vagrant Cascadian <vagrant <at> debian.org>
Cc: 64775 <at> debbugs.gnu.org, 61462 <at> debbugs.gnu.org
Subject: Re: bug#64775: /run should be cleaned on boot
Date: Mon, 16 Sep 2024 00:29:14 +0200

Hi,

Vagrant Cascadian <vagrant <at> debian.org> skribis:

> On 2023-08-08, Ludovic Courtès wrote:
>> Vagrant Cascadian <vagrant <at> 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:

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

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

Ludo’.

Message #48 received at 64775 <at> debbugs.gnu.org (full text, mbox):

From: Vagrant Cascadian <vagrant <at> debian.org>
To: Ludovic Courtès <ludo <at> gnu.org>, 72920 <at> debbugs.gnu.org
Cc: 64775 <at> debbugs.gnu.org, 72670 <at> debbugs.gnu.org
Subject: Re: [bug#72920] [PATCH 0/3] Clean out /run upon boot
Date: Fri, 20 Sep 2024 14:26:00 -0700

[Message part 1 (text/plain, inline)]

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. :)

live well,
  vagrant

[signature.asc (application/pgp-signature, inline)]

Message #53 received at 64775-done <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Vagrant Cascadian <vagrant <at> debian.org>
Cc: 64775-done <at> debbugs.gnu.org, 72670-done <at> debbugs.gnu.org,
 72920-done <at> debbugs.gnu.org
Subject: Re: [bug#72920] [PATCH 0/3] Clean out /run upon boot
Date: Wed, 25 Sep 2024 16:26:09 +0200

Vagrant Cascadian <vagrant <at> debian.org> skribis:

> 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’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.