From: Trent Piepho <tpiepho@impinj.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/3] package/skeleton-init-systemd: work around for /var/lib not populating
Date: Mon, 5 Mar 2018 18:55:10 +0000 [thread overview]
Message-ID: <1520276110.25567.295.camel@impinj.com> (raw)
In-Reply-To: <20180304202911.GA9484@scaer>
On Sun, 2018-03-04 at 21:29 +0100, Yann E. MORIN wrote:
> On 2018-03-04 21:24 +0100, Thomas Petazzoni spake thusly:
> > On Sun, 4 Mar 2018 18:06:15 +0100, Yann E. MORIN wrote:
> > > systemd-tmpfiles[148]: [/etc/tmpfiles.d/var-factory.conf:7] Duplicate line for path "/var/lib/systemd", ignoring.
> > > systemd-tmpfiles[148]: [/etc/tmpfiles.d/var-factory.conf:8] Duplicate line for path "/var/lib/systemd/coredump", ignoring.
> > >
> > > But they can be ignored.
> >
> > But annoying. Lots of people are going to wonder what's happening, and
> > find them bogus.
>
> Yes, I have a few isdeas on how to fix them...
This indicates that there is another tmpfile.d line somewhere for the
same path. In this case, they are in systemd.conf, part of systemd's
installed files.
One could just have the buildroot script avoid the lines for these
specific paths, but then what if systemd removes them from its
tmpfiles.d configuration? Add in some fancy grep command to check a
path against /usr/lib/tmpfiles.d/* and see if it appears anywhere?
> > > IMHO, I think a better solution would be for systemd-tmpfiles to gain a
> > > "merge tree" operation that is like "C" but doesn't abort if the
> >
> > What is "C" ? What is needed for this "better solution" ?
>
> Recursively copy a file or directory, if the destination
> files or directories do not exist yet. Note that this command
> will not descend into subdirectories if the destination
> directory already exists. Instead, the entire copy operation
> is skipped.
That last sentence is the problem. It seems to me that merging the
source into the destination would be more useful. So why wasn't that
done? Maybe it ends up being a really bad idea for some reason that is
not obvious to me? Or maybe the person who coded this originally
didn't need to merge directories and "do nothing" was an easy way to
avoid thinking about that problem?
So what would be needed is to convince the systemd guys that "merge
tree" should be added to tmpfiles and then have someone code it.
Looking at the existing infrastructure in systemd for filesystem tree
ops, it seems like a lot of what is needed is there. But clearly the
timeframe for that is much too long for the buildroot release at hand
now.
The thing I don't like the current situation is that the "create /var
tree" process needs to know each and every path in the /var that is
created on boot by something else. If buildroot duplicates something
from elsewhere, we get those warnings. If buildroot fails to account
for something that is elsewhere, the whole operation can stop working.
Too fragile!
next prev parent reply other threads:[~2018-03-05 18:55 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-04 17:06 [Buildroot] [PATCH 0/3] package/systemd: unbreak a few stuf Yann E. MORIN
2018-03-04 17:06 ` [Buildroot] [PATCH 1/3] package/skeleton-init-systemd: work around for /var/lib not populating Yann E. MORIN
2018-03-04 18:17 ` Adam Duskett
2018-03-04 20:24 ` Thomas Petazzoni
2018-03-04 20:29 ` Yann E. MORIN
2018-03-05 18:55 ` Trent Piepho [this message]
2018-03-04 17:06 ` [Buildroot] [PATCH 2/3] package/skeleton-systemd: invert factory logic Yann E. MORIN
2018-03-06 1:56 ` Trent Piepho
2018-03-04 17:06 ` [Buildroot] [PATCH 3/3] support/tests: enhance the runtime systemd tests Yann E. MORIN
2018-03-04 20:22 ` [Buildroot] [PATCH 0/3] package/systemd: unbreak a few stuf Peter Korsgaard
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=1520276110.25567.295.camel@impinj.com \
--to=tpiepho@impinj.com \
--cc=buildroot@busybox.net \
/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