Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Hakan Bayındır]

> 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-get upgrade".
> 
> This change is likely to come to the majority of our installations
> ("stable") with a release upgrade, which is never boring, but one of
> the most exciting things that can happen to a Debian stable system.

You’re right, new Debian releases always brings me joy too. I used “completely 
boring” in a positive way, to underline how uneventful a Debian release upgrade 
is in 99.999% of the time. In other words, I wanted to underline that I prefer 
the next release would be what I expect from Debian. Upgrade, reboot, continue 
drinking coffee and do productive things.

If a new installation comes with different defaults, as I said before, I’m OK 
with that. Software evolves, and should evolve. What I don’t prefer is forcing 
on this evolution on me, on an established system. I work with a lot of 
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 well-known "please upgrade
> kernel first and reboot" during one udev/systemd upgrade.

I also read the release notes and any caveats and warnings before starting, 
however what I don’t expect is to reconfigure a fleet of servers to restore 
some settings which I customized for the particular role and software on that 
server. I know configuration changes are negotiated during upgrades, but when 
partition changes and automated deletion schedules are “inflicted”, that’s 
something bigger than “we upgraded this daemon/tool and brought better 
defaults, wanna look?” Which happens during upgrades.

> Ubuntu seems to have put the release notes in an automatism disguise
> called do-release-upgrade which probably changes from release to
> release regarding what specialty is in the store for this update. We
> don't have that, we ask our users to read the release notes.

I’m not a big fan of Ubuntu and how they do things, and I don’t use it. I 
prefer Debian to be Debian and to need some RTFM process to administer 
correctly. I’m an old school person and sysadmin. I prefer a more direct, “this 
machine has no brain, use yours” approach. :)

> Greetings
> Marc

Hope I managed to express myself in an understandable way this time. :)

Cheers,

H.

> -- 
> 
> Marc Haber |   " Questions are the | Mailadresse im Header
> Rhein-Neckar, DE   | Beginning of Wisdom " | 
> Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Marc Haber]

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 our installations
("stable") with a release upgrade, which is never boring, but one of
the most exciting things that can happen to a Debian stable system.

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 "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 release to
release regarding what specialty is in the store for this update. We
don't have that, we ask our users to read the release notes.

Greetings
Marc
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Hakan Bayındır]

> 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 existing behaviour unchanged (no cleanup of
 /var/tmp)
>>> [...]
>>> 
>>> Hello,
>>> 
>>> I think it is bad choice to deliberately have different behavior for
>>> freshly installed and upgraded systems. Offering upgrades has always
>>> been one of the major selling points of Debian, and imho this
>>> implicitely includes that you do not get a worse or second class Debian
>>> installation when you upgrade it than if you installed from scratch.
>>> 
>>> cu Andreas
>> 
>> I'll kindly disagree here.
> 
> While I agree with Andreas that having the same behavior for upgraded
> systems and new installations is generally better, I agree with you that
> in this specific case it is not the better choice.
> 
>> 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".
> 
> You haven't specified what behavior you want.  Is it the existing
> behavior or the new behavior?  This thread is exactly about choosing
> between the two, and possibly between different behavior for new and
> existing systems.
Sorry, I thought that the sentence was self explanatory. Using English as a 
second language has its peculiarities. Let me explain.

1. For existing systems, I don’t want anything modified. Let it be Debian’s old 
defaults, or a custom config I made for that system. IOW, I want my old systems 
to have /tmp as a proper disk partition, and nothing to be cleaned 
periodically, or whatever I set to these systems.

2. For new installation, I’m fine with what Debian proposes. For clarity, I’m 
still against automated cleaning of /tmp and /var/tmp of the reasons I outlined 
before (tl;dr: Long running systems with seldom accessed but required files), 
but I’m fine with whatever Debian decides and ships. At most, I’ll configure 
the behavior I need, but I don’t expect it to be changed down the line by 
package updates.

