public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH] cleanfs: Clear /var/tmp on boot as well
Date: Tue, 01 Mar 2022 10:56:33 +0000	[thread overview]
Message-ID: <0C30EA46-22A6-4C87-B2E8-A26636AE2021@ipfire.org> (raw)
In-Reply-To: <0859f5b2a9dce90dd0e5fef01c9608856eef5787.camel@ipfire.org>

[-- Attachment #1: Type: text/plain, Size: 2193 bytes --]

Hello everyone,

I agree with Paul and Stefan here. We should move things out of there first before we add this directory to the tidy up at boot time.

Who would like to grab this and work on this?

-Michael

> On 28 Feb 2022, at 18:48, Stefan Schantl <stefan.schantl(a)ipfire.org> wrote:
> 
> Hello Peter, Hello List,
> 
> I have to decline this patch because the IDS system currently stores
> the downloaded tarballs (which contains the rules of a provider) in
> that directory.
> 
> Each time the ruleset is altered or updated, these tarballs will be
> decompressed and the required files are extracted from them.
> 
> So cleaning up this directory, would remove the tarballs and currently
> breaks the entire IDS.
> 
> We might have to think about keeping this tarballs or to move them to a
> different (better) location.
> 
> Best regards,
> 
> -Stefan
>> Similar to /tmp/, there is no reason to keep any leftovers in
>> /var/tmp,
>> nor can any application expect content placed there to be persistent.
>> 
>> On several IPFire installations I have access to, this would remove
>> quite some clutter accumulated in /var/tmp over the years.
>> 
>> Signed-off-by: Peter Müller <peter.mueller(a)ipfire.org>
>> ---
>>  src/initscripts/system/cleanfs | 5 +++++
>>  1 file changed, 5 insertions(+)
>> 
>> diff --git a/src/initscripts/system/cleanfs
>> b/src/initscripts/system/cleanfs
>> index d1cbb2547..f315682ce 100644
>> --- a/src/initscripts/system/cleanfs
>> +++ b/src/initscripts/system/cleanfs
>> @@ -117,6 +117,11 @@ case "${1}" in
>>                 find . -xdev -mindepth 1 ! -name lost+found \
>>                         -delete || failed=1
>>  
>> +               boot_mesg -n " /var/tmp" ${NORMAL}
>> +               cd /var/tmp &&
>> +               find . -xdev -mindepth 1 ! -name lost+found \
>> +                       -delete || failed=1
>> +
>>                 boot_mesg -n " /var/ipfire/dhcp" ${NORMAL}
>>                 cd /var/ipfire/dhcpc/ && find . -name "*.pid" -exec
>> rm -f {} \; || failed=1
>>                 cd /var/ipfire/dhcpc/ && find . -name "*.cache" -exec
>> rm -f {} \; || failed=1
> 
> 


       reply	other threads:[~2022-03-01 10:56 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <0859f5b2a9dce90dd0e5fef01c9608856eef5787.camel@ipfire.org>
2022-03-01 10:56 ` Michael Tremer [this message]
2022-02-27 21:53 Peter Müller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0C30EA46-22A6-4C87-B2E8-A26636AE2021@ipfire.org \
    --to=michael.tremer@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox