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:
any output related to systemd-tmpfiles in syslog?
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.
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.
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...
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.
Fixed in git.
(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.
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.
(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.
(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?
"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)
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!
systemd-25-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/systemd-25-1.fc15
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).
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.