[root@infinity duff]# systemctl status systemd-tmpfiles-setup-dev.service systemd-tmpfiles-setup-dev.service - Create static device nodes in /dev Loaded: loaded (/usr/lib/systemd/system/systemd-tmpfiles-setup-dev.service; static) Active: failed (Result: exit-code) since lun 2014-08-18 11:13:43 ART; 2min 22s ago Docs: man:tmpfiles.d(5) man:systemd-tmpfiles(8) Process: 373 ExecStart=/usr/bin/systemd-tmpfiles --prefix=/dev --create (code=exited, status=1/FAILURE) Main PID: 373 (code=exited, status=1/FAILURE) ago 18 11:13:43 infinity systemd-tmpfiles[373]: Failed to open '/usr/lib/tmpfiles.d/initscripts.conf', ignoring: Permission denied ago 18 11:13:43 infinity systemd[1]: systemd-tmpfiles-setup-dev.service: main process exited, code=exited, status=1/FAILURE ago 18 11:13:43 infinity systemd[1]: Failed to start Create static device nodes in /dev. ago 18 11:13:43 infinity systemd[1]: Unit systemd-tmpfiles-setup-dev.service entered failed state.
Any idea why your /usr/lib/tmpfiles.d/initscripts.conf file is not accessible? Does it work with selinux disabled? Anyway, reassigning to initscripts, which owns the package. If the access rights are correct there, then please reassing to the selinux policy.
(In reply to Lennart Poettering from comment #1) > Any idea why your /usr/lib/tmpfiles.d/initscripts.conf file is not > accessible? No, but I'm having some problems too with auditd.service. > Does it work with selinux disabled? And, yeah, I'll try to explain how I get rid of this error: 1. reboot, after second boot that error is gone (pretty interesting right?), and 2. disabling SELinux, after disabling SELinux, almost every service work OK, I need to disable SELinux to active auditd for example, reboot just work with systemd-tmpfiles-setup-dev.service. > Anyway, reassigning to initscripts, which owns the package. If the access > rights are correct there, then please reassing to the selinux policy. How I can do that?
(In reply to Duff Padmasana from comment #2) > (In reply to Lennart Poettering from comment #1) > > Any idea why your /usr/lib/tmpfiles.d/initscripts.conf file is not > > accessible? There's nothing special about the file... -rw-r--r--. root root system_u:object_r:lib_t:s0 /usr/lib/tmpfiles.d/initscripts.conf > No, but I'm having some problems too with auditd.service. If you mean the warning 'systemd[1]: Configuration file /usr/lib/systemd/system/auditd.service is marked world-inaccessible. This has no effect as configuration data is accessible via APIs without restrictions. Proceeding anyway.', then this only a packaging issue, and you can safely ignore it. > > Does it work with selinux disabled? > And, yeah, I'll try to explain how I get rid of this error: 1. reboot, after > second boot that error is gone (pretty interesting right?), and 2. disabling > SELinux, after disabling SELinux, almost every service work OK, I need to > disable SELinux to active auditd for example, reboot just work with > systemd-tmpfiles-setup-dev.service. > > > Anyway, reassigning to initscripts, which owns the package. If the access > > rights are correct there, then please reassing to the selinux policy. > How I can do that? Done now.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #3) > If you mean the warning 'systemd[1]: Configuration file > /usr/lib/systemd/system/auditd.service is marked world-inaccessible. This > has no effect as configuration data is accessible via APIs without > restrictions. Proceeding anyway.', then this only a packaging issue, and you > can safely ignore it. [root@infinity duff]# systemctl status auditd.service auditd.service - Security Auditing Service Loaded: loaded (/usr/lib/systemd/system/auditd.service; enabled) Active: failed (Result: exit-code) since lun 2014-08-18 21:00:38 ART; 12s ago Process: 2664 ExecStartPost=/sbin/auditctl -R /etc/audit/audit.rules (code=exited, status=0/SUCCESS) Process: 2663 ExecStart=/sbin/auditd -n (code=exited, status=6) Main PID: 2663 (code=exited, status=6) ago 18 21:00:38 infinity auditctl[2664]: No rules ago 18 21:00:38 infinity auditctl[2664]: AUDIT_STATUS: enabled=0 flag=1 pid=0 rate_limit=0 backlog_limit=320 lost=0 backlog=0 ago 18 21:00:38 infinity systemd[1]: Started Security Auditing Service. ago 18 21:00:38 infinity systemd[1]: auditd.service: main process exited, code=exited, status=6/NOTCONFIGURED ago 18 21:00:38 infinity systemd[1]: Unit auditd.service entered failed state. I don't really know what's the problem, if I can remember, chronyd and auditd had a problem on my machine, every time I check out for their status said that had no access to /var/logs/theirfile, with chronyd the only thing that I did was nano /var/logs/thefile and save it as root, now chronyd works OK, tried with auditd but as you can see it shows an error that I just can't understand, I'm just an average user.
(In reply to Duff Padmasana from comment #4) > ago 18 21:00:38 infinity auditctl[2664]: No rules > ago 18 21:00:38 infinity auditctl[2664]: AUDIT_STATUS: enabled=0 flag=1 > pid=0 rate_limit=0 backlog_limit=320 lost=0 backlog=0 > ago 18 21:00:38 infinity systemd[1]: Started Security Auditing Service. > ago 18 21:00:38 infinity systemd[1]: auditd.service: main process exited, > code=exited, status=6/NOTCONFIGURED > ago 18 21:00:38 infinity systemd[1]: Unit auditd.service entered failed > state. That's strange. What does 'rpm -V audit' say (run as root)?
Are you getting AVC or USER_AVC msgs in permissive mode?
I doubt policy allows systemd-tmpfs_t to create devices in /dev.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #5) > That's strange. What does 'rpm -V audit' say (run as root)? [root@infinity duff]# rpm -V audit S.5....T. c /etc/audit/auditd.conf (In reply to Miroslav Grepl from comment #6) > Are you getting AVC or USER_AVC msgs in permissive mode? I'll attach every msg that I have.
Created attachment 928487 [details] d-bus
Created attachment 928488 [details] systemdreadhe
Created attachment 928489 [details] abrt
Created attachment 928490 [details] python
Get the output of ausearch -m avc,user_avc -i -ts today
(In reply to Daniel Walsh from comment #13) > Get the output of > ausearch -m avc,user_avc -i -ts today [root@infinity duff]# ausearch -m avc,user_avc -i -ts today /var/log/audit/audit.log permissions should be 0600 or 0640 NOTE - using built-in logs: /var/log/audit/audit.log <no matches>
Try without -ts today
(In reply to Daniel Walsh from comment #15) > Try without -ts today [root@infinity duff]# ausearch -m avc,user_avc -i /var/log/audit/audit.log permissions should be 0600 or 0640 NOTE - using built-in logs: /var/log/audit/audit.log <no matches>
Ok it looks like there are dontaudit rules covering this up. semodule -DB WIll remove the dontaudit rules. See if you can trigger the failure, and then get the output of the ausearch command. semodule -B Will turn back on the dontaudit rules.
(In reply to Daniel Walsh from comment #17) > Ok it looks like there are dontaudit rules covering this up. > > semodule -DB > > WIll remove the dontaudit rules. See if you can trigger the failure, and > then get the output of the ausearch command. > > semodule -B > > Will turn back on the dontaudit rules. [root@infinity duff]# ausearch -m avc,user_avc -i /var/log/audit/audit.log permissions should be 0600 or 0640 NOTE - using built-in logs: /var/log/audit/audit.log <no matches> lel. Sorry guys, I can't reply this bug anymore, I'm having too much problems with my Fedora system, don't know why, it works slow, buggy, etc (something with that only happens when I use Netinstall) I'll stay in other distro, see you on Fedora 21 guys.
Created attachment 1428717 [details] updated.txt After today's update of my Rawhide (f29) machine (list of updated packages attached) I could not boot the machine with the same error as this bug is about. I see a significant CPU usage too. Disabling SELinux makes the machine work reliably again, or at least it boots as before. I do not know whether you are still interested in this, thus I'm not reopening the bug report, neither I file any new. I can run some tests, if you'd like too, I guess, but I'd need some babysitting with it, because SELinux world is a blackbox for me.
The logs from the failed boot would be interesting. Without that it's hard to say much.
Sure, I can provide it, but here comes the babysitting part. What is the command, the one in comment #13 or any other? Note the machine doesn't boot at all, it repeats the error message (see bug Summary) at least three times, then it just freezes and/or simply does nothing. Thus the log should be for the previous boot attempt, not for the current, when I've disabled SELinux and can boot the machine.
First try 'journalctl -b-1'. If that looks like the previous boot, then please attach that. But unfortunately it's possible that the previous boot did not get far enough for the logs to be stored. In that case, see https://www.freedesktop.org/wiki/Software/systemd/Debugging/#earlydebugshell. Essentially, the idea is to boot with 'systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M printk.devkmsg=on systemd.debug-shell' appended to the kernel command line and save the logs from the emergency shell under alt-f9.
Created attachment 1428749 [details] screenshot I enabled SELinux and restarted the machine. After it it partly recovered and relabeled the file system, then it restarted itself. After confirming which kernel to boot, I see this. One thing, after that: [ OK ] Started User Manager for UID 42. line the CPU usage went significantly high and the screen didn't move further. I left it for some time, maybe 1:33 minute (time taken from the screen shot), then the screen had been filled with the rest of the text and the CPU is still high, for the whole time me taking the screen shot and writing this comment, which is in minutes. I'm going to reboot the machine, turn off the SELinux and grab the logs you and the text in the screen shot suggest.
Created attachment 1428750 [details] journal.txt > First try 'journalctl -b-1'. If that looks like the previous boot, then > please attach that. Here you are. Let me know if more detailed info would be needed. I cut the log, because it had like 9MB, full of gnome-shell claiming problem opening a /tmp file and other related errors, which makes sense due to earlier failures.
Created attachment 1429010 [details] systemd-tmpfiles-setup-dev journalctl output I'm seeing the exact same behaviour on Rawhide (4.17.0-0.rc1.git3.1.fc29.x86_64) with SELinux (selinux-policy-3.14.2-14.fc29.noarch) and systemd-tmpfiles-setup-dev.service and systemd-tmpfiles-setup.service -- including the high CPU spike when trying to start GDM at the end of the boot process. I've attached the logs from systemd-tmpfiles-setup-dev.service and would be happy to provide any others you may want
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 29 changed to end-of-life (EOL) status on 2019-11-26. Fedora 29 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.