Description of problem: i've changed my .bash_profile (regular user) and at the end, i isuued a 'sync'. the process died. # ps aux | grep sync root 17 0.0 0.0 0 0 ? S 15:26 0:00 [sync_supers] c0rnel 8057 0.0 0.0 4212 208 pts/3 D+ 16:46 0:00 sync root 9281 0.0 0.0 4740 780 pts/4 S+ 18:12 0:00 grep --color=auto sync Version-Release number of selected component (if applicable): # uname -a Linux localhost.localdomain 3.3.1-5.fc17.i686.PAE #1 SMP Tue Apr 10 21:06:28 UTC 2012 i686 i686 i386 GNU/Linux How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: i'll attach the output of echo w > /proc/sysrq-trigger and echo t > /proc/sysrq-trigger if possible :)
Created attachment 577554 [details] echo w > /proc/sysrq_trigger
Created attachment 577555 [details] echo t > ... (incomplete?) it seems that same thing happens on ext? too, as discussed on irc and mailing list.
Yeah, I see the same here on ext4... kevin 24214 0.0 0.0 106840 500 pts/18 D+ 10:35 0:00 sync
Kernel : 3.3.1-5.fc17.x86_64 RPM: coreutils-8.15-6.fc17.x86_64 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1686 0.0 0.0 106840 356 pts/1 D+ 18:23 0:00 sync How reproducible: 100% Steps to Reproduce: 1. dd if=/dev/zero of=/btrfs/test.iso bs=1M count=512 2. sync 3. sync is in "D" state
Created attachment 577565 [details] dmesg in dmesg: echo w > /proc/sysrq-trigger echo t > /proc/sysrq-trigger
812588 may be related, and seems to suggest SELinux may be at fault.
I can not reproduce this issue with SELinux disabled.
If you update to selinux-policy-3.10.0-116.fc17 (in koji) does the issue go away? This really seems like a dupe at this point.
yes, I can confirm it's fixed with the new selinux policy. Should be just a dupe of 812588.
Thanks. *** This bug has been marked as a duplicate of bug 812588 ***