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
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.
Am 06.05.24 um 12:35 schrieb Simon Richter:
Hi,
On 5/6/24 17:40, Michael Biebl wrote:
If we go with a/, then I think d-i should be updated to no longer
create /tmp as a separate partition.
I think if the admin explicitly configures tmpfs as a separate file
system, then that should be honored -- if there is memory pressure, tmpfs+swap is pretty much the worst file system there is.
If you explicitly configure /tmp via /etc/fstab it will override the
default tmp.mount that is shipped by systemd.
My point is a different one: If we enable /tmp-on-tmpfs by default, then offering a partition layout in d-i that places /tmp as a physical
partition is confusing/inconsistent imho.
Am 06.05.24 um 12:35 schrieb Simon Richter:
Hi,
On 5/6/24 17:40, Michael Biebl wrote:
If we go with a/, then I think d-i should be updated to no longer
create /tmp as a separate partition.
I think if the admin explicitly configures tmpfs as a separate file
system, then that should be honored -- if there is memory pressure, tmpfs+swap is pretty much the worst file system there is.
If you explicitly configure /tmp via /etc/fstab it will override the default tmp.mount that is shipped by systemd.
My point is a different one: If we enable /tmp-on-tmpfs by default, then offering a partition layout in d-i that places /tmp as a physical partition is confusing/inconsistent imho.
I'm not sure if we have software on long running servers which place filesNote that FHS mandates it for /var/tmp: "Files and directories located in /var/tmp must not be deleted when the system is booted. Although data
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.
On Mon, May 06, 2024 at 10:40:00AM +0200, Michael Biebl wrote:
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.
Note that FHS mandates it for /var/tmp: "Files and directories located
in /var/tmp must not be deleted when the system is booted. Although data stored in /var/tmp is typically deleted in a site-specific manner, it is recommended that deletions occur at a less frequent interval than /tmp."
Ah, I've read that as "while the system is booted".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.
Note that FHS mandates it for /var/tmp: "Files and directories located
in /var/tmp must not be deleted when the system is booted. Although data stored in /var/tmp is typically deleted in a site-specific manner, it is recommended that deletions occur at a less frequent interval than /tmp."
It mandates that it not be cleaned on *boot*. Not that it never be
cleaned during runtime.
Is that the default layout, or a selectable option?
If the latter, to me it makes sense to keep it, maybe with updated
wording. Making things customizable is not really an issue, as long as
it's clear what happens where.
Afaik, /var/tmp has never been cleaned up on /boot.
So I'm not sure what you mean with "no longer"?
On Mon, 6 May 2024 at 16:30, Simon Richter <sjr@debian.org> wrote:
Hi,
On 5/6/24 20:19, Luca Boccassi wrote:
Is that the default layout, or a selectable option?
When you create a partition manually, it asks for the mount point, and makes a number of suggestions in a dropdown, and /tmp is one of these.
There is also a "enter manually" option.
If the latter, to me it makes sense to keep it, maybe with updated wording. Making things customizable is not really an issue, as long as it's clear what happens where.
The only wording there is "/tmp - Temporary files" or something like
that (has been a while since I saw that particular menu) -- it's an
option in a menu, so space is limited.
FWIW, I don't see much of a use case for leaving /tmp on the root partition, so if no /tmp mount point is configured, mounting a tmpfs is
a good choice. Basically anything that can boot the installer has enough RAM.
Found it:
https://salsa.debian.org/installer-team/partman-basicfilesystems/-/blob/mast er/debian/partman-basicfilesystems.templates?ref_type=heads#L97
So unless someone has a better suggestion, I can change it from:
"/tmp - temporary files"
To something like:
"/tmp - temporary files (default: tmpfs)"
On a fresh installed fedora system I downloaded a .iso in /tmp, then the OOMkiller killed wayland, so everything died.
If you know you won't ever fill it up, I guess it's fine. But I'd go for the safer (and sadly slower) option.
Consider a long running task, which will take days or weeks (which is
the norm in simulation and science domains in general). System emitted a warning after three days, that it'll delete my files in three days. My
job won't be finished, and I'll be losing three days of work unless I
catch that warning.
On the other hand, if we need to change the configuration 99% of the time,[citation needed]
Consider a long running task, which will take days or weeks (which is the norm in simulation and science domains in general). System emitted a warning after three days, that it'll delete my files in three days. My job won't be finished, and I'll be losing three days of work unless I catch that warning.
Dear Russ,
If you are running a long-running task that produces data that you
care about, make a directory for it to use, whether in your home
directory, /opt, /srv, whatever.
Sorry but, clusters, batch systems and other automated systems doesn't
work that way.
That's not an extension of the home directory in any way. After users
submit their jobs to the cluster, they neither have access to the
execution node, nor they can pick and choose where to put their files.
These files may stay there up to a couple of weeks, and deleting
everything periodically will probably corrupt the jobs of these users somehow.
The applications users use create these temporary files without users' knowledge. They work in their own directories, but applications create another job dependent state files in both /tmp and /var/tmp. These are different programs and I assure you they’re not created there because
user (or we) configured something. These files live there during the
lifetime of the job, and cleaned afterwards by the application.
On 7 May 2024, at 18:39, Holger Levsen <holger@layer-acht.org> wrote:Me is figurative here. Neither me, nor my code nor our users abuse these folders. The applications they use create these files without users’ knowledge.
On Tue, May 07, 2024 at 04:24:06PM +0300, Hakan Bayındır wrote:
Consider a long running task, which will take days or weeks (which is the
norm in simulation and science domains in general). System emitted a warning >> after three days, that it'll delete my files in three days. My job won't be >> finished, and I'll be losing three days of work unless I catch that warning.
Then it will be high time you learn not to abuse /tmp that way and
work in your (or your services) home/data directory.
Problem easily avoided. plus you don't need to make /tmp 20 TB because you have lots of data. ;)
I'm a bit surprised how many people seem to really rely on data in /tmp
to survive for weeks or even months. I wonder if they backup /tmp?
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org ⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C ⠈⠳⣄
"When one man dies it's a tragedy. When thousands die it's statistics." (Stalin commenting the worlds reaction on Covid 19.)
On Tue, May 07, 2024 at 04:24:06PM +0300, Hakan Bayındır wrote:
Consider a long running task, which will take days or weeks (which is the norm in simulation and science domains in general). System emitted a warningThen it will be high time you learn not to abuse /tmp that way and work in your (or your services) home/data directory.
after three days, that it'll delete my files in three days. My job won't be finished, and I'll be losing three days of work unless I catch that warning.
Problem easily avoided. plus you don't need to make /tmp 20 TB because you have lots of data. ;)
I'm a bit surprised how many people seem to really rely on data in /tmp to survive for weeks or even months. I wonder if they backup /tmp?
I'm a bit surprised how many people seem to really rely on data in /tmp
to survive for weeks or even months. I wonder if they backup /tmp?
btw, i'm not trying to argue against the change, but i dont yet
understand the rationale (which id like to be put into the
release-notes): is there perhaps something more compelling than "other distributions and upstream already do this"?
I'm a bit surprised how many people seem to really rely on data in /tmp
to survive for weeks or even months. I wonder if they backup /tmp?
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
It sounds like that is what kicked off this discussion, but moving /tmp to tmpfs also usually makes programs that use /tmp run faster. I believe
that was the original motivation for tmpfs back in the day.
For /var/tmp, I think the primary motivation to garbage-collect those
files is that filling up /var/tmp is often quite bad for the system. It's frequently not on its own partition, but is shared with at least /var, and filling up /var can be very bad. It can result in bounced mail, unstable services, and other serious problems.
On 5/8/24 07:05, Russ Allbery wrote:
It sounds like that is what kicked off this discussion, but moving /tmp
to tmpfs also usually makes programs that use /tmp run faster. I
believe that was the original motivation for tmpfs back in the day.
IIRC it started out as an implementation of POSIX SHM, and was later generalized.
When /var runs full, the problem is probably initrd building.
Taking a quick look around all my machines, the accumulated cruft in
/var/tmp is on the order of kilobytes -- mostly reportbug files, and a
few from audacity -- and these machines have not been reinstalled in the
last ten years.
Holger Levsen <holger@layer-acht.org> writes:
I'm a bit surprised how many people seem to really rely on data in /tmp
to survive for weeks or even months. I wonder if they backup /tmp?
I use /tmp for things that fall somewhere between "needs a backup" and >"unimportant, can be deleted whenever".
I understand your point, which is that this pattern is out there in the
wild and Debian is in danger of breaking existing usage patterns by
matching the defaults of other distributions. This is a valid point, and
I appreciate you making it.
On Mon, 6 May 2024 at 16:51, Barak A. Pearlmutter <barak@cs.nuim.ie>
wrote:
For whatever reason, a lot of people who process large data use /var/tmp/FOO/ as a place to store information that should not be
backed up, but also should not just disappear.
Then such people, assuming they actually exist, can configure their
custom systems accordingly upon reading the release notes before
upgrading, as they would do anyway if installing on CentOS or any
other major OS. Hence, not an issue either.
I'd like to hear some arguments *in favour* of making this change.
Alignment with systemd-upstream, reduced package maintenance burden
are two that I can think of, but perhaps I've missed more. These two,
IMHO, are significantly outweighed by the risks.
I'd like to hear some arguments *in favour* of making this change. Alignment with systemd-upstream, reduced package maintenance burdenLet me see if I understand the arguments being made in favor.
are two that I can think of, but perhaps I've missed more. These two,
IMHO, are significantly outweighed by the risks.
1. Compatibility with upstream. This means all the upstream logic is sort of
imported by reference, so the below is mainly the upstream logic, as I
understand it.
2. Defend the system against buggy programs that leave debris in /var/tmp/,
and against debris left there when programs are terminated prematurely.
These are programs which use /var/tmp/ internally, but not as part of
their API, so the user would have no particular way of knowing that they
are leaving things there, would have no particular reason to check for and
delete such files, and might not be able to easily recognize which files
should be removed.
I looked at the upstream bug report https://github.com/systemd/systemd/issues/32674 which suggests that deletion of directory trees in /var/tmp/ be atomic, and trigger only when everything in the tree meets criteria for deletion. I added a comment suggesting that the policy be tweaked in two ways. (a) Use system-up time rather than wall-clock time for measuring file age, to address the "suspending or shutting down for over 30 days breaks running data processing scripts that uses /var/tmp/ for intermediate files" issue. I sort of have an invariant in my head, which is that suspending the computer doesn't break things, and also the whole point of /var/tmp/ is that files there are preserved across boots. And (b) check if a file is open by some process, the same way fuser(1) does, and if so, don't delete it. Could also preserve directories which are the current directory of some process, if you want to be even more user friendly.
The only response I got was "don't use temporary directories for things that you cannot afford to lose and recreate", which I don't really understand. It's like saying "you should have good backups, so it's not a problem to just delete anything in /home older than two days". Bottom line, it's not clear to me that upstream has really thought this through with users in mind. I'd suggest that Debian may wish to tweak the defaults on this stuff pretty hard to be more user friendly.
- as discussed earlier, add /tmp/00-README and /var/tmp/00-README to explain this old-file-deletion policy
Historically, deleting anything in /var/tmp that hadn't been accessed in
over seven days was a perfectly reasonable and typical configuration.
These days, we have the complication that it's fairly common to turn off atime updates for performance reasons, which makes it a bit harder to implement that policy when /var/tmp isn't its own partition and thus
inherits that setting from the rest of the system.
On Mon, May 06, 2024 at 07:42:11AM -0700, Russ Allbery wrote:
Historically, deleting anything in /var/tmp that hadn't been accessed
in over seven days was a perfectly reasonable and typical
configuration. These days, we have the complication that it's fairly
common to turn off atime updates for performance reasons, which makes
it a bit harder to implement that policy when /var/tmp isn't its own
partition and thus inherits that setting from the rest of the system.
Apologies for being a bit late to this, but is this true? relatime-type setups will still update atime if the time between the previous update
and the access is larger than some threshold, so you lose some degree of granularity but the rough policy should still apply.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 339 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 00:17:01 |
| Calls: | 7,466 |
| Calls today: | 2 |
| Files: | 12,691 |
| Messages: | 5,627,864 |
