Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On Thu, 30 May 2024 at 15:41:50 +0200, Johannes Schauer Marin Rodrigues wrote: > I also found another issue with this change in systemd. After the upload to > unstable, 76 out of 264 mmdebstrap tests on jenkins.debian.net started to > fail: > > https://jenkins.debian.net/job/mmdebstrap-jenkins-worker/692/consoleText > > The problem is, that debootstrap wants to mknod which will not work on a tmpfs > mounted with nodev: > > + debootstrap --no-merged-usr --variant=buildd oldstable /tmp/tmp.nWmx8YeAh3 > http://127.0.0.1/debian > /usr/sbin/debootstrap: 1840: cannot create /tmp/tmp.nWmx8YeAh3/test-dev-null: > Permission denied > E: Cannot install into target '/tmp/tmp.nWmx8YeAh3' mounted with noexec or > nodev > > Maybe this affects more CI scripts and test setups which attempt to create a > temporary chroot with debootstrap in /tmp. I believe this arrangement would also fail if a separate on-disk /tmp was mounted nodev (which is somewhat common security hardening advice, although I don't know whether d-i sets this up if asked for a separate /tmp). In principle, even the root filesystem could probably be mounted nodev these days, since /dev is typically a devtmpfs; but I've never tried it, and I don't know whether anyone really does that. > The fix which is documented in systemd NEWS makes everything work again: > > --customize-hook='touch "$1/etc/systemd/system/tmp.mount"' Alternatively, you could consider using somewhere like /var/tmp or /var/cache/mmdebstrap that is less likely to be mounted nodev? (As a bonus, those locations are normally on-disk and therefore less likely to run out of space for chroots/filesystem images/etc. than /tmp.) smcv
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
Hi, Quoting Peter Pentchev (2024-05-30 10:33:08) > > thank you for having discussed this change on d-devel and for adding > > documentation to NEWS and release notes to announce this change. I also > > think it is sensible to roll this only out on new installations and to keep > > the behaviour on existing setups. Thank you for implementing that as well. > > > > That being said, maybe some Perl wizard knows how to do a flock on a > > directory > > in Perl? > > I wouldn't call myself a Perl wizard by a long stretch, but I can give it a > try :) > > > I tried this: > > > > use Fcntl qw(LOCK_EX); > > opendir(my $handle, ".") or die "opendir: $!"; > [snip] > > Here lies your problem. The flock(2) syscall works on file descriptors, > the things returned by open(2), not on the dirent structures returned by > opendir(3). So you need something like this: > > use v5.10; # I really should switch to at least 5.16 if not 5.24 > use strict; > use warnings; > > use Fcntl qw(O_RDONLY O_DIRECTORY LOCK_EX); > > my $dirname = "/tmp/to-be-locked"; > sysopen(my $handle, "/tmp/to-be-locked", O_RDONLY | O_DIRECTORY) or > die "Could not open $dirname: $!\n"; > flock($handle, LOCK_EX) or > die "Could not lock $dirname: $!\n"; > > say "locked, it seems"; > sleep(3600);' > > I only put the sleep() part so I could check using lsof that > the directory was indeed locked. And yeah, the v5.10 part is a leftover > from the days (...until a month or two ago...) when I still had to > support stock CentOS 7 systems; I really should train my fingers to > put 5.24 there. > > Hope that helps! it absolutely does! Thank you! I was misled by `perldoc -f flock` which states that it works on filehandles. I'll add your name to the git commit message unless you object. :) I also found another issue with this change in systemd. After the upload to unstable, 76 out of 264 mmdebstrap tests on jenkins.debian.net started to fail: https://jenkins.debian.net/job/mmdebstrap-jenkins-worker/692/consoleText The problem is, that debootstrap wants to mknod which will not work on a tmpfs mounted with nodev: + debootstrap --no-merged-usr --variant=buildd oldstable /tmp/tmp.nWmx8YeAh3 http://127.0.0.1/debian /usr/sbin/debootstrap: 1840: cannot create /tmp/tmp.nWmx8YeAh3/test-dev-null: Permission denied E: Cannot install into target '/tmp/tmp.nWmx8YeAh3' mounted with noexec or nodev Maybe this affects more CI scripts and test setups which attempt to create a temporary chroot with debootstrap in /tmp. The fix which is documented in systemd NEWS makes everything work again: --customize-hook='touch "$1/etc/systemd/system/tmp.mount"' Thanks! cheers, josch signature.asc Description: signature
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On Thu, May 30, 2024 at 08:35:47AM +0200, Johannes Schauer Marin Rodrigues wrote: > Hi, > > Quoting Luca Boccassi (2024-05-28 01:54:08) > > Thanks for the useful input, the following has been done: > > > > - existing installations pre-trixie will get an orphaned tmpfiles.d in > > /etc/ that keeps the existing behaviour unchanged (no cleanup of > > /var/tmp) > > - openssh and tmux have been fixed to provide a tmpfiles.d exception > > to retain their respective files > > - the /tmp/ description in debian-installer has been updated to note > > it is a tmpfs by default (via a commit in partman-basicfilesystems, > > will upload if nobody gets around to it before Trixie's freeze) > > - two paragraphs have been provided for the release notes ticket > > - the changes are also noted in NEWS, with instructions on how to > > override locally > > - as mentioned, the latest upload to unstable makes /tmp/ a tmpfs by > > default and for new installations 10+ days old files in /tmp/ and 30+ days > > old files in /var/tmp/ are cleaned up daily > > thank you for having discussed this change on d-devel and for adding > documentation to NEWS and release notes to announce this change. I also think > it is sensible to roll this only out on new installations and to keep the > behaviour on existing setups. Thank you for implementing that as well. > > That being said, maybe some Perl wizard knows how to do a flock on a directory > in Perl? I wouldn't call myself a Perl wizard by a long stretch, but I can give it a try :) > I tried this: > > use Fcntl qw(LOCK_EX); > opendir(my $handle, ".") or die "opendir: $!"; [snip] Here lies your problem. The flock(2) syscall works on file descriptors, the things returned by open(2), not on the dirent structures returned by opendir(3). So you need something like this: use v5.10; # I really should switch to at least 5.16 if not 5.24 use strict; use warnings; use Fcntl qw(O_RDONLY O_DIRECTORY LOCK_EX); my $dirname = "/tmp/to-be-locked"; sysopen(my $handle, "/tmp/to-be-locked", O_RDONLY | O_DIRECTORY) or die "Could not open $dirname: $!\n"; flock($handle, LOCK_EX) or die "Could not lock $dirname: $!\n"; say "locked, it seems"; sleep(3600);' I only put the sleep() part so I could check using lsof that the directory was indeed locked. And yeah, the v5.10 part is a leftover from the days (...until a month or two ago...) when I still had to support stock CentOS 7 systems; I really should train my fingers to put 5.24 there. Hope that helps! G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com PGP key:https://www.ringlet.net/roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
Hi, Quoting Luca Boccassi (2024-05-28 01:54:08) > Thanks for the useful input, the following has been done: > > - existing installations pre-trixie will get an orphaned tmpfiles.d in > /etc/ that keeps the existing behaviour unchanged (no cleanup of > /var/tmp) > - openssh and tmux have been fixed to provide a tmpfiles.d exception > to retain their respective files > - the /tmp/ description in debian-installer has been updated to note > it is a tmpfs by default (via a commit in partman-basicfilesystems, > will upload if nobody gets around to it before Trixie's freeze) > - two paragraphs have been provided for the release notes ticket > - the changes are also noted in NEWS, with instructions on how to > override locally > - as mentioned, the latest upload to unstable makes /tmp/ a tmpfs by > default and for new installations 10+ days old files in /tmp/ and 30+ days > old files in /var/tmp/ are cleaned up daily thank you for having discussed this change on d-devel and for adding documentation to NEWS and release notes to announce this change. I also think it is sensible to roll this only out on new installations and to keep the behaviour on existing setups. Thank you for implementing that as well. That being said, maybe some Perl wizard knows how to do a flock on a directory in Perl? I tried this: use Fcntl qw(LOCK_EX); opendir(my $handle, ".") or die "opendir: $!"; flock($handle, LOCK_EX) or die "flock: $!"; And got this: flock() on unopened filehandle $handle at test.pl line 8. (Are you trying to call flock() on dirhandle $handle?) flock: Bad file descriptor at test.pl line 8. Wrapping $handle in fileno() doesn't make a difference either. Perl sources seem to indicate that directory handles are "evil_fh"? https://sources.debian.org/src/perl/5.38.2-4/util.c/?hl=3783#L3783 Thanks! cheers, josch signature.asc Description: signature
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On Wed, May 29, 2024 at 06:58:32PM +0200, Andreas Metzler wrote: > >> I think it is bad choice to deliberately have different behavior for > >> freshly installed and upgraded systems. Offering upgrades has always > >> been one of the major selling points of Debian, and imho this > >> implicitely includes that you do not get a worse or second class Debian > >> installation when you upgrade it than if you installed from scratch. > > > I strongly disagree: it is a bad choice to change on upgrades a default > > which may cause data loss. > > That is false dichotomy. data-loss will occur when people use /tmp or > /var/tmp for persistent data-storage because "This has (for a couple of > years) worked on Debian systems" not because "This has (for a couple of > years) worked on *this* *specific* Debian system.". Both perspectives are valid, and that is part of why this change is concerning to me. Transitioning the filesystem configuration of an existing system is inherently dangerous and can lead to data loss, as Marco points out. But leaving a system to diverge from the default Debian base configuration leads to configurtion drift that may trigger obscure bugs, untested configuration, difficult upgrades, etc. I'm not convinced the change is worth the risk. noah
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On 2024-05-29 Marco d'Itri wrote: > On May 28, Andreas Metzler wrote: >> I think it is bad choice to deliberately have different behavior for >> freshly installed and upgraded systems. Offering upgrades has always >> been one of the major selling points of Debian, and imho this >> implicitely includes that you do not get a worse or second class Debian >> installation when you upgrade it than if you installed from scratch. > I strongly disagree: it is a bad choice to change on upgrades a default > which may cause data loss. Hello, That is false dichotomy. data-loss will occur when people use /tmp or /var/tmp for persistent data-storage because "This has (for a couple of years) worked on Debian systems" not because "This has (for a couple of years) worked on *this* *specific* Debian system.". cu Andreas
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On May 28, Andreas Metzler wrote: > I think it is bad choice to deliberately have different behavior for > freshly installed and upgraded systems. Offering upgrades has always > been one of the major selling points of Debian, and imho this > implicitely includes that you do not get a worse or second class Debian > installation when you upgrade it than if you installed from scratch. I strongly disagree: it is a bad choice to change on upgrades a default which may cause data loss. -- ciao, Marco signature.asc Description: PGP signature
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On 2024-05-28 Luca Boccassi wrote: [...] > - existing installations pre-trixie will get an orphaned tmpfiles.d in > /etc/ that keeps the existing behaviour unchanged (no cleanup of > /var/tmp) [...] Hello, I think it is bad choice to deliberately have different behavior for freshly installed and upgraded systems. Offering upgrades has always been one of the major selling points of Debian, and imho this implicitely includes that you do not get a worse or second class Debian installation when you upgrade it than if you installed from scratch. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
> > what would break where, and how to fix it? I only found autopkgtest > so > > far, which uses /tmp/ in the guest and expects it to survive across > > reboots, and I have a MR up already for that. Anything else? > > Perhaps whatever makes these files in /tmp? i think something to do > with > X/gdm/gnome? > > /tmp/.X0-lock > /tmp/.X1024-lock > /tmp/.X1025-lock > > /tmp/.X11-unix > /tmp/.X1-lock > > /tmp/.XIM-unix > > /tmp/.font-unix > > /tmp/.ICE-unix These are all already covered by /usr/lib/tmpfiles.d/x11.conf -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
Luca Boccassi writes: > what would break where, and how to fix it? I only found autopkgtest so > far, which uses /tmp/ in the guest and expects it to survive across > reboots, and I have a MR up already for that. Anything else? Perhaps whatever makes these files in /tmp? i think something to do with X/gdm/gnome? /tmp/.X0-lock /tmp/.X1024-lock /tmp/.X1025-lock /tmp/.X11-unix /tmp/.X1-lock /tmp/.XIM-unix /tmp/.font-unix /tmp/.ICE-unix
Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
Sven Mueller writes: > Am 07.05.2024 22:56 schrieb Richard Lewis > : > > Luca Boccassi writes: > > > qwhat would > > break where, and how to fix it? > > Another one for you to investigate: I believe apt > source and 'apt-get > source' download and extract things into /tmp, as in > the mmdebootstap > example mentioned by someone else, this will create > "old" files that > could immediately be flagged for deletion causing > surprises. > > `apt download` and `apt source` download to your current > working directory. Same for apt-get. > > (People restoring from backups might also find this > an issue) > > I would not expect people to restore to /tmp and > expecting that restore to work across a reboot. Yes but this duscussion is about a change to make files disappear after 10 days despite no reboot.
Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
Luca Boccassi writes: > On Mon, 6 May 2024 at 15:42, Richard Lewis > wrote: >> >> Luca Boccassi writes: >> >> > Hence, I am not really looking for philosophical discussions or lists >> > of personal preferences or hypotheticals, but for facts: what would >> > break where, and how to fix it? >> >> cleaning /tmp or /var/tmp: users may lose files if they dont realise a >> directory tmp can be cleaned without a reboot. something in /var/tmp >> that's been in there for 35 days before an upgrade might be deleted >> before the user reads the NEWS.Debian email, meaning they have no >> chance to react). Maybe you could postpone the very first deletion >> until after the next reboot? >> >> using a tmpfs: is there a risk of losing unrelated data due to more >> frequent OOM killing random other programmes due to /tmp using all the >> memory? is there a case to only use a tmpfs if the system has >> "enough" memory? > > Again, those are all hypotheticals, and one can construct similarly > contrived thought exercises for most possible permutations of most > configurations, and the answer is always the same: customize the > configuration accordingly. Hence, not relevant right now. > What is relevant is: which packages, if any, or which DSA-owned > systems, if any, are actually affected and how? Why do you think that the impact on users is less important than the impact on debian packages?
Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
Luca Boccassi writes: > qwhat would > break where, and how to fix it? Another one for you to investigate: I believe apt source and 'apt-get source' download and extract things into /tmp, as in the mmdebootstap example mentioned by someone else, this will create "old" files that could immediately be flagged for deletion causing surprises. (People restoring from backups might also find this an issue)
Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
Luca Boccassi writes: > Hence, I am not really looking for philosophical discussions or lists > of personal preferences or hypotheticals, but for facts: what would > break where, and how to fix it? cleaning /tmp or /var/tmp: users may lose files if they dont realise a directory tmp can be cleaned without a reboot. something in /var/tmp that's been in there for 35 days before an upgrade might be deleted before the user reads the NEWS.Debian email, meaning they have no chance to react). Maybe you could postpone the very first deletion until after the next reboot? using a tmpfs: is there a risk of losing unrelated data due to more frequent OOM killing random other programmes due to /tmp using all the memory? is there a case to only use a tmpfs if the system has "enough" memory?
Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
Luca Boccassi writes: > Hence, I am not really looking for philosophical discussions or lists > of personal preferences or hypotheticals, but for facts: what would > break where, and how to fix it? - tmux stores sockets in /tmp/tmux-$UID - I think screen might use /tmp/screens I suppose if you detached for a long time you might find yourself unable to reattach. I think you can change the location of these.
Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On Tue, 7 May 2024 at 17:33, Sam Hartman wrote: > > > "Luca" == Luca Boccassi writes: > > Luca> On Mon, 6 May 2024 at 15:42, Richard Lewis > Luca> wrote: > >> > >> Luca Boccassi writes: > >> > >> > Hence, I am not really looking for philosophical discussions or > >> lists > of personal preferences or hypotheticals, but for facts: > >> what would > break where, and how to fix it? > > ssh-agent appears to default to creating a socket under /tmp. > I think respecting $XDG_RUNTIME_DIR would be better. > > /etc/X11/Xsession.d/90x11-common_ssh-agent also doesn't override where > the socket ends up. > I definitely think for session scripts like that $XDG_RUNTIME_DIR would > be better. > > > gnome-keyring's ssh-agent handles this better, although last time I > checked, it did not support pkcs11, so I could not use it with PIV > cards. > (Other parts of gnome-keyring do support pkcs11). The ssh agent provided by gnupg also behaves correctly and creates the socket in XDG_RUNTIME_DIR. I have filed a bug for openssh-client's ssh-agent.
Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
Am 07.05.2024 22:56 schrieb Richard Lewis :Luca Boccassi writes: > qwhat would > break where, and how to fix it? Another one for you to investigate: I believe apt source and 'apt-get source' download and extract things into /tmp, as in the mmdebootstap example mentioned by someone else, this will create "old" files that could immediately be flagged for deletion causing surprises.`apt download` and `apt source` download to your current working directory. Same for apt-get. (People restoring from backups might also find this an issue)I would not expect people to restore to /tmp and expecting that restore to work across a reboot. And to be honest, I find the expectation to have any guarantee on files in /tmp or /var/tmp across a reboot quite surprising. The directories are named "tmp" because they are meant as temporary storage, which implies automatic deleting at some point IMHO.Now, bad choices by various tools have been mentioned, so a cleaner for these directories that runs outside a reboot has to be careful anyhow. But during a reboot? I don't think that should be too much of a problem. Cheers, Sven
Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
> "Luca" == Luca Boccassi writes: Luca> On Mon, 6 May 2024 at 15:42, Richard Lewis Luca> wrote: >> >> Luca Boccassi writes: >> >> > Hence, I am not really looking for philosophical discussions or >> lists > of personal preferences or hypotheticals, but for facts: >> what would > break where, and how to fix it? ssh-agent appears to default to creating a socket under /tmp. I think respecting $XDG_RUNTIME_DIR would be better. /etc/X11/Xsession.d/90x11-common_ssh-agent also doesn't override where the socket ends up. I definitely think for session scripts like that $XDG_RUNTIME_DIR would be better. gnome-keyring's ssh-agent handles this better, although last time I checked, it did not support pkcs11, so I could not use it with PIV cards. (Other parts of gnome-keyring do support pkcs11).
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
The /tmp/ as tmpfs discussion is funny to me because while we've been kicking around the idea of whether or not to clean /tmp/, having /tmp/ as a tmpfs makes that whole argument moot. It all goes away at boot time! Problem solved! :D Honestly, I see this one as a much easier topic, assuming that no one is talking about changing existing systems. (I haven't seen anyone say that.) So for new systems, /tmp/ as a tmpfs strikes me as a legitimate option, and the partition layout is something that any good admin pays close attention to on any new system, particularly a new distribution or even distro version. (That is, even going from 12.1 to 12.2, I'm going to be on the lookout for changes in the installer.) Whether you want /tmp as a tmpfs is a decision that's going to be made at the same time as whether or not /home should be on a separate partition. The admin is going to do whatever makes the most sense for this system. To me, it's all about the display. I want to see what partition will be mounted as root, what partition will be mounted as /home, which will be swap (if any), and so on. But I don't need to see /proc and /sys. Those aren't optional. So if /tmp is not part of the root partition, it doesn't matter if it's a separate partition or a tmpfs. It should just appear in the screen that displays the filesystem layout, and then the admin can decide whether or not that's a good idea. I have no opinion on whether or not it should be the default. If /tmp/ as tmpfs becomes the default, I would probably only override that on certain low-memory systems that I run and just leave it on most others. I've seen it done before and it seemed to work fine in some cases and not in others. As long as it's somewhere that I can SEE it in the installer, I'd be happy. That's definitely a thing the admin can change later on with few consequences. Sent from my mobile device. From: Hakan Bayındır Sent: Tuesday, May 7, 2024 05:45 To: 966...@bugs.debian.org; debian-de...@lists.debian.org Cc: Carsten Leonhardt; Luca Boccassi; Peter Pentchev Subject: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default] Similarly, I’m following the thread for a couple of days now, and wondering about its implications. When I consider server scenarios, pushing /tmp to RAM looks highly undesirable from my perspective. All the servers I manage use their whole RAMs and using the unused space as a disk cache is far more desirable than a /tmp mount. When servers are virtualized, RAM is at premium, and a disk cache is way more usable rather than /tmp in the RAM. The other scenario I think is HPC, where applications use all the RAM available, squeezing the hardware dry. Again, /tmp in the RAM is very undesirable, because /tmp/$USER is also heavily used and an OOM situation creates a lose-lose situation where you either delete runtime files, or lose the executing job, which results in job failure in any case. On the other hand, I personally use my desktop computer as a development workstation and use tons of RAM either with software or with VMs. Again a /tmp in RAM is an inferior scenario to my current setup. The only useful state where /tmp is in RAM is single board computers where temp is both lightly utilized and maximizing SD/eMMC life is important. These systems even mount /var/log to a tmpfs and sync on boot/reboot/shutdown, reducing flash wear. Deleting /var/tmp has the same problems since long running tasks on the servers might need a file once in a month, but it can be crucial for functions of the software. I can’t see any scenario where these two are useful in typical or niche installations of Debian. FWIW, RedHat family doesn’t mount /tmp as a tmpfs on its default installation. Cheers, H.
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
Similarly, I’m following the thread for a couple of days now, and wondering about its implications. When I consider server scenarios, pushing /tmp to RAM looks highly undesirable from my perspective. All the servers I manage use their whole RAMs and using the unused space as a disk cache is far more desirable than a /tmp mount. When servers are virtualized, RAM is at premium, and a disk cache is way more usable rather than /tmp in the RAM. The other scenario I think is HPC, where applications use all the RAM available, squeezing the hardware dry. Again, /tmp in the RAM is very undesirable, because /tmp/$USER is also heavily used and an OOM situation creates a lose-lose situation where you either delete runtime files, or lose the executing job, which results in job failure in any case. On the other hand, I personally use my desktop computer as a development workstation and use tons of RAM either with software or with VMs. Again a /tmp in RAM is an inferior scenario to my current setup. The only useful state where /tmp is in RAM is single board computers where temp is both lightly utilized and maximizing SD/eMMC life is important. These systems even mount /var/log to a tmpfs and sync on boot/reboot/shutdown, reducing flash wear. Deleting /var/tmp has the same problems since long running tasks on the servers might need a file once in a month, but it can be crucial for functions of the software. I can’t see any scenario where these two are useful in typical or niche installations of Debian. FWIW, RedHat family doesn’t mount /tmp as a tmpfs on its default installation. Cheers, H. > On 7 May 2024, at 12:42, Peter Pentchev wrote: > > On Tue, May 07, 2024 at 10:38:14AM +0200, Carsten Leonhardt wrote: >> Luca Boccassi writes: >> >>> Defaults are defaults, they are trivially and fully overridable where >>> needed if needed. Especially container and VM managers these days can >>> super trivially override them via SMBIOS Type11 strings or >>> Credentials, ephemerally and without changing the guest image at all. >> >> That argument goes both ways and I prefer safe defaults. What >> you/upstream propose are unsafe defaults, as was shown by several >> comments in this thread. Whoever wants the unsafe defaults of deleting >> old files and risking OOM situations can than "trivially and fully >> override" the safe defaults. > > So I've been wondering for a couple of days now, following this thread... > ...would it be a good idea to make this a debconf prompt, high priority, > default "yes", so that it is activated on new automatically installed > systems, but people who upgrade their current Debian installations can > choose to keep the old behavior? > > I do realize that more debconf prompts are not always desirable, and > such decisions must be taken on a case-by-case basis, so... yeah. > > G'luck, > Peter > > -- > Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com > PGP key:http://people.FreeBSD.org/~roam/roam.key.asc > Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On Tue, May 07, 2024 at 10:38:14AM +0200, Carsten Leonhardt wrote: > Luca Boccassi writes: > > > Defaults are defaults, they are trivially and fully overridable where > > needed if needed. Especially container and VM managers these days can > > super trivially override them via SMBIOS Type11 strings or > > Credentials, ephemerally and without changing the guest image at all. > > That argument goes both ways and I prefer safe defaults. What > you/upstream propose are unsafe defaults, as was shown by several > comments in this thread. Whoever wants the unsafe defaults of deleting > old files and risking OOM situations can than "trivially and fully > override" the safe defaults. So I've been wondering for a couple of days now, following this thread... ...would it be a good idea to make this a debconf prompt, high priority, default "yes", so that it is activated on new automatically installed systems, but people who upgrade their current Debian installations can choose to keep the old behavior? I do realize that more debconf prompts are not always desirable, and such decisions must be taken on a case-by-case basis, so... yeah. G'luck, Peter -- Peter Pentchev r...@ringlet.net r...@debian.org pe...@morpheusly.com PGP key:http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13 signature.asc Description: PGP signature
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
Luca Boccassi writes: > Defaults are defaults, they are trivially and fully overridable where > needed if needed. Especially container and VM managers these days can > super trivially override them via SMBIOS Type11 strings or > Credentials, ephemerally and without changing the guest image at all. That argument goes both ways and I prefer safe defaults. What you/upstream propose are unsafe defaults, as was shown by several comments in this thread. Whoever wants the unsafe defaults of deleting old files and risking OOM situations can than "trivially and fully override" the safe defaults.
Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On Mon, 6 May 2024 at 23:03, Richard Lewis wrote: > > Luca Boccassi writes: > > > Hence, I am not really looking for philosophical discussions or lists > > of personal preferences or hypotheticals, but for facts: what would > > break where, and how to fix it? > > - tmux stores sockets in /tmp/tmux-$UID > - I think screen might use /tmp/screens > > I suppose if you detached for a long time you might find yourself unable > to reattach. > > I think you can change the location of these. And those are useful only as long as screen/tmux are still running, right (I don't really use either that much)? If so, a flock is the right solution for these
Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On Mon, 6 May 2024 at 15:42, Richard Lewis wrote: > > Luca Boccassi writes: > > > Hence, I am not really looking for philosophical discussions or lists > > of personal preferences or hypotheticals, but for facts: what would > > break where, and how to fix it? > > cleaning /tmp or /var/tmp: users may lose files if they dont realise a > directory tmp can be cleaned without a reboot. something in /var/tmp > that's been in there for 35 days before an upgrade might be deleted > before the user reads the NEWS.Debian email, meaning they have no > chance to react). Maybe you could postpone the very first deletion > until after the next reboot? > > using a tmpfs: is there a risk of losing unrelated data due to more > frequent OOM killing random other programmes due to /tmp using all the > memory? is there a case to only use a tmpfs if the system has > "enough" memory? Again, those are all hypotheticals, and one can construct similarly contrived thought exercises for most possible permutations of most configurations, and the answer is always the same: customize the configuration accordingly. Hence, not relevant right now. What is relevant is: which packages, if any, or which DSA-owned systems, if any, are actually affected and how?
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On Mon, 6 May 2024 at 11:48, Michael Biebl wrote: > > Am 06.05.24 um 12:18 schrieb Luca Boccassi: > > Defaults are defaults, they are trivially and fully overridable where > > needed if needed. Especially container and VM managers these days can > > super trivially override them via SMBIOS Type11 strings or > > Credentials, ephemerally and without changing the guest image at all. > > > Aligning defaults across distros does have value. > That said, a distro like Debian has a larger scope than say a desktop > oriented one like Fedora. > Debian is used on a broad spectrum of systems: from embedded to server > to cloud to desktop. > So I think it is valuable to gather feedback from all affected parties > to make an informed decision. > > What upstream is doing should not be the only driving factor. It's impossible to have defaults that make everyone happy, there will always be someone who doesn't like any choice one might pick (there are people unhappy with the current ones too). Hence, I am not really looking for philosophical discussions or lists of personal preferences or hypotheticals, but for facts: what would break where, and how to fix it? I only found autopkgtest so far, which uses /tmp/ in the guest and expects it to survive across reboots, and I have a MR up already for that. Anything else?
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
Am 06.05.24 um 12:18 schrieb Luca Boccassi: Defaults are defaults, they are trivially and fully overridable where needed if needed. Especially container and VM managers these days can super trivially override them via SMBIOS Type11 strings or Credentials, ephemerally and without changing the guest image at all. Aligning defaults across distros does have value. That said, a distro like Debian has a larger scope than say a desktop oriented one like Fedora. Debian is used on a broad spectrum of systems: from embedded to server to cloud to desktop. So I think it is valuable to gather feedback from all affected parties to make an informed decision. What upstream is doing should not be the only driving factor. Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On Mon, 6 May 2024 at 09:40, Michael Biebl wrote: > > We have two separate issues here: > > a/ /tmp-on-tmpfs > b/ time based clean-up of /tmp and /var/tmp > > I think it makes sense to discuss/handle those separately. > > Regarding a/: > tmp.mount as shipped by systemd uses the following mount options: > "mode=1777,strictatime,nosuid,nodev,size=50%" > > In the past there were concerns that those 50% of available RAM wasn't a > one-size-fits-all solution, especially for (LXC) containers and VMs > > One also needs to keep in mind that debian-installer still offers a > partitioning setup with /tmp on a separate partition. This will be > created via an entry in /etc/fstab. Such a /tmp entry in /etc/fstab will > override tmp.mount. > > If we go with a/, then I think d-i should be updated to no longer create > /tmp as a separate partition. > > > Regarding b/: > The current setup as used in Debian is to only clean /tmp on boot (which > is pointless with /tmp-on-tmpfs) and never clean up /var/tmp > > The tmpfiles rule tmp.conf as shipped by systemd upstream contains: > > q /tmp 1777 root root 10d > q /var/tmp 1777 root root 30d > > Files that are older then 10 days or 30 days are automatically cleaned > up. The age of the files are determined as such: > > "The age of a file system entry is determined from its last modification > timestamp (mtime), its last access timestamp (atime), and (except for > directories) its last status change timestamp (ctime). By default, any > of these three (or two) values will prevent cleanup if it is more recent > than the current time minus the age field." > > I'm not sure if we have software on long running servers which place > files in /tmp and /var/tmp and expect files to not be deleted during > runtime, even if not accessed for a long time. This is certainly an > issue to be aware of and keep an eye on. Defaults are defaults, they are trivially and fully overridable where needed if needed. Especially container and VM managers these days can super trivially override them via SMBIOS Type11 strings or Credentials, ephemerally and without changing the guest image at all.
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On Mon, 6 May 2024 at 06:36, Paul Gevers wrote: > > Hi Luca, > > On 05-05-2024 10:04 p.m., Luca Boccassi wrote: > > > Hence, I intend to apply these changes in the next src:systemd upload > > to unstable, probably next week. > > > In case anybody is aware of packages/programs needing an update to cope > > with these changes, or any other issue, please let me know and I will > > file bugs. > > You filed MR341 against autopkgtest, thanks for that. Can you please > hold off a bit longer than only one week to get the infrastructure > updated? I'm confident that every test that has the needs-reboot > restriction will start failing (which are only 21 tests according to > codesearch). However, I fear that every test is at risk under common > circumstances. > > I don't want to be rushed into an autopkgtest update and an > infrastructure update for something that we can plan (there's always > risk involved and I want to have the time and peace to cope with the > process). Having said that, maybe we will be ready next week. Sure, no problem. That MR fixes autopkgtest for my local runs, let me know if something else is needed.
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
Am 05.05.24 um 22:04 schrieb Luca Boccassi: This will be mentioned in NEWS (and I guess in the release notes when the time comes), together with the instructions to override for anybody wanting to keep the old behaviour, which is as trivial as: .. touch /etc/tmpfiles.d/tmp.conf This doesn't restore the old/current behaviour, which is to cleanup /tmp on boot. For that you would need something like echo "D /tmp 1777 root root -" > /etc/tmpfiles.d/tmp.conf OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
clone 966621 -1 reassign -1 release-notes thanks On Mon, May 06, 2024 at 10:40:00AM +0200, Michael Biebl wrote: > We have two separate issues here: > > a/ /tmp-on-tmpfs > b/ time based clean-up of /tmp and /var/tmp > > I think it makes sense to discuss/handle those separately. very much agreed. a.) is mostly "just" a /tmp size issue but b.) can introduce interesting unforseen breakages for long running stuff. -- cheers, Holger ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄ “I'll tell you what freedom is to me No fear.” (Nina Simone) signature.asc Description: PGP signature
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
We have two separate issues here: a/ /tmp-on-tmpfs b/ time based clean-up of /tmp and /var/tmp I think it makes sense to discuss/handle those separately. Regarding a/: tmp.mount as shipped by systemd uses the following mount options: "mode=1777,strictatime,nosuid,nodev,size=50%" In the past there were concerns that those 50% of available RAM wasn't a one-size-fits-all solution, especially for (LXC) containers and VMs One also needs to keep in mind that debian-installer still offers a partitioning setup with /tmp on a separate partition. This will be created via an entry in /etc/fstab. Such a /tmp entry in /etc/fstab will override tmp.mount. If we go with a/, then I think d-i should be updated to no longer create /tmp as a separate partition. Regarding b/: The current setup as used in Debian is to only clean /tmp on boot (which is pointless with /tmp-on-tmpfs) and never clean up /var/tmp The tmpfiles rule tmp.conf as shipped by systemd upstream contains: q /tmp 1777 root root 10d q /var/tmp 1777 root root 30d Files that are older then 10 days or 30 days are automatically cleaned up. The age of the files are determined as such: "The age of a file system entry is determined from its last modification timestamp (mtime), its last access timestamp (atime), and (except for directories) its last status change timestamp (ctime). By default, any of these three (or two) values will prevent cleanup if it is more recent than the current time minus the age field." I'm not sure if we have software on long running servers which place files in /tmp and /var/tmp and expect files to not be deleted during runtime, even if not accessed for a long time. This is certainly an issue to be aware of and keep an eye on. Michael OpenPGP_signature.asc Description: OpenPGP digital signature
Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
Luca Boccassi writes: > we should bring the > defaults in line with upstream and other distributions This is not an argument. Why can't "upstream and other distributions" be in line with Debian? That would obviously be the sane thing for then to strive for on most technical subjects. Please state the *technical* reasons justifyin your proposed changes. It's fine with me if you copy those reasons from " upstream and other distributions". If there are any. It's so vague that I, as a Debian user, don't even know which distributions you are talking about. > - /var/tmp/ is cleaned up on a timer IMHO this is crazy. Please don't do that. It is a completely unexpected policy change with exactly no upside AFAICS. The downside is obvious: Users will lose temporary data they expected to be persistent. I predict that this will haunt us for years, like all the other major policy changes which was forced upon us lately with the "upstream and other distributions" arguments. For heavens sake, you're still struggling with the fallout of the /usr merge! How many years is that now? But "upstream and other distributions" did it, so therefore Debian had to as well? Bjørn
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
Hi Luca, On 05-05-2024 10:04 p.m., Luca Boccassi wrote: > Hence, I intend to apply these changes in the next src:systemd upload > to unstable, probably next week. In case anybody is aware of packages/programs needing an update to cope with these changes, or any other issue, please let me know and I will file bugs. You filed MR341 against autopkgtest, thanks for that. Can you please hold off a bit longer than only one week to get the infrastructure updated? I'm confident that every test that has the needs-reboot restriction will start failing (which are only 21 tests according to codesearch). However, I fear that every test is at risk under common circumstances. I don't want to be rushed into an autopkgtest update and an infrastructure update for something that we can plan (there's always risk involved and I want to have the time and peace to cope with the process). Having said that, maybe we will be ready next week. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On Sun, 5 May 2024 at 22:22, Salvo Tomaselli wrote: > > > In case anybody is aware of packages/programs needing an update to cope > > with these changes, or any other issue, please let me know and I will > > file bugs. > > in localslackirc@.service > > ReadWritePaths=/var/tmp > > It uses /var/tmp because it needs a directory with 1777 permissions that is > permanent, to keep some status. > > The user it ends up using is configured by a seting, and is intended to be a > non-system user (and could be different users for the various instances). > > I guess the solution would be to create such a directory when installing, in / > var/lib/localslackirc instead of using /var/tmp and have the purge script > remove it. Services can use StateDirectory= and StateDirectoryMode= which should provide the same functionality, and is more appropriate for persistent state. /tmp/ and /var/tmp/ are meant to be scratch areas, rather than state storage.
Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]
On Tue, 5 Jul 2022 19:42:37 +0200 Michael Biebl wrote: > > Hi Eric > > On Fri, 31 Jul 2020 15:12:48 + Eric Desrochers > wrote: > > Package: systemd > > Version: 245.7-1 > > Severity: normal > > > > Dear Maintainer, > > > > Debian systemd implementation does not clean > > /var/tmp by default. > > > > * quilt patch: > > d/p/debian/Bring-tmpfiles.d-tmp.conf-in-line-with-Debian- defaul.patch > > > > * systemd-245.7/tmpfiles.d/tmp.conf: > > #q /var/tmp 1777 root root 30d > > > > The patch exist in Debian since 2012. > > > > The topic has been discussed and a few suggestion has been put on the > > table in the following Ubuntu bug: https://launchpad.net/bugs/1870585 > > > > I fill this bug today to start a conversation. > > I haven't received any further input from your side. > Are you still interested in this issue or not? > I wonder where to go from here and what to do about this bug report. I think it's been long enough, and for Trixie we should bring the defaults in line with upstream and other distributions, which means: - /tmp/ is a tmpfs - /var/tmp/ is cleaned up on a timer Hence, I intend to apply these changes in the next src:systemd upload to unstable, probably next week. This will be mentioned in NEWS (and I guess in the release notes when the time comes), together with the instructions to override for anybody wanting to keep the old behaviour, which is as trivial as: systemctl mask tmp.mount (or touch /etc/systemd/system/tmp.mount) touch /etc/tmpfiles.d/tmp.conf for the former and the latter respectively. In case anybody is aware of packages/programs needing an update to cope with these changes, or any other issue, please let me know and I will file bugs. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
