From: Vagrant Cascadian <vagrant@debian.org>
To: Csepp <raingloom@riseup.net>
Cc: 64775@debbugs.gnu.org
Subject: bug#64775: /run should be cleaned on boot
Date: Fri, 21 Jul 2023 12:57:30 -0700 [thread overview]
Message-ID: <875y6dyr4l.fsf@wireframe> (raw)
In-Reply-To: <87y1j9njij.fsf@riseup.net>
[-- Attachment #1: Type: text/plain, Size: 1453 bytes --]
On 2023-07-21, Csepp wrote:
> 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.
...
> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
next prev parent reply other threads:[~2023-07-21 19:58 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
2023-07-21 19:57 ` Vagrant Cascadian [this message]
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=875y6dyr4l.fsf@wireframe \
--to=vagrant@debian.org \
--cc=64775@debbugs.gnu.org \
--cc=raingloom@riseup.net \
/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).