My disk doesn't stay spun-down very long, even with laptop-mode.  I
discovered the problem was syslog doing syncs to auth.log whenever a
cron job runs.  (I have a package, lockout, that runs a cron job every
minute.)  cron logs to auth.log because it has "@include common-session"
in its PAM config, and common-session uses pam_unix.  The log lines look
like

    Feb  1 20:07:01 localhost CRON[25041]: (pam_unix) session opened for user root by (uid=0)
    Feb  1 20:07:01 localhost CRON[25041]: (pam_unix) session closed for user root

I would suggest leaving common-session out of the PAM config, because a
cron job is not really a session in the normal sense.  It really doesn't
make sense for every cron job to be logged in auth.log.  (If you want to
log them, daemon.log would probably be better.)

Another way to solve my problem would be to change syslog.conf so that
auth.log is not synced.  However, this seems sub-optimal because real
authorization events are pretty important.

Andrew

I don't think the change requested in this bug report should be made
(actually, it's at odds with bug #543303 that I've just filed).  I believe
that in the general case, we do want pam_unix logging here, just as we do
for any other sort of session; and there are other sorts of session modules
that might be included in /etc/pam.d/common-session{,-noninteractive} that
could be significantly more important to operation of the service.

I think your use case (cronjob running every minute, but wanting to keep the
disk spun down for powersaving reasons) is an exceptional one, and the sort
of use case best supported by availing yourself of /etc/pam.d/cron's
conffile status (i.e.: edit the file to taste).

I don't think the change requested in this bug report should be made
(actually, it's at odds with bug #543303 that I've just filed).  I believe
that in the general case, we do want pam_unix logging here, just as we do
for any other sort of session; and there are other sorts of session modules
that might be included in /etc/pam.d/common-session{,-noninteractive} that
could be significantly more important to operation of the service.

I think your use case (cronjob running every minute, but wanting to keep the
disk spun down for powersaving reasons) is an exceptional one, and the sort
of use case best supported by availing yourself of /etc/pam.d/cron's
conffile status (i.e.: edit the file to taste).

I agree with the OP.  Logging cron events here is better avoided.
I often have multiple lines in each cron job, and each gets it's own
auth.log line
(multiple rows per second).

Log spam makes it harder to monitor and extract useful information from
logs.

And, at the very least, this change should be part of any laptop variant
of the OS
(along with noatime, etc).

I can verify that editing /etc/pam.d/cron and commenting out @include
common-session supresses lines like this from /var/log/auth.log:

Jan 17 06:30:01 u2 CRON[26443]: pam_unix(cron:session): session closed
for user production
Jan 17 06:30:01 u2 CRON[26453]: pam_unix(cron:session): session opened
for user production by (uid=0)
Jan 17 06:30:01 u2 CRON[26459]: pam_unix(cron:session): session opened
for user production by (uid=0)
Jan 17 06:30:01 u2 CRON[26453]: pam_unix(cron:session): session closed
for user production
Jan 17 06:30:01 u2 CRON[26463]: pam_unix(cron:session): session opened
for user production by (uid=0)
Jan 17 06:30:01 u2 CRON[26469]: pam_unix(cron:session): session opened
for user production by (uid=0)

Keywords: auth.log filling up, laptop won't spin down, log spam,
excessive logging, Ubuntu, Debian, pam, pluggable authentication
modules, pam_unix, cron.

FWIW, this bug is the same as one reported in Red Hat in
https://bugzilla.redhat.com/show_bug.cgi?id=165571 (they 'fixed' this
through PAM, see below)

Since the 3.0pl1-107 package release of cron cron uses
'common-session-noninteractive' in its PAM configuration instead of
'common-session'.

I see several ways to prevent cron logs from generating auth.log entries:

 - Remove the pam_unix call in common-session-noninteractive, so that
   NO logging is produced when cron starts up a job

 - (better yet) Use a PAM configuration that will avoid cron from generating
   any logging but will log for other (non-interactive) programs. This
   is what Red Hat does.

   In Debian, to do this add the following line before the pam_unix.so call
   in /etc/pam.d/common-session-noninteractive:

------------------------------------------------------------------------------------
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
------------------------------------------------------------------------------------

 - Use a syslog daemon that supports filtering (such as rsyslog or syslog-ng)
   and filter out these messages.

   For example, with syslog-ng it looks like this can be done with

------------------------------------------------------------------
# all messages from the auth and authpriv facilities
filter f_auth { facility(auth, authpriv);};

#filter the CRON messages
filter f_cron_msgs { not match("CRON*"); };

# auth,authpriv.*                 /var/log/auth.log
# + filter the CRON messages out
log {
        source(s_all);
        filter(f_auth);
        filter(f_cron_msgs);
        destination(df_auth);
};
------------------------------------------------------------------

    Hope this helps.


    Regards

    Javier

FWIW, this bug is the same as one reported in Red Hat in
https://bugzilla.redhat.com/show_bug.cgi?id=165571 (they 'fixed' this
through PAM, see below)

Since the 3.0pl1-107 package release of cron cron uses
'common-session-noninteractive' in its PAM configuration instead of
'common-session'.

I see several ways to prevent cron logs from generating auth.log entries:

 - Remove the pam_unix call in common-session-noninteractive, so that
   NO logging is produced when cron starts up a job

 - (better yet) Use a PAM configuration that will avoid cron from generating
   any logging but will log for other (non-interactive) programs. This
   is what Red Hat does.

   In Debian, to do this add the following line before the pam_unix.so call
   in /etc/pam.d/common-session-noninteractive:

------------------------------------------------------------------------------------
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
------------------------------------------------------------------------------------

 - Use a syslog daemon that supports filtering (such as rsyslog or syslog-ng)
   and filter out these messages.

   For example, with syslog-ng it looks like this can be done with

------------------------------------------------------------------
# all messages from the auth and authpriv facilities
filter f_auth { facility(auth, authpriv);};

#filter the CRON messages
filter f_cron_msgs { not match("CRON*"); };

# auth,authpriv.*                 /var/log/auth.log
# + filter the CRON messages out
log {
        source(s_all);
        filter(f_auth);
        filter(f_cron_msgs);
        destination(df_auth);
};
------------------------------------------------------------------

    Hope this helps.


    Regards

    Javier

Sorry, for Debian this should have been:

---------------------------------------------------------------------------------------
session     [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid
---------------------------------------------------------------------------------------

I.e. 'cron' instead of 'crond', as the 'service' file is /etc/pam.d/cron

The previous definition was specific to RedHat.

Regards

Javier

Sorry, for Debian this should have been:

---------------------------------------------------------------------------------------
session     [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid
---------------------------------------------------------------------------------------

I.e. 'cron' instead of 'crond', as the 'service' file is /etc/pam.d/cron

The previous definition was specific to RedHat.

Regards

Javier

Hello,


It would be nice to have the solution proposed by Javier
Fernandez-Sanguino Peña on #36.

If the cron is running frequently, it can generate a lot of messages. As
example, on systems with limited resources, those messages can be can be
worthless.

In the case that the current behaviour is needed, that line can be
easily commented.


Thanks,

Works fine on Debian 12.