Hide Forgot
Description of problem: sudo complains if auditd is not running, but still works. It says audit_log_user_command(): Connection refused Version-Release number of selected component (if applicable): sudo-1.6.9p4-2.fc8.x86_64 How reproducible: every time Steps to Reproduce: run sudo successfully Suggest removing the perror("audit_log_user_command()") in audit_logger() in the patch sudo-1.6.9p4-audit.patch. Sites that do not run auditd will thus not be bothered with the error message every time.
This problem should be fixed in sudo-1.6.9p4-3.fc8.
sudo-1.6.9p4-3.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
Just updated to sudo-1.6.9p4-3.fc8 and I am still seeing "audit_log_user_command(): Connection refused"
Yup, still complains in 1.6.9p4-3.fc8 on x86_64. Even though the netlink socket create works, a write may fail if no daemon is listening. Just ignore ECONNREFUSED too, or all errors for that matter.
today i have upgraded one of f7 to f8 running as virtual machine (UML) and i am getting the same error 'audit_log_user_command(): Connection refused' any fix for that ? sudo-1.6.9p4-3.fc8 is installed. askar
I don't know its relevant or not we have fixed the sudo error 'audit_log_user_command(): Connection refused' by compiling kernel 2.6.23 and enabled AUDITD support by 'CONFIG_AUDIT=y' sudo not any more complaining even if auitd is not running. However we where using the old kernel (for all our UML hosts) on fedora 6 , Fedora 7 and sudo was fine it start complaining after upgrading the hosts to fedora 8. thanks.
I am still getting this error on 1.6.9p4-4.fc8
I upgraded from fedora6 to fedora8. I am using version 1.6.9p4-4.fc8 (32 bit) and I am still getting the complaint.
The annoying connection error to auditd is still there in the latest updates too: blackblue 10:20:12 (Mituc):~>cat /etc/redhat-release Fedora release 8 (Werewolf) blackblue 10:20:15 (Mituc):~>sudo /bin/true audit_log_user_command(): Connection refused blackblue 10:20:19 (Mituc):~>rpm -q sudo sudo-1.6.9p4-6.fc8
(In reply to comment #1) > This problem should be fixed in sudo-1.6.9p4-3.fc8. I am unable to change the "Fixed In" field so I'm wondering if the assignee Peter Vrabec knows that it is still a problem. I'll try reassigning to the same guy...
Created attachment 309211 [details] new sudo-1.6.9p13-audit.patch This was supposedly fixed in version 1.6.9p4-5 but I can't find any changes that were actually made in that version except a changelog entry and a version number change. (but then again I'm not very good with CVS) Here's an updated version of sudo-1.6.9p13-audit.patch which adds in a check for ECONNREFUSED. I've tested it and it does solve the issue (which indeed only appears when you disable CONFIG_AUDIT, it's enabled by default in fedora kernels but not in OLPC kernels).
Created attachment 309212 [details] interdiff interdiff output showing the changes that I made to the patch
sudo-1.6.9p13-4.fc9 and sudo-1.6.9p17-1.fc10 still have this problem, and the attached patch (interdiff) fixes it.
Daniel, I would suggest to change the patch. - if( err <= 0 && !(errno == EPERM && getuid() != 0) ) + if( err <= 0 && !((errno == EPERM && getuid() > 0) || errno == ECONNREFUSED )
Sounds fine to me. OLPC no longer use this sudo package so it's not an issue for us any more...
fixed in sudo-1_6_9p17-2_fc10
sudo-1.6.9p17-5.el5 have this problem
confirming problem with sudo-1.6.9p17-5.el5
same problem solved by yum update sudo