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

[SCOTT FIELDS]

I've not seen any response on this.

My primary question regards the behavior of the following, and the correct behavior.

--

d

    Create a directory. The mode and ownership will be adjusted if specified. Contents of this directory are subject to time-based cleanup if the age argument is specified. 
D

    Similar to d, but in addition the contents of the directory will be removed when --remove is used.

--

Though not directly stated here, and inference from other help discussions on other forums is that this only applies to files in the top level of the specified path.

I.E. it doesn't recursively process all files/directories in the specified path.

Is that still correct?

The date format documentation isn't clear on this behavior, either.

--

If the age field starts with a tilde character "~", clean-up is only applied to files and directories one level inside the directory specified, but not the files and directories immediately inside it.

--

This implies that the behavior SHOULD be recursive, if the '`' modifier isn't present.

Is this correct, in that 'd' or 'D' should be recursive to all files/directories in the specified path?

If at systemd 219-78, does this still apply, or is this behavior a change that was done post 219-78. I don't see it processing files below the top level on our systems without '`' in the age field.

-----Original Message-----
From: SCOTT FIELDS 
Sent: Wednesday, August 31, 2022 6:10 AM
To: Ulrich Windl <Ulrich.Windl at rz.uni-regensburg.de>; systemd-devel at lists.freedesktop.org; antlists at youngman.org.uk
Subject: RE: [EXTERNAL] [systemd-devel] Antw: Re: Antw: [EXT] [systemd
devel] systemd
tmpfiles: behavior of 

clean

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 at lists.freedesktop.org> On Behalf Of Ulrich Windl
Sent: Wednesday, August 31, 2022 4:42 AM
To: systemd-devel at lists.freedesktop.org; antlists at youngman.org.uk
Subject: [EXTERNAL] [systemd-devel] Antw: Re: Antw: [EXT] [systemd
devel] systemd
tmpfiles: behavior of 

clean

>>> Wols Lists <antlists at youngman.org.uk> schrieb am 31.08.2022 um 09:25 
>>> in
Nachricht <6c25970f-c7cb-2728-a827-1452e193762d at youngman.org.uk>:
> 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