-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Tue, 18 Jun 2024 23:49:25 +0100
Source: systemd-boot-installer
Architecture: source
Version: 0.2
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team
Changed-By: Luca Boccassi
Changes:
systemd-boot
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Tue, 18 Jun 2024 23:19:16 +0100
Source: systemd
Architecture: source
Version: 256.1-1
Distribution: unstable
Urgency: medium
Maintainer: Debian systemd Maintainers
Changed-By: Luca Boccassi
Closes: 1072562 1073290
Changes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Wed, 12 Jun 2024 01:30:51 +0100
Source: systemd
Binary: libnss-myhostname libnss-myhostname-dbgsym libnss-mymachines
libnss-mymachines-dbgsym libnss-resolve libnss-resolve-dbgsym libnss-systemd
libnss-systemd-dbgsym libpam
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sun, 02 Jun 2024 23:49:55 +0100
Source: systemd-boot-installer
Binary: systemd-boot-installer
Architecture: source all
Version: 0.1
Distribution: unstable
Urgency: medium
Maintainer: Debian Install System Team
Changed-By: Luca
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Tue, 11 Jun 2024 22:59:12 +0100
Source: systemd
Architecture: source
Version: 256-1
Distribution: unstable
Urgency: medium
Maintainer: Debian systemd Maintainers
Changed-By: Luca Boccassi
Changes:
systemd (256-1) unstable
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Thu, 06 Jun 2024 20:49:17 +0100
Source: systemd
Architecture: source
Version: 256~rc4-1
Distribution: unstable
Urgency: high
Maintainer: Debian systemd Maintainers
Changed-By: Luca Boccassi
Closes: 1072373
Changes:
systemd (256
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 components
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Sat, 01 Jun 2024 12:30:39 +0100
Source: systemd
Architecture: source
Version: 256~rc3-7
Distribution: unstable
Urgency: medium
Maintainer: Debian systemd Maintainers
Changed-By: Luca Boccassi
Closes: 1072249
Changes:
systemd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Thu, 30 May 2024 18:11:19 +0100
Source: systemd
Architecture: source
Version: 256~rc3-6
Distribution: unstable
Urgency: medium
Maintainer: Debian systemd Maintainers
Changed-By: Luca Boccassi
Closes: 1072155 1072187
Changes
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
stems; 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 issu
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 well-known
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
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
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 rele
> 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
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
>
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
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
* 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
> > >
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Wed, 29 May 2024 01:04:53 +0100
Source: systemd
Architecture: source
Version: 256~rc3-5
Distribution: unstable
Urgency: medium
Maintainer: Debian systemd Maintainers
Changed-By: Luca Boccassi
Changes:
systemd (256~rc3-5
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
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Tue, 28 May 2024 12:11:36 +0100
Source: systemd
Architecture: source
Version: 256~rc3-4
Distribution: unstable
Urgency: medium
Maintainer: Debian systemd Maintainers
Changed-By: Luca Boccassi
Changes:
systemd (256~rc3-4
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Tue, 28 May 2024 00:07:57 +0100
Source: systemd
Architecture: source
Version: 256~rc3-3
Distribution: unstable
Urgency: medium
Maintainer: Debian systemd Maintainers
Changed-By: Luca Boccassi
Closes: 825438 851314 913061 966621
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Thu, 23 May 2024 16:31:42 +0100
Source: systemd
Architecture: source
Version: 256~rc3-2
Distribution: unstable
Urgency: medium
Maintainer: Debian systemd Maintainers
Changed-By: Luca Boccassi
Changes:
systemd (256~rc3-2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Wed, 22 May 2024 23:24:02 +0100
Source: systemd
Architecture: source
Version: 256~rc3-1
Distribution: unstable
Urgency: medium
Maintainer: Debian systemd Maintainers
Changed-By: Luca Boccassi
Closes: 1071278
Changes:
systemd
> > 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
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Thu, 16 May 2024 22:51:08 +0100
Source: systemd
Built-For-Profiles: stage1
Architecture: source
Version: 256~rc2-3
Distribution: unstable
Urgency: medium
Maintainer: Debian systemd Maintainers
Changed-By: Luca Boccassi
Changes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Thu, 16 May 2024 17:40:43 +0100
Source: systemd
Built-For-Profiles: stage1
Architecture: source
Version: 256~rc2-2
Distribution: unstable
Urgency: medium
Maintainer: Debian systemd Maintainers
Changed-By: Luca Boccassi
Closes
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Wed, 15 May 2024 00:40:56 +0100
Source: systemd
Architecture: source
Version: 256~rc2-1
Distribution: unstable
Urgency: medium
Maintainer: Debian systemd Maintainers
Changed-By: Luca Boccassi
Closes: 1070499
Changes:
systemd
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 al
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 1.8
Date: Wed, 15 May 2024 08:37:08 +0200
Source: kde-config-systemd
Architecture: source
Version: 1.2.1-3.3
Distribution: unstable
Urgency: medium
Maintainer: Shawn Sörbom
Changed-By: Pino Toscano
Closes: 1060527
Changes:
kde-config
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
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.launchpad.net
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. T
> 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
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
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
dependently. (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 and it may already support (as
systemd
ld 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,
IMHO, are significantly outweighed by the risks.
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.
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"
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
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
' 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)
>
> system
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
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,
s 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 problem on file
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
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
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
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,
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
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.
/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
to survive for weeks or even months
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
> "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
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
> 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,
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
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, systemd
> >
>> > 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 th
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
ch 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
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
, 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
nt 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 not cleaning /var/tmp by default]
May
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's perfect in software
obile 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/ a tmpfs and cleanup /var/tmp/ on a timer by default
[was: Re: systemd: tmpfiles.d no
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
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
(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
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.c
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
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
.
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/tmp by default]
On Mon, 6
1 - 100 of 3811 matches
Mail list logo
