From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc4 Firefox/1.0.6 Description of problem: Every cron job will result in two syslog messages like this: Aug 10 10:01:01 geneva crond(pam_unix)[369]: session opened for user root by (uid=0) Aug 10 10:01:01 geneva crond(pam_unix)[369]: session closed for user root It's already bad enough in the default installation, but if you run jobs every five or ten minutes, then things get out of hand. Some tools like mrtg can be run in daemon mode, but you're not always that lucky, see for example sysstat after you install its RPM. The vast majority of the text in /var/log/messages* will be pam_unix spam, which has very little useful information for the system administrator. I have searched for solutions. One floated around is to disable the "session" statement in /etc/pam.d/crond. It didn't work for me and, even if it worked, it would still look very dubious to me. Another one is to redirect or silence the messages, which is easier said than done. Initially, one would assume that crond messages would all appear in /var/log/cron. Wrong. That's not the case for the session messages, as they are created by pam_unix and their type is auth.info. It makes sense if you think about it for a while. Matching parts of the message is resource intensive; so you don't want syslogd do that. You probably don't want to redirect auth.* to a new /var/log/auth, either - or do you? You definitely to want to silence auth.info message altogether. Would it make sense to have pam_unix be able to send syslog messages with a different facility? E.g. some way in /etc/pam.d/crond to tell pam_unix to spew out cron.info syslog messages instead, so that the spam ends up in /var/log/cron, where it is more "on-topic" (even if it's really an auth notification). Version-Release number of selected component (if applicable): 0.77 How reproducible: Always Steps to Reproduce: 1. yum install sysstat (or yum install mrtg - from Extras) Actual Results: /var/log/messages gets cluttered with pam_unix noise Expected Results: pam_unix noise should be in /var/log/cron or some other log file Additional info:
Seeing this in RHEL 4 also; most junk a result of the sysstat package, which has a */10 minute cronjob. Makes logs fairly unreadable.
This can be resolved only by adding "quiet" option to pam_unix for session calls. Then you could modify /etc/pam.d/system-auth to silence these messages.
I have better idea but it would have to be accepted upstream first and it would require modification of pam patch in the cron. A PAM_LOG_ERRORS_ONLY flag could be added to PAM which services running regularly and not representing a security risk such as cron could add when PAM is called. The quiet option to pam_unix is not as useful because when added to system-auth it would silence all session calls even from daemons as ssh where the logging is useful and doesn't clutter the log file.
---- Additional Comments From corryk.com(prefers email via kevcorry.com) 2005-11-03 14:34 EDT ------- Reposting earlier comment from Emily which got missed by the mirroring tools: --- Additional Comment #2 From Emily J. Ratliff 2005-10-28 09:34 EDT ---- According to /usr/share/doc/pam-0.79/txts/README.pam_unix and the pam_unix_sess.c source, the only point to having pam_unix in the session stack is to provide this level of logging. This logging can be suppressed by commenting out the line in /etc/pam.d/crond that invokes the system-auth session stacking and uncommenting the session pam_limits line, since the only pam modules invoked in the system-auth session stack are pam_unix and pam_limits. So on a FC4 system, the /etc/pam.d/crond file would contain # # The PAM configuration file for the cron daemon # # auth sufficient pam_rootok.so auth required pam_stack.so service=system-auth auth required pam_env.so account required pam_stack.so service=system-auth account required pam_access.so #session required pam_stack.so service=system-auth session required pam_loginuid.so # To enable PAM user limits for cron jobs, # configure /etc/security/limits.conf and # uncomment this line: session required pam_limits.so #
Yes, this makes sense. It would be probably the easiest way how to resolve this bug and it shouldn't break anything.
This was fixed a long ago.