Hope this clears this part.
> 
> There are four combinations of old/new behavior and upgrading/new
> installation.  Eliminating the obviously bad combination, we are left
> with three:
> 
> A.  Keep old behavior for both upgrading and new installations.
> B.  Keep old behavior for upgrading, use new behavior for new installations.
> C.  Apply new behavior for both.

As I aforementioned, I’m a proponent of “A”, but it’s not favored it seems. So, 
I want to drive the line at “B”. “C” can cause problems because a seasoned 
Debian install is probably old enough to attend school (i.e. 7+ years), and a 
ton of custom configuration is accumulated in /etc, ~/.local, ~/.config and 
elsewhere. Touching working systems and periodically deleting files out of 
nowhere can cause big headaches and worse. 

> The new behavior is preferable for many use cases, but the old behavior
> is not a "BUG" that must be fixed.  Debian has had the old behavior for
> a very long time.
> 
> A number of people have spoken up on this list saying that they are
> relying on the old behavior, and that changing to the new behavior could
> potentially cause serious data loss.

I personally don’t rely on the old behavior, but I work with clusters, and as I 
detailed, some files can linger for a very long time before deleted. These are 
not bugs of these systems, it’s just a side effect of how clusters and long 
running jobs work. Also, RedHat and their derivatives behaves exactly the same 
as how current Debian behaves. /tmp is a partition (which we sometimes mount to 
a high speed NVMe RAID on multi-GPU systems), which is used for data exchange 
between processors, processes, etc., and these files live a pretty long life 
for longer jobs.

> 
> Some people have stated an opinion that keeping upgraded systems in sync
> with the behavior of new installations is desirable.
> 
> So to choose between A, B, and C, we must rank the following:
> 
> X.  desirability of new behavior
> Y.  preventing data loss for an unspecified, but non-zero, number of
>existing systems
> Z.  desirability of having upgraded systems match new installations.
> 
> Both X and Z are primarily opinions with some (non-overwhelming)
> technical merit to each.
> 
> Sufficient technical arguments have been provided on this meta-thread to
> support that Y is highly important and also more important than both X
> and Z.  This means that choice C fails.

So yes, Y is very important for some (small in number, big in footprint) 
installations.

> If Z were more important than X, then the order of importance would
> become Y, then Z, then X, which would make choice A the winner.
> 
> However, there have been no technical arguments 

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Lyndon Brown]

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
> years) worked on *this* *specific* Debian system.".
> 
> cu Andreas

I think you might be missing the point that this is the *DEFAULT*
behaviour. You're free to override it. If you personally have no
precious data in tmp storage to worry about then after upgrade you can
simply tweak the config to enable the new behaviour, as I have done.

I'm using Sid and after doing a little reading up on the topic
yesterday after the upgrade I believe all that needed doing was to
delete the /etc/tmpfiles.d/tmp.conf file, which as I understand it
contains a simple override of the new behaviour defined in
/usr/lib/tmpfiles.d/tmp.conf.

FWIW I think Luca made a perfectly sensible choice here.

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Noah Meyerhans]

On Wed, May 29, 2024 at 06:58:32PM +0200, Andreas Metzler wrote:
> >> I think it is bad choice to deliberately have different behavior for
> >> freshly installed and upgraded systems. Offering upgrades has always
> >> been one of the major selling points of Debian, and imho this
> >> implicitely includes that you do not get a worse or second class Debian
> >> installation when you upgrade it than if you installed from scratch.
> 
> > I strongly disagree: it is a bad choice to change on upgrades a default 
> > which may cause data loss.
> 
> That is false dichotomy. data-loss will occur when people use /tmp or
> /var/tmp for persistent data-storage because "This has (for a couple of
> years) worked on Debian systems" not because "This has (for a couple of
> years) worked on *this* *specific* Debian system.".

Both perspectives are valid, and that is part of why this change is
concerning to me.  Transitioning the filesystem configuration of an
existing system is inherently dangerous and can lead to data loss, as
Marco points out.  But leaving a system to diverge from the default
Debian base configuration leads to configurtion drift that may trigger
obscure bugs, untested configuration, difficult upgrades, etc.  I'm not
convinced the change is worth the risk.

