Description of problem: Calling /usr/bin/sync manually will hang up. System continues to operate and reboots normally. This happens with both kernel-3.3.1-5.fc17, kernel-3.3.2-1.fc17 Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1./usr/bin/sync 2. 3. Actual results: Command does not return Expected results: command ends. Additional info: strace sync execve("/usr/bin/sync", ["sync"], [/* 53 vars */]) = 0 brk(0) = 0x175e000 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa7be34a000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=134043, ...}) = 0 mmap(NULL, 134043, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fa7be329000 close(3) = 0 open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0@\30\342\257<\0\0\0"..., 832) = 832 fstat(3, {st_mode=S_IFREG|0755, st_size=2065568, ...}) = 0 mmap(0x3cafe00000, 3892376, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x3cafe00000 mprotect(0x3caffac000, 2097152, PROT_NONE) = 0 mmap(0x3cb01ac000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1ac000) = 0x3cb01ac000 mmap(0x3cb01b2000, 17560, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x3cb01b2000 close(3) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa7be328000 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fa7be326000 arch_prctl(ARCH_SET_FS, 0x7fa7be326740) = 0 mprotect(0x604000, 4096, PROT_READ) = 0 mprotect(0x3cb01ac000, 16384, PROT_READ) = 0 mprotect(0x3caf81f000, 4096, PROT_READ) = 0 munmap(0x7fa7be329000, 134043) = 0 brk(0) = 0x175e000 brk(0x177f000) = 0x177f000 brk(0) = 0x177f000 open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=105038240, ...}) = 0 mmap(NULL, 105038240, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fa7b7ef9000 close(3) = 0 sync( Remark: Hangs here!
Thanks for report, but I doubt this is a problem of coreutils sync command - as this is only a wrapper of the sync() syscall - and the commands hangs there. Reassigning to kernel. Meanwhile - is there something special on your system (I mean nondefault filesystem)? It is not clear from your report and might be important for kernel devels.
mount proc on /proc type proc (rw,nosuid,nodev,noexec,relatime) sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime,seclabel) devtmpfs on /dev type devtmpfs (rw,nosuid,relatime,seclabel,size=1660876k,nr_inodes=415219,mode=755) devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,seclabel,gid=5,mode=620,ptmxmode=000) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,relatime,seclabel) tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,seclabel,mode=755) /dev/sda7 on / type ext4 (rw,relatime,seclabel,user_xattr,barrier=1,data=ordered) selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime) tmpfs on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,seclabel,mode=755) cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd) cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset) cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct,cpu) cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory) cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices) cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer) cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls) cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio) cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,perf_event) systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=28,pgrp=1,timeout=300,minproto=5,maxproto=5,direct) debugfs on /sys/kernel/debug type debugfs (rw,relatime) hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,seclabel) configfs on /sys/kernel/config type configfs (rw,relatime) tmpfs on /media type tmpfs (rw,nosuid,nodev,noexec,relatime,seclabel,mode=755) securityfs on /sys/kernel/security type securityfs (rw,relatime) mqueue on /dev/mqueue type mqueue (rw,relatime,seclabel) binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime) /dev/sda5 on /disk2 type ext4 (rw,relatime,seclabel,user_xattr,acl,barrier=1,data=ordered) /dev/sdb2 on /DISK2_BACKUP type ext4 (rw,relatime,seclabel,user_xattr,acl,barrier=1,data=ordered) /dev/sdb1 on /VBOX_BACKUP type ext4 (rw,relatime,seclabel,user_xattr,acl,barrier=1,data=ordered) /dev/sdb6 on /tmp type ext4 (rw,relatime,seclabel,user_xattr,acl,barrier=1,data=ordered) /dev/sdb3 on /SYSTEM_BACKUP type ext4 (rw,relatime,seclabel,user_xattr,acl,barrier=1,data=ordered) /dev/sda6 on /vbox type ext4 (rw,relatime,seclabel,user_xattr,acl,barrier=1,data=ordered)
Two hints: I'm wondering about 1. The system reboots normally without any delay, even though reboot uses sync (this is my knowledge). 2. Only a hint: additionally, pm-hibernate does not hibernate my box: it remains hanging in the pm-hibernate-command, but the box does not switch off. And I assume it should sync the filesystems.
Seems to be related to fusermount: running the ps command shows a running usermount process (00:00:00 fusermount -o rw,nosuid,nodev,subtype=gvfs-fuse-daemon -- /run/user/backes/gvfs) Killing this process lets run sync flawlessly. See http://lists.fedoraproject.org/pipermail/test/2012-April/106907.html (Thanks to Kalev Lember who found out the coherence).
*** Bug 812569 has been marked as a duplicate of this bug. ***
Actually my Z800 x86_64 box is seeing this issue. For my box killing fusermount does not recover this issue (maybe because it seems that killing fusermount again launches fusermount). Strangely, when booting with "init 3", sync command succeeds, however with graphical mode, sync hangs.
Well, with 3.10.0-114.fc17 killing fusermount with -SIGKILL see the error(?) message like [ 350.681284] SELinux: (dev fuse, type fuse) getxattr errno 4 and downgrading selinux-policy\* from 3.10.0-114.fc17 to -110 fixes this issue (for me). Once adding mgrepl to cc list.
(In reply to comment #7) > and downgrading selinux-policy\* from 3.10.0-114.fc17 to -110 and rebooting fixes this issue
Sounds like bug 808795. Do you have stray jbd2 processes hanging around for file systems that have already been umounted?
(In reply to comment #9) > Sounds like bug 808795. Do you have stray jbd2 processes hanging around for > file systems that have already been umounted? I am afraid I don't know (in the meaning that I don't know how to judge it).
Use ps or lsof. There are examples in both that bug report and the two that were already closed duplicate of it.
Sync also hangs when there are hanging FUSE mounts (bug 812798). Whether it's the same issue or not I don't know. You can easily test if it's bug 812798 by disabling (*NOT* permissive) selinux.
Downgrading selinux-policy from -114 to -110 fixes the issue in bug 812798 also for me. Anyone mind if we reassign this bug to selinux-policy?
Please, could you test it with the latest policy -115.fc17 which is available from koji.
I will try tomorrow (in Japan)
(In reply to comment #14) > Please, > could you test it with the latest policy -115.fc17 which is available from > koji. I installed selinux-policy-3.10.0-115.fc17.noarch selinux-policy-doc-3.10.0-115.fc17.noarch selinux-policy-devel-3.10.0-115.fc17.noarch selinux-policy-targeted-3.10.0-115.fc17.noarch but I'm sorry, -115 does not fix this BZ :-( /usr/bin/sync still hangs, and there is still a fusermount present ( fusermount -o rw,nosuid,nodev,subtype=gvfs-fuse-daemon -- /run/user/backes/gvfs )
With selinux-policy-3.10.0-116.fc17 this seems no longer reproducible.
For record: https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-116.fc17
(In reply to comment #17) > With selinux-policy-3.10.0-116.fc17 this seems no longer reproducible. I can confirm this!
*** Bug 812638 has been marked as a duplicate of this bug. ***
*** Bug 812918 has been marked as a duplicate of this bug. ***
I found this sync hang was blocking suspend/hibernate in F17 for me. selinux-policy-3.10.0-116.fc17 makes suspend work again \o/
*** Bug 813791 has been marked as a duplicate of this bug. ***
thanks, that fixes it, fiou!
*** Bug 814056 has been marked as a duplicate of this bug. ***
*** Bug 813822 has been marked as a duplicate of this bug. ***
Works for me with selinux-policy-3.10.0-116.fc17. Thanks!
selinux-policy-3.10.0-117.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-117.fc17
selinux-policy-3.10.0-118.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-118.fc17
Package selinux-policy-3.10.0-118.fc17: * should fix your issue, * was pushed to the Fedora 17 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing selinux-policy-3.10.0-118.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2012-6452/selinux-policy-3.10.0-118.fc17 then log in and leave karma (feedback).
selinux-policy-3.10.0-118.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.