unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Vagrant Cascadian <vagrant@debian.org>
To: 64775@debbugs.gnu.org
Subject: bug#64775: /run should be cleaned on boot
Date: Fri, 21 Jul 2023 12:23:54 -0700	[thread overview]
Message-ID: <878rb9ysol.fsf@wireframe> (raw)

[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

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

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-21 19:23 Vagrant Cascadian [this message]
2023-07-21 19:36 ` bug#64775: /run should be cleaned on boot Csepp
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=878rb9ysol.fsf@wireframe \
    --to=vagrant@debian.org \
    --cc=64775@debbugs.gnu.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).