This bug was fixed in the package systemd - 255.4-1ubuntu5
---
systemd (255.4-1ubuntu5) noble; urgency=medium
* No-change rebuild against libcurl4t64
-- Steve Langasek Sat, 16 Mar 2024
07:04:30 +
** Changed in: systemd (Ubuntu Noble)
Status: Fix Committed => Fix Rele
I have uploaded a change to add the 30d cleanup age.
** Changed in: systemd (Ubuntu Noble)
Status: Triaged => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/
** Changed in: systemd (Ubuntu Noble)
Status: Confirmed => Triaged
** Changed in: systemd (Ubuntu Noble)
Assignee: (unassigned) => Nick Rosbrook (enr0n)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in U
I agree with Nick, regular cleaning *and* cleaning at /boot is best
behavior.
** Tags removed: rls-nn-incoming
** Tags added: foundations-todo
** Also affects: systemd (Ubuntu Noble)
Importance: Wishlist
Status: Confirmed
--
You received this bug notification because you are a member
** Tags added: rls-nn-incoming
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2019026
Title:
systemd /tmp cleaning is suboptimal
Status in systemd package in Ubuntu:
Co
Looks like the experiment worked: having
e /tmp 1777 root root 30d
deleted a test directory which has mtime and atime >30d old (done via:
touch -d '29 days ago', and then left to age over the weekend).
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packa
It looks like something on our autopkgtest-cloud-worker may also be
regularly changing the contents of /tmp but we've set up an experiment
for over the weekend and will report back.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed
AIUI he suggests keeping the boot time cleanup, and that it could be
nice to have the 30d behavior back. In any case that's what I'd prefer.
I know we're speaking of file age; certainly not of blindly deleting
everything every month or so :-)
--
You received this bug notification because you are
On Fri, Feb 16, 2024 at 01:06:07PM -, Paride Legovini wrote:
> Maybe we could make that 40d, as 30d is likely to be a time interval at
> which a lot of periodic things happen (e.g. an off-site backup).
The period here is the age at which files are considered old and to be clean
up, not the in
You say "Nick's preference", but it's Nick who took the position here
that the default behavior should not change?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/2019026
Tit
FWIW I agree with Nick's preference (clean at boot && clean files older
than 30d). Maybe we could make that 40d, as 30d is likely to be a time
interval at which a lot of periodic things happen (e.g. an off-site
backup). A retention period >30d is less likely be synchronized with it
in an unlucky wa
The Ubuntu QA team encountered an issue where our autopkgtest-cloud-
workers in the prod-proposed-migration environment ran out of free space
in /tmp because these are production servers which are rebooted very
infrequently. Due to some bug in the autopkgtest-cloud or autopkgtest
code there were le
> how would it impact you if it was NOT cleaned at reboot?
I just like it. It's easier for me to keep track in my head that "oh,
this file in /tmp will only be around until I reboot", as opposed to
trying to keep track of the actual age of a file. To be clear, I am not
suggesting that my use case
(setting bug back to New because I don't see any request for
information)
** Changed in: systemd (Ubuntu)
Status: Incomplete => New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launch
The reason it's specifically important to me not to clean at boot is
that schroot bind mounts /tmp by default but does not bind mount
/var/tmp by default, so I am accustomed (since long before the systemd
behavior became the norm) to using this directory for sharing data
between the host system and
I personally have become very accustomed to the current behavior where
/tmp is emptied on reboot -- I have no idea what most users would say
about this, so I wonder if changing that behavior would be unwelcome. I
do think it could be nice to have the 30d behavior back, however.
In other words, if
16 matches
Mail list logo