noah

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Andreas Metzler]

On 2024-05-29 Marco d'Itri  wrote:
> On May 28, Andreas Metzler  wrote:

>> I think it is bad choice to deliberately have different behavior for
>> freshly installed and upgraded systems. Offering upgrades has always
>> been one of the major selling points of Debian, and imho this
>> implicitely includes that you do not get a worse or second class Debian
>> installation when you upgrade it than if you installed from scratch.

> I strongly disagree: it is a bad choice to change on upgrades a default 
> which may cause data loss.

Hello,

That is false dichotomy. data-loss will occur when people use /tmp or
/var/tmp for persistent data-storage because "This has (for a couple of
years) worked on Debian systems" not because "This has (for a couple of
years) worked on *this* *specific* Debian system.".

cu Andreas

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Marvin Renich]

* 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)
> > [...]
> > 
> > Hello,
> > 
> > I think it is bad choice to deliberately have different behavior for
> > freshly installed and upgraded systems. Offering upgrades has always
> > been one of the major selling points of Debian, and imho this
> > implicitely includes that you do not get a worse or second class Debian
> > installation when you upgrade it than if you installed from scratch.
> > 
> > cu Andreas
> 
> I'll kindly disagree here.

While I agree with Andreas that having the same behavior for upgraded
systems and new installations is generally better, I agree with you that
in this specific case it is not the better choice.

> 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".

You haven't specified what behavior you want.  Is it the existing
behavior or the new behavior?  This thread is exactly about choosing
between the two, and possibly between different behavior for new and
existing systems.

There are four combinations of old/new behavior and upgrading/new
installation.  Eliminating the obviously bad combination, we are left
with three:

A.  Keep old behavior for both upgrading and new installations.
B.  Keep old behavior for upgrading, use new behavior for new installations.
C.  Apply new behavior for both.

The new behavior is preferable for many use cases, but the old behavior
is not a "BUG" that must be fixed.  Debian has had the old behavior for
a very long time.

A number of people have spoken up on this list saying that they are
relying on the old behavior, and that changing to the new behavior could
potentially cause serious data loss.

Some people have stated an opinion that keeping upgraded systems in sync
with the behavior of new installations is desirable.

So to choose between A, B, and C, we must rank the following:

X.  desirability of new behavior
Y.  preventing data loss for an unspecified, but non-zero, number of
existing systems
Z.  desirability of having upgraded systems match new installations.

Both X and Z are primarily opinions with some (non-overwhelming)
technical merit to each.

Sufficient technical arguments have been provided on this meta-thread to
support that Y is highly important and also more important than both X
and Z.  This means that choice C fails.

If Z were more important than X, then the order of importance would
become Y, then Z, then X, which would make choice A the winner.

However, there have been no technical arguments whatsoever that Z is
more important than either of X or Y, only a few personal opinions.
And, from the discussion, the consensus appears to be that X is more
important than Z, so the order is Y, then X, then Z.

This gives us choice B as the winner.

It also looks like Luca Boccassi has already made the changes to effect
choice B.  Thank you, Luca!

,,,Marvin

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Hakan Bayındır]

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 have different behavior for
freshly installed and upgraded systems. Offering upgrades has always
been one of the major selling points of Debian, and imho this
implicitely includes that you do not get a worse or second class Debian
installation when you upgrade it than if you installed from scratch.

cu Andreas


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".


Cheers,

H.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Luca Boccassi]

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
> >> been one of the major selling points of Debian, and imho this
> >> implicitely includes that you do not get a worse or second class Debian
> >> installation when you upgrade it than if you installed from scratch.
> >I strongly disagree: it is a bad choice to change on upgrades a default
> >which may cause data loss.
>
> I also think that a change of this kind is release notes material. A
> system having been updated for two decades is bound to carry some
> cruft.


