bug#64775: /run should be cleaned on boot
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 Description: PGP signature
bug#64775: /run should be cleaned on boot
Vagrant Cascadian 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.
bug#64775: /run should be cleaned on boot
On 2023-07-21, Csepp wrote: > Vagrant Cascadian 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 1848total 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 Description: PGP signature
bug#64775: /run should be cleaned on boot
> > 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 > 1848total > > 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 Description: PGP signature
bug#64775: /run should be cleaned on boot
Hi all, On Sat, 22 Jul 2023 04:24:17 +0800, Saku Laesvuori via Bug reports for GNU Guix wrote: > > [1 ] > > > 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 > > 1848total > > > > 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 ] > 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
bug#64775: /run should be cleaned on boot
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 ] >> > > 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 >> > 1848total >> > >> > 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 ] >> 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 Description: PGP signature
bug#64775: /run should be cleaned on boot
On Mon, 07 Aug 2023 04:06:37 +0800, Vagrant Cascadian wrote: > > [1 ] > 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 ] > >> > > 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 > >> > 1848total > >> > > >> > 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 ] > >> 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
bug#64775: /run should be cleaned on boot
Hi, Hilton Chain via Bug reports for GNU Guix writes: > Hi all, > > On Sat, 22 Jul 2023 04:24:17 +0800, > Saku Laesvuori via Bug reports for GNU Guix wrote: >> >> [1 ] >> > > 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 >> > 1848total >> > >> > 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 ] >> 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
bug#64775: /run should be cleaned on boot
On 2023-08-08, Ludovic Courtès wrote: > Vagrant Cascadian 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 Description: PGP signature
bug#64775: /run should be cleaned on boot
Vagrant Cascadian 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
