Description of problem: laus_attach Version-Release number of selected component (if applicable): How reproducible: Use laus_attach in at. Steps to Reproduce: 1. try to run at job version at-3.1.8-64.EL3 touch /tmp/somefile | batch 2. see tail -f /var/log/messages Actual results: Apr 3 16:16:19 lab atd[1664]: LAuS error - atd.c:565 - laus_attach:(19) laus_attach: No such device Expected results: no error message? Error message isn't the main problem. If I want functional pam support I have to restart atd daemon after each reboot. Additional info: edit /etc/security/limits.conf * hard fsize 4000000 reboot computer log in as non root echo "ulimit -a > /tmp/p" | batch cat /tmp/p (unlimited) Now if you restart at: service atd restart and run echo "ulimit -a > /tmp/p" | batch again, you have the right size of limit 4000000. I've tested it without laus and then is functional without restarting. I've also read bug#131860, which's maybe related with problem and was also fixed with workaround. The whole problem is in bug#196717.
Is this a new problem caused by the new version of laus, or does any version of laus cause this problem? Also, what is the start priority of at and laus? Do you have any strace data showing what the code is doing? Does /dev/audit exist when atd starts up? Thanks.
This bug is filed against RHEL 3, which is in maintenance phase. During the maintenance phase, only security errata and select mission critical bug fixes will be released for enterprise products. Since this bug does not meet that criteria, it is now being closed. For more information of the RHEL errata support policy, please visit: http://www.redhat.com/security/updates/errata/ If you feel this bug is indeed mission critical, please contact your support representative. You may be asked to provide detailed information on how this bug is affecting you.