There might be situations where your messages directory is full of
crond(pam_unix) session closed for user root messages.
For example, the
/var/log/messages directory might be full of message like the following:
crond(pam_unix) ... session closed for user root
On Acoustic™ Tealeaf CX Passive Capture Application servers running Red Hat Enterprise Linux™ 4, messages of the following types are common in /var/log/messages:
# fgrep crond /var/log/messages | tail -5 Sep 6 16:23:02 ganymede crond(pam_unix): session closed for user root Sep 6 16:24:01 ganymede crond(pam_unix): session opened for user root by (uid=0) Sep 6 16:24:03 ganymede crond(pam_unix): session closed for user root Sep 6 16:25:01 ganymede crond(pam_unix): session opened for user root by (uid=0) Sep 6 16:25:02 ganymede crond(pam_unix): session closed for user root
On machine ganymede, all the messages are these
crond(pam_unix) messages. Consider the following count of the lines with these messages:
# fgrep crond /var/log/messages | wc -l 13233 # wc -l /var/log/messages 13241 /var/log/messages
The inclusion of the
pam_unix text hints that this message is coming from the PAM configuration for the machine. Looking in
/etc/pam.d reveals a crond file whose contents describe it as, "The PAM configuration file for the cron daemon."
Verify if this configuration file is owned by some RPM package:
# rpm -qf /etc/pam.d/crond vixie-cron-4.1-36.EL4 # rpm -ql vixie-cron | fgrep pam /etc/pam.d/crond
/etc/pam.d/crond file does not exist in an RHEL 3 Update 5 machine:
# rpm -q vixie-cron vixie-cron-3.0.1-76_EL3 # rpm -ql vixie-cron | fgrep pam #
It seems likely that these
crond(pam_unix) messages start appearing in RHEL 4 because of a change that is introduced by the newer vixie-cron package.
The manual page for crond on RHEL 4 also documents this relationship (from "man crond"):
PAM Access Control On Red Hat systems, crond now supports access control with PAM - see pam(8). A PAM configuration file for crond is installed in /etc/pam.d/crond. crond loads the PAM environment from the pam_env module, but these can be overriden by settings in the crontab file.
An Internet search for
crond(pam_unix) messages /etc/pam.d/crond reveals that many users are running into this situation with the PAM configuration in vixie-cron triggering messages in
See the solutions in the following topics.
crond message logging
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 starts the system-auth session stacking and uncommenting the session
pam_limits line, since the only pam modules started in the system-auth session stack are
On a RedHat ES4 system, the
/etc/pam.d/crond file should contain as follows:
# # 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 # Restart crond daemon: service crond restart
cron messages to a different log file
Another solution to an influx of
cron is to redirect the messages to a different log file.
cron messages to a different log file
# Log anything (except mail) of level info or higher. # Don't log private authentication messages. *.info;mail.none;local5.none;authpriv.none;cron.none;auth.!=info /var/log/messagesNote: The config line has just
- Log cron auth messages in a separate file. Add the following lines:
service syslog restartthe syslog messages caused by cron appear in