> - two paragraphs have been provided for the release notes ticket

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Marc Haber]

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 this
>> implicitely includes that you do not get a worse or second class Debian
>> installation when you upgrade it than if you installed from scratch.
>I strongly disagree: it is a bad choice to change on upgrades a default 
>which may cause data loss.

I also think that a change of this kind is release notes material. A
system having been updated for two decades is bound to carry some
cruft.

Greetings
Marc
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Marco d'Itri]

On May 28, Andreas Metzler  wrote:

> I think it is bad choice to deliberately have different behavior for
> freshly installed and upgraded systems. Offering upgrades has always
> been one of the major selling points of Debian, and imho this
> implicitely includes that you do not get a worse or second class Debian
> installation when you upgrade it than if you installed from scratch.
I strongly disagree: it is a bad choice to change on upgrades a default 
which may cause data loss.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Andreas Metzler]

On 2024-05-28 Luca Boccassi  
wrote:
[...]
> - existing installations pre-trixie will get an orphaned tmpfiles.d in
> /etc/ that keeps the existing behaviour unchanged (no cleanup of
> /var/tmp)
[...]

Hello,

I think it is bad choice to deliberately have different behavior for
freshly installed and upgraded systems. Offering upgrades has always
been one of the major selling points of Debian, and imho this
implicitely includes that you do not get a worse or second class Debian
installation when you upgrade it than if you installed from scratch.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Luca Boccassi]

> > what would break where, and how to fix it? I only found autopkgtest
> so
> > far, which uses /tmp/ in the guest and expects it to survive across
> > reboots, and I have a MR up already for that. Anything else?
> 
> Perhaps whatever makes these files in /tmp? i think something to do
> with
> X/gdm/gnome?
> 
> /tmp/.X0-lock
> /tmp/.X1024-lock
> /tmp/.X1025-lock
> 
> /tmp/.X11-unix
> /tmp/.X1-lock
> 
> /tmp/.XIM-unix
> 
> /tmp/.font-unix
> 
> /tmp/.ICE-unix

These are all already covered by /usr/lib/tmpfiles.d/x11.conf

-- 
Kind regards,
Luca Boccassi


signature.asc
Description: This is a digitally signed message part

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Luca Boccassi]

On Tue, 7 May 2024 at 17:33, Sam Hartman  wrote:
>
> > "Luca" == Luca Boccassi  writes:
>
> Luca> On Mon, 6 May 2024 at 15:42, Richard Lewis
> Luca>  wrote:
> >>
> >> Luca Boccassi  writes:
> >>
> >> > Hence, I am not really looking for philosophical discussions or
> >> lists > of personal preferences or hypotheticals, but for facts:
> >> what would > break where, and how to fix it?
>
> ssh-agent appears to default to creating a socket under /tmp.
> I think respecting $XDG_RUNTIME_DIR would be better.
>
> /etc/X11/Xsession.d/90x11-common_ssh-agent also doesn't override where
> the socket ends up.
> I definitely think for session scripts like that $XDG_RUNTIME_DIR would
> be better.
>
>
> gnome-keyring's ssh-agent handles this better, although last time I
> checked, it did not support pkcs11, so I could not use it with PIV
> cards.
> (Other parts of gnome-keyring do support pkcs11).

The ssh agent provided by gnupg also behaves correctly and creates the
socket in XDG_RUNTIME_DIR. I have filed a bug for openssh-client's
ssh-agent.

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Luca Boccassi]

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 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)
>
> systemd-tmpfiles respects atime and ctime by default, not just mtime, so I
> think this would only be a problem on file systems that didn't support
> those attributes.  atime is often turned off, but I believe support for
> ctime is fairly universal among the likely file systems for /var/tmp, and
> I believe tmpfs supports all three.  (I'm not 100% sure, though, so please
> correct me if I'm wrong.)

Yes atime/ctime are used too, so things that are really in the process
of being used are not really an issue.

I checked screen and even in bookworm it uses /run/screen/ as you
said, so it's fine.

I checked tmux and indeed it uses /tmp/tmux-UID/ - which is a terrible
choice given it's predictable so if something manages to run first it
can hijack it, but that's really a pre-existing issue. I've filed a
bug to notify that it needs to start flocking the file in /tmp/ while
running to avoid them being deleted while in use.

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Sven Mueller]

