Bug 690253 - don't fail when two identical tmpfiles lines are configured
Summary: don't fail when two identical tmpfiles lines are configured
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: systemd
Version: rawhide
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Lennart Poettering
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-23 17:41 UTC by Horst H. von Brand
Modified: 2011-05-01 03:23 UTC (History)
6 users (show)

Fixed In Version: systemd-25-1.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-05-01 03:23:16 UTC
Type: ---


Attachments (Terms of Use)

Description Horst H. von Brand 2011-03-23 17:41:05 UTC
Description of problem:
On boot I see:

systemd-tmpfiles-setup.service exited, status=1 (or something similar)

# systemctl status systemd-tmpfiles-setup.service
systemd-tmpfiles-setup.service - Recreate Volatile Files and Directories
          Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service)
          Active: failed since Wed, 23 Mar 2011 14:08:51 -0300; 29min ago
         Process: 914 ExecStart=/bin/systemd-tmpfiles --create --remove (code=exited, status=1/FAILURE)
          CGroup: name=systemd:/system/systemd-tmpfiles-setup.service


Version-Release number of selected component (if applicable):
systemd-units-20-1.fc15.x86_64

How reproducible:
Booted once after downgrading severely broken rsyslog (bug 690250)

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 1 Lennart Poettering 2011-03-29 00:00:46 UTC
any output related to systemd-tmpfiles in syslog?

Comment 2 Horst H. von Brand 2011-03-30 23:03:57 UTC
Mar 23 07:41:53 laptop15 kernel: [   13.774091] systemd-tmpfiles[788]: Two or more conflicting lines for /var/lock/pki configured, ignoring.
Mar 23 07:41:53 laptop15 kernel: [   13.774582] systemd-tmpfiles[788]: Two or more conflicting lines for /var/run/pki configured, ignoring.
Mar 23 07:41:53 laptop15 kernel: [   13.775018] systemd-tmpfiles[788]: Two or more conflicting lines for /var/lock/pki configured, ignoring.
Mar 23 07:41:53 laptop15 kernel: [   13.775703] systemd-tmpfiles[788]: Two or more conflicting lines for /var/run/pki configured, ignoring.

Comment 3 Lennart Poettering 2011-03-31 12:29:40 UTC
could you please do:

grep pki /etc/tmpfiles.d/*

This probably lists two files with the same contents. The packages those files come from should be fixed.

Comment 4 Horst H. von Brand 2011-03-31 14:33:15 UTC
Packages with conflicting entries here are:

pki-ca-9.0.5-1.fc15.noarch
pki-kra-9.0.2-1.fc15.noarch
pki-ocsp-9.0.1-1.fc15.noarch

All specify /var/{run,lock}/pki, and from looking at the documentation this means this directory (under which they specify another) is first to be cleaned out. Sure is fishy...

Now how do I get around at having all of them cooperate creating the parent directory once? Or should each just go:

D /var/{run,lock}/pki/$PACKAGE 0755 root root -

(omitting the /var/{run,lock}/pki directory altogether for creation/cleanup), or perhaps do:

D /var/{run,lock}/pki-$PACKAGE 0755 root root -

(just do away with the pki directories altogether)?

Methinks this is something the packaging guidelines should flesh out...

Comment 5 Lennart Poettering 2011-03-31 15:14:01 UTC
hmm, so if i understood this properly then you have 3 packages which can be installed completely independently but all three need /var/run/pki?

Hmm, I guess this is a valid usecase, and we should probably allow this kind of usage and only complain if there are multiple lines listed with different parameters.

Added this to the todo list of systemd upstream.

Comment 6 Lennart Poettering 2011-04-08 02:50:13 UTC
Fixed in git.

Comment 7 Horst H. von Brand 2011-04-13 00:44:04 UTC
(In reply to comment #5)
> hmm, so if i understood this properly then you have 3 packages which can be
> installed completely independently but all three need /var/run/pki?
> 
> Hmm, I guess this is a valid usecase, and we should probably allow this kind of
> usage and only complain if there are multiple lines listed with different
> parameters.
> 
> Added this to the todo list of systemd upstream.

Yes, but the trouble is that all 3 of them ask for cleaning out the directory before use. Whoever comes last wins here, I'd assume... that's why I ask for forcing^Wasking developers politely but forcefully to RTFM to create such a setup sanely.

Comment 8 Lennart Poettering 2011-04-14 16:02:38 UTC
Hmm, I don't follow?

Note that systemd-tmpfiles first reads all data from /etc/tmpfiles.d/, and sorts out duplicates while doing so. Then, afterwards it actually goes and applies the data.

Comment 9 Horst H. von Brand 2011-04-14 18:55:48 UTC
(In reply to comment #8)
> Hmm, I don't follow?
> 
> Note that systemd-tmpfiles first reads all data from /etc/tmpfiles.d/, and
> sorts out duplicates while doing so. Then, afterwards it actually goes and
> applies the data.

My bad, sorry.

Comment 10 Horst H. von Brand 2011-04-14 19:06:27 UTC
(In reply to comment #8)
> Hmm, I don't follow?
> 
> Note that systemd-tmpfiles first reads all data from /etc/tmpfiles.d/, and
> sorts out duplicates while doing so. Then, afterwards it actually goes and
> applies the data.

What happens when a new file shows up (due to a package installation, for example) in the above scenario? The new file demands cleaning out /run/foo, as do the older others; afterwards all have to (re)populate their subdirectories of /run/foo? That can't be right if that is one-shot information like PIDs or such, or open sockets, or whatnot. I think duplicates that clean out directories here are a mistake.

BTW, as long as /run is on a tmpfs perhaps "clean out" is superfluous?

Comment 11 Lennart Poettering 2011-04-15 00:08:49 UTC
"systemd-tmpfiles --create" is independent of "systemd-tmpfiles --remove". The former really just creates dirs, the latter also empties/removes dirs as requested. The latter is really something that should only and exclusively be called at boot (and it should be combined then with --create). The former can be called from packaging scripts without bad effects. (Though quite frankly most packaging scripts can also just do an mkdir -p for most cases)

Comment 12 Horst H. von Brand 2011-04-15 12:53:21 UTC
OK. But please get prominent notices on being careful with this stuff into the packaging guidelines... and perhaps rpmlint catching them.

Thanks for your time!

Comment 13 Fedora Update System 2011-04-21 02:00:04 UTC
systemd-25-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/systemd-25-1.fc15

Comment 14 Fedora Update System 2011-04-21 03:01:31 UTC
Package systemd-25-1.fc15:
* should fix your issue,
* was pushed to the Fedora 15 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-25-1.fc15'
as soon as you are able to, then reboot.
Please go to the following url:
https://admin.fedoraproject.org/updates/systemd-25-1.fc15
then log in and leave karma (feedback).

Comment 15 Fedora Update System 2011-05-01 03:22:32 UTC
systemd-25-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.