unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Csepp <raingloom@riseup.net>
To: Vagrant Cascadian <vagrant@debian.org>
Cc: 64775@debbugs.gnu.org
Subject: bug#64775: /run should be cleaned on boot
Date: Fri, 21 Jul 2023 21:36:40 +0200	[thread overview]
Message-ID: <87y1j9njij.fsf@riseup.net> (raw)
In-Reply-To: <878rb9ysol.fsf@wireframe>


Vagrant Cascadian <vagrant@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.




  reply	other threads:[~2023-07-21 19:38 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-21 19:23 bug#64775: /run should be cleaned on boot Vagrant Cascadian
2023-07-21 19:36 ` Csepp [this message]
2023-07-21 19:57   ` Vagrant Cascadian
2023-07-21 20:24     ` Saku Laesvuori via Bug reports for GNU Guix
2023-08-06 13:18       ` Hilton Chain via Bug reports for GNU Guix
2023-08-06 20:06         ` Vagrant Cascadian
2023-08-07  1:33           ` Hilton Chain via Bug reports for GNU Guix
2023-08-07 14:39         ` Maxim Cournoyer
     [not found] <87r0uuehlr.fsf@nckx>
     [not found] ` <129e8d298556f6a159fcb704ed3df4bf0709ddd3.1689465600.git.me@tobias.gr>
     [not found]   ` <87edl1yu2k.fsf@wireframe>
     [not found]     ` <87bkg5yt91.fsf@wireframe>
     [not found]       ` <87r0odpmot.fsf_-_@gnu.org>
     [not found]         ` <87o7ipvbhh.fsf__48662.4622646318$1693341314$gmane$org@wireframe>
2023-08-29 21:21           ` brian via Bug reports for GNU Guix

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y1j9njij.fsf@riseup.net \
    --to=raingloom@riseup.net \
    --cc=64775@debbugs.gnu.org \
    --cc=vagrant@debian.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).