Re: Antw: Re: Antw: [EXT] [systemd‑devel] systemd‑tmpfiles: behavior of ‑‑clean

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



By this logic, the '--clean' option shouldn't exist in systemd-tmpfiles.

The point here is that apps aren't perfect, and you still need to periodically cleanup items that apps haven't.

 That can be due to app bugs or behavior issues in certain situations (and in some cases, ones that aren't going to get fixed, for various reasons).

All of the above aren't the only reasons you need a system level approach to cleaning up old data.

-----Original Message-----
From: systemd-devel <systemd-devel-bounces@xxxxxxxxxxxxxxxxxxxxx> On Behalf Of Ulrich Windl
Sent: Wednesday, August 31, 2022 4:42 AM
To: systemd-devel@xxxxxxxxxxxxxxxxxxxxx; antlists@xxxxxxxxxxxxxxx
Subject: [EXTERNAL]  Antw: Re: Antw: [EXT] [systemddevel] systemdtmpfiles: behavior of clean

>>> Wols Lists <antlists@xxxxxxxxxxxxxxx> schrieb am 31.08.2022 um 09:25 
>>> in
Nachricht <6c25970f-c7cb-2728-a827-1452e193762d@xxxxxxxxxxxxxxx>:
> On 31/08/2022 07:16, Ulrich Windl wrote:
>>> 'tomcat.<####>' with other associated files (or directories below this).
> 
>> I think with the guideline "clean up your own dirt" there wouldn't be 
>> so
> much
>> need for external cleanup if the applications would do a better job. 
>> The application always knows best what, how, and when to clean up. 
>> (MHO)
>> 
> Always? Sometimes the application doesn't have a clue!

If you write an app and you don't know what temporary data you create or need, you have a big problem!

> 
> Simple example, your system crashes (or a thread exits with a crash, 
> security violation, out-of-mem, whatever). Why on earth should the
> *application* have a clue about what that crashed process was doing? 
> If

35 years ago vi knew.

> (as is the case with tomcat) it was carrying out a user request, all 
> state has gone.

Then put "volatile" files in a separate directory and wipe that before start.
Other data should be recovered from their location.
It's all a design issue.

> 
> And even within the application you can't just come along and clean up 
> stuff that doesn't belong to you because another thread might own it 
> and

Wha said the application should clean up "foreign" stuff?

> be most upset when it disappears. Truly, the sysadmin often *does* 
> know best.

But the sysadmin is not an automatic job ;-)

> 
> Cheers,
> Wol








[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux