Hide Forgot
Thought it was a fluke once, but now it's happened on 2 boxes of ours. Trying to update to selinux-policy-targeted-2.6.4-49.fc7 simply hangs (ok, takes longer than 12 hours, which is how long I waited). The first hang I saw was on a i386 box, this last on x86_64. All I can see is a related processes that doesn't finish: root 16658 0.0 0.0 72464 1224 pts/4 T Nov05 0:00 /bin/sh /sbin/fixfiles -C /etc/selinux/targeted/contexts/files/file_contexts.pre restore root 16685 0.0 0.0 72464 664 pts/4 T Nov05 0:00 /bin/sh /sbin/fixfiles -C /etc/selinux/targeted/contexts/files/file_contexts.pre restore
Just had a 3rd machine trying to update and hang. Bad.
This is *really* bad. :( Confirmed hangs on i386 and x86_64 when running "yum update" on F7 machines. root 31923 31914 0 09:13 pts/3 00:00:00 /bin/sh /sbin/fixfiles -C /etc/selinux/targeted/contexts/files/file_contexts.pre restore root 31950 31923 0 09:13 pts/3 00:00:00 /bin/sh /sbin/fixfiles -C /etc/selinux/targeted/contexts/files/file_contexts.pre restore root 31951 31923 1 09:13 pts/3 00:01:19 /sbin/restorecon -v -f - I will leave my processes in their hung state for a while if anyone needs info to help debug this, (e.g. I could attach gdb to restorecon, if someone thought that would help) just contact me. Otherwise, does anyone have advice on how to gracefully recover from the hung update?
Yes Is the process continuing to execute? This procedure it to attempt to check the previous version of file context versus the new and then run restorecon/fixfiles on the difference. This could take some time but not 12 hours. Do you see disk activity and does top show restorecon running?
I saw no activity (nothing on top, hd disk light off)
This is strange we just tried it here and it went fine. selinux-policy-2.6.4-48 - selinux-policy-2.6.4-49
Which policycoreutils do you have installed?
rpm -q policycoreutils policycoreutils-2.0.16-11.fc7
same here, policycoreutils-2.0.16-11.fc7, and no disk or cpu load. Daniel, feel free to ping me (shoe) in #fedora, for more info, too.
This turns out to be a yum/rpm python binding problem. If a package that you are updating spews lots of data, yum gets into a dead lock situation.
Created attachment 249561 [details] source for a package which triggers the error on my test system This triggers the behavior when SELinux doesn't prevent the %post script's output from being handed to yum (permissive mode, though I imagine SELinux disabled would show identical behavior).
I am removing -v from fixfiles in policycoreutils to stop selinux from triggering this error. But if this screwed you environment. http://skvidal.wordpress.com/2006/12/04/re-wow/ Might help.
Confirmed, guilty, my boxes in question are running in permissive mode.
fwiw, it's not a good idea for pkg scriptlets to be spewing much, if any, output anyway.
Fixed in upstream yum, we'll be pushing an updated package in the near-ish future (have another bug we're trying to track down first). Dan has also made the policy package spew less to make this less likely.
*** Bug 376071 has been marked as a duplicate of this bug. ***
yum-3.2.7-2.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
yum-3.2.7-2.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.