Hi,
On 6/3/24 21:05, Colin Watson wrote:
From the d-i side we've generally preferred to have all the UI be part
of the installer (especially for translations etc.).
Makes sense, thanks!
Simon
On Mon, Jun 03, 2024 at 07:51:44PM +0900, Simon Richter wrote:
> On 6/3/24 15:33, Philipp Kern wrote:
>
> > > > * Package name : systemd-boot-installer
> > > Can this be merged into the normal systemd source package?
>
> > I feel like from a d-i perspect
Hi,
On 6/3/24 15:33, Philipp Kern wrote:
* Package name : systemd-boot-installer
Can this be merged into the normal systemd source package?
I feel like from a d-i perspective that'd be highly unusual? Having the
purely d-i-specific components be owned by d-i is the common setup.
On 03.06.24 05:43, Simon Richter wrote:
On 6/3/24 09:33, Luca Boccassi wrote:
* Package name : systemd-boot-installer
Can this be merged into the normal systemd source package?
I feel like from a d-i perspective that'd be highly unusual? Having the
purely d-i-specific componen
Hi,
On 6/3/24 09:33, Luca Boccassi wrote:
* Package name: systemd-boot-installer
Can this be merged into the normal systemd source package?
Simon
Package: wnpp
Severity: wishlist
Owner: Luca Boccassi
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: systemd-boot-installer
Version : 0.1
Upstream Author : Luca Boccassi
* URL :
https://salsa.debian.org/installer-team/systemd-boot-installer
* License
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/mmd
entOS 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 fou
servers. I don’t want to worry about uncontrolled configuration changes
happening on updates.
>
> People doing this responsibly read the release notes before beginning,
> and those release notes have in the past contained things that needed
> doing manually in the process such as the w
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
n the past contained things that needed
doing manually in the process such as the well-known "please upgrade
kernel first and reboot" during one udev/systemd upgrade.
Ubuntu seems to have put the release notes in an automatism disguise
called do-release-upgrade which probably changes from
> 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: 2
> > 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 an
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
Good morning/day/evening,
TL;DR version
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.
Roundabout
gut feeling is, that the cost of these hard to debug problems is far greater
than continuing to deviate from upstream and carry a Debian-specific patch, no?
Concerning the /var/tmp (and /tmp) cleaning, the Debian specific patch
is
https://salsa.debian.org/systemd-team/systemd/-/blob/debian
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.lau
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 mo
> 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 s
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
ata,
and everyone was doing this independently. (I've done a *lot* of this
kind of thing, once upon a time.)
But now we have mount namespaces, and systemd has PrivateTmp that builds
on top of that. So if the job is managed by an execution manager, it can
create per-job temporary directories
ee people
shouldn't! We should also work on education and promotion of the
alternatives.
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,
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
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)
>
&
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
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)
systemd-tmpfiles respects atime and ctime by default, not just mtime, so I
think this would only be a probl
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
dynamic, maybe they could be links to files in
> /usr/share/doc/systemd/.
This seems like a *great* idea. systemd-tmpfiles configuration can
easily create such a file, either with contents or as a symlink to a
documentation file in /usr/share/doc.
.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).
; > > how should applications guard against that from
> >> > > happening?
> >> >
> >> > As documented in tmpfiles.d(5), if mmdebstrap takes out an exclusive
> >> > flock(2) lock on its chroot's root directory, system
> >
>> > As documented in tmpfiles.d(5), if mmdebstrap takes out an exclusive
>> > flock(2) lock on its chroot's root directory, systemd-tmpfiles should
>> > fail to take out its own lock on the directory during cleanup, and
>> > respond
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
cache/tmp or such as a place
sysadmins might want to set up for not-backed-up but not-auto-deleted
material.
If the contents aren't dynamic, maybe they could be links to files in
/usr/share/doc/systemd/.
> 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
, one or two lines) and desktop
notification (for desktop only users who never see the terminal) be
helpful. A smarter implementation could perhaps only warn if dirs/files
that are going to be deleted are not systemd generated random items.
This does not fix issues with applications depending on
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
rs who never see the
terminal) be helpful. A smarter implementation could perhaps only warn if
dirs/files that are going to be deleted are not systemd generated random items.
This does not fix issues with applications depending on stuff being there long
term; yet again nothing&#
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
(minimal, one or two
lines) and desktop notification (for desktop only users who never see the
terminal) be helpful. A smarter implementation could perhaps only warn if
dirs/files that are going to be deleted are not systemd generated random items.
This does not fix issues with applications depending
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.
scuss/handle those separately.
>>
>> Agreed.
>>
>> I also don't see any issue with a/, at worst people will be annoyed
>> with it for some reason and can then change it back.
>>
>> > Regarding b/: ...
>>
>> > The tmpfiles rule tmp.conf as
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
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
t; > 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 exclus
> > > how should applications guard against that from
> > > happening?
> >
> > As documented in tmpfiles.d(5), if mmdebstrap takes out an exclusive
> > flock(2) lock on its chroot's root directory, systemd-tmpfiles should
> > fail to take out its own
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
ng?
>
> As documented in tmpfiles.d(5), if mmdebstrap takes out an exclusive
> flock(2) lock on its chroot's root directory, systemd-tmpfiles should
> fail to take out its own lock on the directory during cleanup, and
> respond to that by treating the directory as "in us
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
e
flock(2) lock on its chroot's root directory, systemd-tmpfiles should
fail to take out its own lock on the directory during cleanup, and
respond to that by treating the directory as "in use" and skipping it.
smcv
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
1 - 100 of 2575 matches
Mail list logo
