All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Markus Volk <f_l_k@t-online.de>,
	openembedded-core@lists.openembedded.org
Subject: Re: [oe-core][PATCH] Remove usage of /var/volatile/tmp
Date: Fri, 17 Mar 2023 08:00:37 +0000	[thread overview]
Message-ID: <dd5e0f7df463ddc2733dc126beaa3bf29eb8d49b.camel@linuxfoundation.org> (raw)
In-Reply-To: <20230317060202.385862-1-f_l_k@t-online.de>

On Fri, 2023-03-17 at 07:02 +0100, Markus Volk wrote:
> Currently /tmp is a link to /var/tmp which breaks glib-2.0 ptest
> Systemd documentation describes tmpdir usage as follows:
> 
> /tmp/ and /var/tmp/ are two world-writable directories Linux systems provide for temporary files. The former is
> typically on tmpfs and thus backed by RAM/swap, and flushed out on each reboot. The latter is typically a proper,
> persistent file system, and thus backed by physical storage.
> 
> By default, systemd-tmpfiles will apply a concept of “ageing” to all files and directories stored in /tmp/ and
> /var/tmp/. This means that files that have neither been changed nor read within a specific time frame are auto-
> matically removed in regular intervals.
> (This concept is not new to systemd-tmpfiles btw, it’s inherited from previous subsystems such as tmpwatch.)
> By default files in /tmp/ are cleaned up after 10 days, and those in /var/tmp after 30 days.
> 
> This commit tries to align tmpdir to what systemd expects.

This changes the system layout to what systemd wants but what happens
to sysvinit or anything else though? Some systems won't have systemd-
tmpfiles and so on present. The commit message above makes it sound
like systemd is the only thing that exists/matters.

Cheers,

Richard


  parent reply	other threads:[~2023-03-17  8:00 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-17  6:02 [oe-core][PATCH] Remove usage of /var/volatile/tmp Markus Volk
2023-03-17  6:04 ` Markus Volk
2023-03-17  7:34 ` Alexander Kanavin
2023-03-17  8:00 ` Richard Purdie [this message]
2023-03-17  8:18   ` Markus Volk
2023-03-17 11:53     ` Richard Purdie
2023-03-17 17:31       ` Markus Volk
2023-03-17 19:10         ` Alexander Kanavin
2023-03-22 19:00           ` f_l_k
2023-03-22 19:11             ` Alexander Kanavin
     [not found]               ` <9VVZRR.NLXPW4ISUM5R2@t-online.de>
2023-03-23 22:34                 ` Richard Purdie
2023-03-24 17:34               ` Markus Volk
2023-03-24 19:53                 ` Alexander Kanavin
2023-03-24 23:13                   ` Markus Volk
2023-03-25 18:38                     ` Alexander Kanavin
2023-03-25 19:19                       ` Markus Volk
     [not found]               ` <174F6B63D17BDF87.25304@lists.openembedded.org>
2023-03-24 17:58                 ` Markus Volk

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=dd5e0f7df463ddc2733dc126beaa3bf29eb8d49b.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=f_l_k@t-online.de \
    --cc=openembedded-core@lists.openembedded.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.