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-wo
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
> On 30 May 2024, at 09:15, Marc Haber wrote:
>
> On Wed, 29 May 2024 14:35:27 +0300, Hakan Bay?nd?r
> wrote:
>> I'll kindly disagree here. I'd rather not have to go back to every
>> system and make sure that they all behave the way I want after doing a
>> periodic, completely boring "apt-g
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 keep
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 fixe
On Wed, 29 May 2024 14:35:27 +0300, Hakan Bay?nd?r
wrote:
>I'll kindly disagree here. I'd rather not have to go back to every
>system and make sure that they all behave the way I want after doing a
>periodic, completely boring "apt-get upgrade".
This change is likely to come to the majority of
> On 29 May 2024, at 17:33, Marvin Renich wrote:
>
> * Hakan Bayındır [240529 07:51]:
>> On 28.05.2024 ÖS 8:16, Andreas Metzler wrote:
>>> On 2024-05-28 Luca Boccassi
>>> wrote:
>>> [...]
- existing installations pre-trixie will get an orphaned tmpfiles.d in
/etc/ that keeps the e
On Wed, 2024-05-29 at 18:58 +0200, Andreas Metzler wrote:
> 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
> yea
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 in
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 in
* Hakan Bayındır [240529 07:51]:
> On 28.05.2024 ÖS 8:16, Andreas Metzler wrote:
> > 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
On 28.05.2024 ÖS 8:16, Andreas Metzler wrote:
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 ha
On Wed, 29 May 2024 at 08:18, Marc Haber wrote:
>
> On Wed, 29 May 2024 00:44:29 +0200, 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
> >
On Wed, 29 May 2024 00:44:29 +0200, 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 th
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 sec
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 an
Matthew Garrett writes:
> 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
>>
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
On Sun, 5 May 2024 at 21:04, Luca Boccassi wrote:
>
> 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,
>
> > 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/g
In days of yore (Wed, 15 May 2024), Sirius thus quoth:
> Thank you. I will update later with results for kernel 6.9.0 and Xen
> 4.18.2, how they work together.
Quick feedback: it works, although I am seeing some weird log-spewing when
I run things like aptitude and apt-get search. I will persist,
In days of yore (Wed, 15 May 2024), Simon Richter thus quoth:
> Hi,
Hello Simon,
> On 5/15/24 10:31, Sirius wrote:
>
> >Where is the systemd-dev package for regular Bookworm? The only package
> >that show up is systemd-dev/stable-backports 254.5-1~bpo12+3 all and if
> >I try and ins
Hi,
On 5/15/24 10:31, Sirius wrote:
Where is the systemd-dev package for regular Bookworm? The only package
that show up is systemd-dev/stable-backports 254.5-1~bpo12+3 all and if
I try and install that, it seems like it wants to uninstall most of my
system in the process.
The ver
Am 13.05.24 um 11:42 schrieb Johannes Schauer Marin Rodrigues:
If we want to try and weigh cost against benefit, do the benefits really
outweigh the cost? How costly is it to carry a patch in Debian and deviate from
upstream versus all the problems that participants of this thread now listed?
My
Unless somebody's already put it there, I'm going to move these
suggestions to a wishlist bug against systemd. Not sure if it should
be one bug or a few, one for each suggestion.
Currently discussion about reaping /var/tmp/ is in
https://bugs.debian.org/966621 and
https://bugs.launchpad.net/ubuntu
Hi,
Quoting Barak A. Pearlmutter (2024-05-13 10:47:43)
> > 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 significantl
> 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.
Let me see if I understand the argum
Le Mon, May 06, 2024 at 11:15:35AM +0100, Barak A. Pearlmutter a écrit :
> > We have two separate issues here:
>
> > a/ /tmp-on-tmpfs
Note that /tmp-on-tmpfs and cleanup-tmp-at-boot are not equivalent.
With cleanup-tmp-at-boot, if your system crashes, you can still backup
/tmp before rebooting.
Le mar. 7 mai 2024, 20:18, a écrit :
> Even after a reboot, I would be upset to lose the debug files that I've
> been accumulating for several days while trying to track down an
> intermittent problem with this stupid VPN...
>
At reboot, /tmp isautomatically flushed. It's the default behaviour
"Jonathan Dowland" writes:
> Else-thread, Russ begs people to stop doing this. I agree people
> shouldn't! We should also work on education and promotion of the
> alternatives.
Also, helping people use better tools for managing workloads like this
that make their lives easier and have better sem
On Mon May 6, 2024 at 5:01 PM BST, Luca Boccassi wrote:
> On Mon, 6 May 2024 at 16:51, Barak A. Pearlmutter
> 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 disa
Hi,
On 2024-05-07 09:43, Russ Allbery wrote:
> 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.
Th
On Tue, 07 May 2024 22:29:30 +0100, Richard Lewis
wrote:
>Holger Levsen 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" an
Simon Richter writes:
> 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 ou
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
>
Hi,
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 PO
On Tue, 7 May 2024 at 22:57, Russ Allbery wrote:
>
> Richard Lewis writes:
> > Luca Boccassi writes:
>
> >> what 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 mmdeboot
Richard Lewis writes:
> 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"?
It sounds like that is what
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, t
Richard Lewis writes:
> Luca Boccassi writes:
>> what 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"
Holger Levsen 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 think all of the i
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
On Tue, May 07, 2024 at 09:49:17PM +0200, Johannes Schauer Marin Rodrigues
wrote:
> Quoting Andrey Rakhmatullin (2024-05-06 19:14:40)
> > On Mon, May 06, 2024 at 04:50:50PM +0100, Barak A. Pearlmutter wrote:
> > > > tmpfiles.d snippets can be defined to cleanup on a timer _anything_,
> > >
> > >
Quoting Andrey Rakhmatullin (2024-05-06 19:14:40)
> On Mon, May 06, 2024 at 04:50:50PM +0100, Barak A. Pearlmutter wrote:
> > > tmpfiles.d snippets can be defined to cleanup on a timer _anything_,
> >
> > It's a question of what the *default* behaviour should be.
> >
> > For whatever reason, a lo
Hi,
Quoting Holger Levsen (2024-05-07 17:22:48)
> 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, tha
I guess sometimes when people discuss technical matters, good ideas pop up.
(Although I still think that its problematic interactions with lengthy
suspends makes the whole idea of auto-deletion based purely on
timestamps problematic. I can imagine more coherent mechanisms, which
doesn't count time
Barak A. Pearlmutter wrote:
> You know, that's a pretty good idea!
>
> Put a 00README-TMP.txt in /tmp/ and /var/tmp/ which briefly states the
> default deletion policy, the policy in place if it's not the default,
> and a pointer to info about altering it. "/tmp's contents are deleted
> at boot whi
.debian.org
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]
Then it will be high time you learn not to abuse /tmp that way
I'm a bit surprised how many people seem to really rely on data in /tmp
Early in this meta-thread it was suggested to separate /tmp-is-tmpfs
from cleanup-of-{,/var}/tmp. I am really surprised that nobody has
suggested the obvious separation of new installs from upgrades.
Changing the local configuration for either feature is trivial either
way. I think the proposed
Hakan Bayındır writes:
> 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 creat
> "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 fact
Sent from my iPhone
> On 7 May 2024, at 18:39, Holger Levsen wrote:
>
> 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
> On 7 May 2024, at 18:57, Russ Allbery wrote:
>
> Hakan Bayındır writes:
>> 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, cluster
Hakan Bayındır writes:
> 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 w
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
>
Dear Russ,
It's not *me* using /var/tmp for my own temporary files, it's the
applications other people use. I just logged in one of the nodes we have
and there were job-dependent files created by a particular, high end
scientific application (which is developed by another prominent
company).
On Tue, 7 May 2024 at 15:53, Sam Hartman wrote:
>
> > "Johannes" == Johannes Schauer Marin Rodrigues
> > writes:
> >> > > If [files can be deleted automatically while mmdebstrap is using
> them],
> >> > > how should applications guard against that from
> >> > > happening?
>
> "Johannes" == Johannes Schauer Marin Rodrigues writes:
>> > > If [files can be deleted automatically while mmdebstrap is using
them],
>> > > how should applications guard against that from
>> > > happening?
>> >
>> > As documented in tmpfiles.d(5), if mmdebstrap takes ou
On Tue, May 07, 2024 at 04:24:06PM +0300, Hakan Bayındır wrote:
> On the other hand, if we need to change the configuration 99% of the time,
[citation needed]
--
WBR, wRAR
signature.asc
Description: PGP signature
Hakan Bayındır writes:
> 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
> ...3) I would put a file in any auto-cleaned space named "1-AUTOCLEAN.txt"
> that contains some verbage explaining that things in this directory will be
> wiped based on rules set in (wherever).
You know, that's a pretty good idea!
Put a 00README-TMP.txt in /tmp/ and /var/tmp/ which briefly s
> 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
.debian.org; debian-devel@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
Maybe putting the cleanup task for /var/tmp on a longer timer and
warning users ahead of time of impending deletion (maybe 3 days before,
2 days, etc) would help with files of unsuspecting users getting
deleted. A log entry could also be emitted. I could see a gentle
warning on ssh login (minimal,
al with it than not be told at all.
Sent from my mobile device.
From: Alexandru Mihail
Sent: Tuesday, May 7, 2024 07:59
To: debian-devel@lists.debian.org
Subject: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default
[was: Re: systemd: tmpfiles.d no
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
echnical issue, this would be a much shorter
conversation. ;)
--J
Sent from my mobile device.
From: "Barak A. Pearlmutter"
Sent: Tuesday, May 7, 2024 07:18
To: r...@neoquasar.org
Cc: Luca Boccassi; debian-devel@lists.debian.org
Subject: Re: Re: Make /tmp/
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
On Tue, 07 May 2024 at 07:34:54 -0500, r...@neoquasar.org wrote:
> possibly convince those applications to use their own
> scratch space such as /tmp// that is more easily identifiable
This would be a denial of service at best, and a privilege escalation
vulnerability at worst. To be safe, it woul
Maybe putting the cleanup task for /var/tmp on a longer timer and warning users
ahead of time of impending deletion (maybe 3 days before, 2 days, etc) would
help with files of unsuspecting users getting deleted. A log entry could also
be emitted. I could see a gentle warning on ssh login (minima
This, in my opinion, is the correct view.
If the users/admins of a system are putting files somewhere, those are their
files and therefore their responsibility. It is not up to anyone else to claim
they know better and clean up after them.
If the files are abandoned by applications that don't
Rhys, I think you're being unfair. We have a *technical* disagreement
here. But our hearts are all in the same place: Luca, myself, and all
the other DDs discussing this, all want what's best for our users, we
all want to build the best OS possible, and are all discussing the
issue in good faith.
Luca Boccassi writes:
> On Mon, 6 May 2024 at 11:33, Barak A. Pearlmutter 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.
>>
>> Agreed.
>>
>> I also don't
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 stri
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
ent from my mobile device.
From: Luca Boccassi
Sent: Monday, May 6, 2024 08:20
To: Barak A. Pearlmutter
Cc: debian-devel@lists.debian.org
Subject: Re: Re: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default
[was: Re: systemd: tmpfiles.d not cleaning /var/t
Luca Boccassi writes:
> Richard Lewis wrote:
>> - 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 usefu
Hi,
Quoting Luca Boccassi (2024-05-07 00:09:51)
> To be more specific, as per documentation:
>
> https://www.freedesktop.org/software/systemd/man/latest/tmpfiles.d.html
>
> 'x' lines can be used to override cleanup rules, and support globbing,
> so something like:
>
> x /tmp/mmdebstrap.*
thank
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/tmu
On Mon, 6 May 2024 at 23:00, Johannes Schauer Marin Rodrigues
wrote:
>
> Quoting Luca Boccassi (2024-05-06 23:28:59)
> > On Mon, 6 May 2024 at 22:27, Simon McVittie wrote:
> > >
> > > On Mon, 06 May 2024 at 22:08:56 +0200, Johannes Schauer Marin Rodrigues
> > > wrote:
> > > > If [files can be de
Quoting Luca Boccassi (2024-05-06 23:28:59)
> On Mon, 6 May 2024 at 22:27, Simon McVittie wrote:
> >
> > On Mon, 06 May 2024 at 22:08:56 +0200, Johannes Schauer Marin Rodrigues
> > wrote:
> > > If [files can be deleted automatically while mmdebstrap is using them],
> > > how should applications g
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
On Mon, 6 May 2024 at 22:27, Simon McVittie wrote:
>
> On Mon, 06 May 2024 at 22:08:56 +0200, Johannes Schauer Marin Rodrigues wrote:
> > If [files can be deleted automatically while mmdebstrap is using them],
> > how should applications guard against that from
> > happening?
>
> As documented in
On Mon, 6 May 2024 at 21:08, Johannes Schauer Marin Rodrigues
wrote:
>
> Hi,
>
> Quoting Luca Boccassi (2024-05-06 15:20:08)
> > While personal anecdotes and stories can be interesting and amusing in many
> > circumstances, I am not really looking for those at this very moment. What I
> > am looki
On Mon, 06 May 2024 at 22:08:56 +0200, Johannes Schauer Marin Rodrigues wrote:
> If [files can be deleted automatically while mmdebstrap is using them],
> how should applications guard against that from
> happening?
As documented in tmpfiles.d(5), if mmdebstrap takes out an exclusive
flock(2) lock
On Mon, 6 May 2024 at 21:30, Salvo Tomaselli wrote:
>
> 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.
You
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?
>>
Hi,
Quoting Luca Boccassi (2024-05-06 15:20:08)
> While personal anecdotes and stories can be interesting and amusing in many
> circumstances, I am not really looking for those at this very moment. What I
> am looking for right now is packages or internal infrastructure that need an
> update to co
On Mon, May 06, 2024 at 04:50:50PM +0100, Barak A. Pearlmutter wrote:
> > tmpfiles.d snippets can be defined to cleanup on a timer _anything_,
>
> It's a question of what the *default* behaviour should be.
>
> For whatever reason, a lot of people who process large data use
> /var/tmp/FOO/ as a pl
On Mon, 6 May 2024 at 16:51, Barak A. Pearlmutter wrote:
>
> > tmpfiles.d snippets can be defined to cleanup on a timer _anything_,
>
> It's a question of what the *default* behaviour should be.
No, it is not, at least not for the strawman you conjured. So I gather
that git doesn't warn when clon
> tmpfiles.d snippets can be defined to cleanup on a timer _anything_,
It's a question of what the *default* behaviour should be.
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 di
On Mon, 6 May 2024 at 16:42, Simon Richter wrote:
>
> Hi,
>
> On 5/6/24 19:57, Michael Biebl wrote:
>
> > Afaik, /var/tmp has never been cleaned up on /boot.
> > So I'm not sure what you mean with "no longer"?
>
> Oof, you're right, it was /tmp, /var/run, /var/lock:
>
> [ "$VERBOSE" != no
On Mon, 6 May 2024 at 16:30, Simon Richter 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
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
Hi,
On 5/6/24 19:57, Michael Biebl wrote:
Afaik, /var/tmp has never been cleaned up on /boot.
So I'm not sure what you mean with "no longer"?
Oof, you're right, it was /tmp, /var/run, /var/lock:
[ "$VERBOSE" != no ] && echo -n "Cleaning"
[ -d /tmp ] && cleantmp
[ -d /
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 latt
On Mon, 6 May 2024 at 16:03, Barak A. Pearlmutter wrote:
>
> If it clones into /tmp the *entire* tree will either be reaped (upon
> reboot) or not.
>
> But having just some files deleted from a git dir or git working dir
> is much more dangerous, because various git commands can treat files
> dele
On Mon, May 06, 2024 at 07:42:11AM -0700, Russ Allbery 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
If it clones into /tmp the *entire* tree will either be reaped (upon
reboot) or not.
But having just some files deleted from a git dir or git working dir
is much more dangerous, because various git commands can treat files
deleted from the working tree as deliberate changes to be committed,
and fi
Andrey Rakhmatullin writes:
> 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 ce
1 - 100 of 1001 matches
Mail list logo
