Red Hat Bugzilla – Bug 1282981
Default permissions on /dev/shm prevent some applications from starting
Last modified: 2016-06-27 06:07:23 EDT
Created attachment 1095754 [details]
Backtrace from attempting to start domain
Description of problem:
Unable to start libvirt guests in this kernel version, starts fine kernel 4.3.0-0.rc7.git0.1.fc24.x86_64. Have eliminated selinux as a culprit.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. boot with listed kernel
2. use virsh start <domain>
Unsure how to create a domain without spice
Bug not present in 4.4.0-0.rc0.git5.1
I'm able to run qemu manually and connect with spice server on -rc1. Is git5 the last of the snapshots that was working (i.e. git6 starts to fail)? Can you share your systemlogs as well?
Adding libvirt maintainers to see if they have any ideas.
FWIW There's a known kvm kernel regression tracked here:
But this sounds different. shm_open failing makes me think non-virt-related kernel issue
Created attachment 1097552 [details]
journalctl since 2015-11-17
This is a complete dump of my logs which starts a day earlier than this bug, up until now. Unfortunately, I did not have git6 installed, so I cannot tell you whether git5 was the last one working.
There are a bunch of messages there about shm_open failing with permission denied so I don't think it's qemu specific. What does 'mount' look like on your system?
Created attachment 1097916 [details]
I think you are right, I've just found out that google chrome fails to start with similar errors:
shm_open() failed: Permission denied
[2408:2408:1124/101443:ERROR:shared_memory_posix.cc(290)] Creating shared memory in /dev/shm/.com.google.Chrome.6sbRj4 failed: Permission denied
[2408:2408:1124/101443:ERROR:shared_memory_posix.cc(293)] Unable to access(W_OK|X_OK) /dev/shm: Permission denied
[2408:2408:1124/101443:FATAL:shared_memory_posix.cc(295)] This is frequently caused by incorrect permissions on /dev/shm. Try 'sudo chmod 1777 /dev/shm' to fix.
Aborted (core dumped)
So running the command suggested allows both VMs to start and google chrome to launch, but this change is only temporary. Amending title.
What's the output of mount? What about ls -lZd /dev/shm?
mount is as attached previously, ls -lZd /dev/shm:
drwxr-xr-t. 2 root root system_u:object_r:tmpfs_t:s0 60 Nov 24 12:51 /dev/shm
Sorry, I missed the mounts attachment. That looks okay but it looks like something is mounting /dev/shm with the wrong permissions. This isn't in the kernel but I think in systemd which is responsible for this now a days. Moving to systemd.
Not sure this is strictly a systemd problem.
The permissions issue started with the 4.4 kernels.
If I boot back to 4.2.0-1.fc24.x86_64 on the same machine the problem goes away. It returns again on a reboot to a 4.4 kernel.
You likely have an older systemd binary in the initramfs for 4.2.0-1.fc24. You can probably tell by looking at the boot output for each.
Hm, fedora-import-state. We had some bugs previously where f-i-s would clobber permissions (#1149419), this could be something similar. Do you need f-i-s? Does the problem still occur with f-i-s disabled (systemctl mask fedora-import-state.service)?
*** Bug 1289232 has been marked as a duplicate of this bug. ***
masking fedora-import-state.service does seem to fix it.
Seems to have been fixed.
Updated to kernel 4.5.0-0.rc0.git1.1 (unsure about initscript versioning)
This was likely 'fixed' by https://git.kernel.org/cgit/boot/dracut/dracut.git/commit?id=e93ff1cf9aac8f97131b3101a5da240ce5f45239 , and has since been broken again by https://git.kernel.org/cgit/boot/dracut/dracut.git/commit?id=b99e72427b517dea0d91d15fe43cf0a37420af36 ; see https://bugzilla.redhat.com/show_bug.cgi?id=1347436 .
dracut should not create a world writable directory under /run/initramfs.
This fedora-import-state should make an exception for /dev/shm while copying state from /run/initramfs/state.
dracut patch could be reverted, if systemd had commit cacf980ed44a28e276a6cc7f8fc41f991e2ab354, which relabels /dev/shm