Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Two times every minute I get this in auth.log:

May 12 15:21:01 ruptai CRON[25303]: pam_unix(cron:session): session opened for user root by (uid=0)
May 12 15:21:01 ruptai CRON[25303]: pam_unix(cron:session): session closed for user root

This never stops, two times every minute, every minute of every day.

I've no idea what it is, I would just to stop it from pointless logging this stuff. This has been going on for ages so I can't recall when it started.

OS is debian stable.

Btw, I've found questions on google but no answers

Update:

On /etc/pam.d/ there are, among other things, four files named common-* that are included by the others.

common-auth:

auth    required        pam_unix.so md5

common-account:

account required        pam_unix.so md5

common-session:

session required        pam_unix.so md5

common-password:

password   required   pam_unix.so nullok obscure min=4 max=8 md5

(I tried adding that line to common-session but to no avail)

share|improve this question

3 Answers 3

up vote 4 down vote accepted

Javier gave a Debian specific answer there: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=293272#36

I added this at the beginning of /etc/pam.d/cron on a Lenny system and it worked (I restarted cron but I don't know if that was necessary):

session     [success=1 default=ignore] pam_succeed_if.so service in cron quiet use_uid
share|improve this answer
    
looks like it works, thanks! –  Lohoris Jun 15 '11 at 12:23
    
Note that the linked page specifies that the edit should occur in /etc/pam.d/common-session-noninteractive ; /etc/pam.d/cron (as well as /etc/pam.d/samba) @include this file. –  mikewaters Jun 23 '11 at 18:44
    
I had this problem licked, somehow, but a recent upgrade of the Debian distro to a new release reverted the change. Looking at /etc/pam backups, it's not obvious what I had done; it wasn't the above, though. –  Kaz Jul 17 at 23:26
    
This solution, as presented, is not working on Debian Squeeze. mikewaters above has the right clue. –  Kaz Jul 31 at 22:33

This is the relevant portion of /etc/pam.d/password-auth on a Fedora system with a silent crond:

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

The important line is the third one. Put that in the appropriate location in Debian's PAM config and that should shut it up.

share|improve this answer
    
that's a better solution... hopefully the cron process running as root every minute is a benign one. –  cpbills May 12 '10 at 23:35
    
It's probably something silly like sa or sysstat or whatever it's called. –  Ignacio Vazquez-Abrams May 12 '10 at 23:45
    
mmmh... I've tried to add it to /etc/pam.comf but it had no effect. On the other hand there are 36 files in /etc/pam.d and I've no clue on were to add the line: I've tried a few random ones but had no effect either. Keep in mind that I know next to nothing about pam and cron. –  Lohoris May 13 '10 at 10:02
    
Try opening up the ssh PAM config file and seeing if it includes another PAM stack. There's probably a single overarching stack that most of the other stacks include. –  Ignacio Vazquez-Abrams May 13 '10 at 10:49
    
I've edited the post –  Lohoris May 13 '10 at 12:24

i would guess there's a crontab'd task for root, either in root's crontab or the system-wide cron files, that runs every minute.

once you locate that task, you can maybe adjust it so it doesn't run every minute.

i'm wondering what the concern is, if this continues? if /var is low on disk-space you could set up log rotation to be a little more aggressive with auth.log, and compress every day (should compress to a very small size, since the lines are nearly identical).

for general log monitoring egrep -v 'session (opened|closed) for user root' would filter out all those messages...

share|improve this answer
1  
The concern is simply one of "order" and "good practice". It's not a useful log, so there's no reason to keep it. There are reasons to remove it, so I want to remove it. Simple as that :) –  Lohoris May 13 '10 at 9:01
    
The nuisance logs go to auth.log which I often look at for messages related to intrusion attempts, generated by security tools. The nuisance logs add clutter which makes the log harder to read. –  Kaz Jul 17 at 23:24

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.