Am 07.05.2024 22:56 schrieb Richard Lewis :Luca Boccassi  writes:



> qwhat would

> break where, and how to fix it?



Another one for you to investigate: I believe apt source and 'apt-get

source' download and extract things into /tmp, as in the mmdebootstap

example mentioned by someone else, this will create "old" files that

could immediately be flagged for deletion causing surprises.`apt download` and `apt source` download to your current working directory. Same for apt-get.
(People restoring from backups might also find this an issue)I would not expect people to restore to /tmp and expecting that restore to work across a reboot. And to be honest, I find the expectation to have any guarantee on files in /tmp or /var/tmp across a reboot quite surprising. The directories are named "tmp" because they are meant as temporary storage, which implies automatic deleting at some point IMHO.Now, bad choices by various tools have been mentioned, so a cleaner for these directories that runs outside a reboot has to be careful anyhow. But during a reboot? I don't think that should be too much of a problem. Cheers, Sven

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Russ Allbery]

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" 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 systems that didn't support
those attributes.  atime is often turned off, but I believe support for
ctime is fairly universal among the likely file systems for /var/tmp, and
I believe tmpfs supports all three.  (I'm not 100% sure, though, so please
correct me if I'm wrong.)

-- 
Russ Allbery (r...@debian.org)  

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Richard Lewis]

Luca Boccassi  writes:

> qwhat would
> break where, and how to fix it?

Another one for you to investigate: I believe apt source and 'apt-get
source' download and extract things into /tmp, as in the mmdebootstap
example mentioned by someone else, this will create "old" files that
could immediately be flagged for deletion causing surprises.

(People restoring from backups might also find this an issue)

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Sam Hartman]

> "Luca" == Luca Boccassi  writes:

Luca> On Mon, 6 May 2024 at 15:42, Richard Lewis
Luca>  wrote:
>> 
>> Luca Boccassi  writes:
>> 
>> > Hence, I am not really looking for philosophical discussions or
>> lists > of personal preferences or hypotheticals, but for facts:
>> what would > break where, and how to fix it?

ssh-agent appears to default to creating a socket under /tmp.
I think respecting $XDG_RUNTIME_DIR would be better.

/etc/X11/Xsession.d/90x11-common_ssh-agent also doesn't override where
the socket ends up.
I definitely think for session scripts like that $XDG_RUNTIME_DIR would
be better.


gnome-keyring's ssh-agent handles this better, although last time I
checked, it did not support pkcs11, so I could not use it with PIV
cards.
(Other parts of gnome-keyring do support pkcs11).

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Russ Allbery]

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 useful only as long as screen/tmux are still running,
> right (I don't really use either that much)? If so, a flock is the right
> solution for these

Also, using /tmp as a path for those sockets was always a questionable
decision.  I believe current versions of screen use /run/screen, which is
a more reasonable location.  Using a per-user directory would be even
better, although I think screen intentionally supports shared screens
between users (which is a somewhat terrifying feature from a security
standpoint, but that's a different argument).

-- 
Russ Allbery (r...@debian.org)  

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Luca Boccassi]

On Mon, 6 May 2024 at 23:03, Richard Lewis
 wrote:
>
> Luca Boccassi  writes:
>
> > Hence, I am not really looking for philosophical discussions or lists
> > of personal preferences or hypotheticals, but for facts: what would
> > break where, and how to fix it?
>
> - tmux stores sockets in /tmp/tmux-$UID
> - I think screen might use /tmp/screens
>
> I suppose if you detached for a long time you might find yourself unable
> to reattach.
>
> I think you can change the location of these.

And those are useful only as long as screen/tmux are still running,
right (I don't really use either that much)? If so, a flock is the
right solution for these

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Richard Lewis]

Luca Boccassi  writes:

> Hence, I am not really looking for philosophical discussions or lists
> of personal preferences or hypotheticals, but for facts: what would
> break where, and how to fix it?

- tmux stores sockets in /tmp/tmux-$UID
- I think screen might use /tmp/screens

I suppose if you detached for a long time you might find yourself unable
to reattach.

I think you can change the location of these.

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Richard Lewis]

