Description of problem: Sometimes (I think only when selinux policies are updated) yum-cron send me an email, which does not contain information about errors, just one empty line. May be this problem should be fixed in an selinux* package, just I can't reproduce it from command line so I don't know, which command produces this empty line and also I am not sure, if it's produced by selinux. Version-Release number of selected component (if applicable): selinux-policy-targeted-3.5.13-54.fc10.noarch selinux-doc-1.26-1.1.noarch yum-cron-0.8.3-1.fc10.noarch selinux-policy-3.5.13-54.fc10.noarch selinux-policy-doc-3.5.13-54.fc10.noarch I see these problems aprox. 1/2 - 1 year ago. How reproducible: always Steps to Reproduce: I am not sure. May be downgrading selinux policy and then leave to upgrade from yum-cron. Actual results: From root.sk Wed Apr 8 06:35:35 2009 From: Cron Daemon <root.sk> Date: Wed, 8 Apr 2009 06:30:27 +0200 (CEST) To: root.sk Subject: Cron <root@ftp> run-parts /etc/cron.daily /etc/cron.daily/yum: Expected results: No email from yum-cron. Additional info: See attachment, if you need to see output in binary (all text bytes). Is it possible to add an "grep -v '^ *$'" to filter out these empty lines from output of yum-cron? May be there was similar problems with other packages. If you consider, this is not a bug of yum-cron, please change component to selinux-policy.
I can confirm this - it looks like selinux-policy-targeted's rpm install script echos a bonus newline when it shouldn't. Trying to deal with non-standard output is something I don't think should be inside yum-cron, so re-assigning this to selinux-policy-targeted for a fix in their install script of spec file.
Alec, do you have a line in the spec file that does this, or is this the output of "*" when it is relabeling that is causing the problem?
Created attachment 339190 [details] Original email with headers. Email addresses have been replaced by xxx chars.
Looking, that I forgot to attach my original email. Attached now. I tryed to run all commands from rpm -q --scripts selinux-policy-targeted from command line, but there was no similar situation after install. May be it does something different on second run or displays something different when running from cron.
When SELinux is updating a policy it will check the difference between the previous policy's file_context and the new and then run recursive "restorecon" on all the differences. If the differences are large the postinstall will output a "*" for each 10,000 files. So maybe this caused the problem?
I haven't checked all the script lines yet to tell for sure which of the two scenarios in comment #2 is right, but what I've seen is consistent with comment #5. Watching the rpm progress hash marks go, they proceed normally, then a \n, then then next rpm proceeds - so something in the %post section. Is it as simple as making sure the relabel gets called with the right level of (non) verbosity?
(In reply to comment #5) > When SELinux is updating a policy it will check the difference between the > previous policy's file_context and the new and then run recursive "restorecon" > on all the differences. If the differences are large the postinstall will > output a "*" for each 10,000 files. So maybe this caused the problem? Daniel, why are you talking about "*"s? My problem is about empty lines, not about any other characters (see attachment).
Today I updating with "yum update" (not from cron) and I see similar problem on my screen. Here is a part of my screen: Updating : tzdata-java 49/227 Updating : wine-desktop 50/227 Updating : selinux-policy 51/227 Updating : gnome-mplayer-common 52/227 Updating : kernel-tuxonice-firmware 53/227 Updating : selinux-policy-targeted 54/227 Updating : salpack 55/227 Updating : check-devel 56/227 Updating : nss-devel 57/227 Updating : libX11-devel 58/227 Updating : oxygen-icon-theme 59/227 Updating : aspell-sk 60/227 Updating : bittorrent 61/227 Updating : memtest86+ 62/227 You can see an empty line after selinux-policy-targeted. salpack is my own package, but this empty line is not from salpack.
Fixed in policycoreutils-2.0.62-10.fc11.x86_64 # restorecon -p /etc # restorecon was the culprit, Now changed to only print the \n when it has put out a '*'
Great. :) Can you please fix this for next release of fc10 (and may be fc9) package?
This bug has been reported against Fedora 10 and there are still same problems for fc10 packages. Plases, fix this for F10 too if possible. Fedora 10 will have aprox. half year of support, so this fix can be used long time. Thank you.
Created attachment 343440 [details] Do not print \n, if count < 1000; If I'm right, this patch does this magic. Miroslav, if you are too busy, I can apply it.
It should be fixed in policycoreutils-2.0.57-21.fc10 and available from updates-testing repo or from koji.
Works well on all my updated servers (aprox. 10). Please move this to stable.
I think this was already fixed. Closing this bug, reopen if still need something.