Luca Boccassi  writes:

> On Mon, 6 May 2024 at 15:42, Richard Lewis
>  wrote:
>>
>> Luca Boccassi  writes:
>>
>> > Hence, I am not really looking for philosophical discussions or lists
>> > of personal preferences or hypotheticals, but for facts: what would
>> > break where, and how to fix it?
>>
>> cleaning /tmp or /var/tmp: users may lose files if they dont realise a
>>   directory tmp can be cleaned without a reboot. something in /var/tmp
>>   that's been in there for 35 days before an upgrade might be deleted
>>   before the user reads the NEWS.Debian email, meaning they have no
>>   chance to react). Maybe you could postpone the very first deletion
>>   until after the next reboot?
>>
>> using a tmpfs: is there a risk of losing unrelated data due to more
>>   frequent OOM killing random other programmes due to /tmp using all the
>>   memory?  is there a case to only use a tmpfs if the system has
>>   "enough" memory?
>
> Again, those are all hypotheticals, and one can construct similarly
> contrived thought exercises for most possible permutations of most
> configurations, and the answer is always the same: customize the
> configuration accordingly. Hence, not relevant right now.

> What is relevant is: which packages, if any, or which DSA-owned
> systems, if any, are actually affected and how?

Why do you think that the impact on users is less important than the
impact on debian packages?

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Luca Boccassi]

On Mon, 6 May 2024 at 15:42, Richard Lewis
 wrote:
>
> Luca Boccassi  writes:
>
> > Hence, I am not really looking for philosophical discussions or lists
> > of personal preferences or hypotheticals, but for facts: what would
> > break where, and how to fix it?
>
> cleaning /tmp or /var/tmp: users may lose files if they dont realise a
>   directory tmp can be cleaned without a reboot. something in /var/tmp
>   that's been in there for 35 days before an upgrade might be deleted
>   before the user reads the NEWS.Debian email, meaning they have no
>   chance to react). Maybe you could postpone the very first deletion
>   until after the next reboot?
>
> using a tmpfs: is there a risk of losing unrelated data due to more
>   frequent OOM killing random other programmes due to /tmp using all the
>   memory?  is there a case to only use a tmpfs if the system has
>   "enough" memory?

Again, those are all hypotheticals, and one can construct similarly
contrived thought exercises for most possible permutations of most
configurations, and the answer is always the same: customize the
configuration accordingly. Hence, not relevant right now.
What is relevant is: which packages, if any, or which DSA-owned
systems, if any, are actually affected and how?

Re: Bug#966621: Make /tmp/ a tmpfs and cleanup /var/tmp/ on a timer by default [was: Re: systemd: tmpfiles.d not cleaning /var/tmp by default]

[Richard Lewis]

Luca Boccassi  writes:

> Hence, I am not really looking for philosophical discussions or lists
> of personal preferences or hypotheticals, but for facts: what would
> break where, and how to fix it?

cleaning /tmp or /var/tmp: users may lose files if they dont realise a
  directory tmp can be cleaned without a reboot. something in /var/tmp
  that's been in there for 35 days before an upgrade might be deleted
  before the user reads the NEWS.Debian email, meaning they have no
  chance to react). Maybe you could postpone the very first deletion
  until after the next reboot?

using a tmpfs: is there a risk of losing unrelated data due to more
  frequent OOM killing random other programmes due to /tmp using all the
  memory?  is there a case to only use a tmpfs if the system has
  "enough" memory?