OpenSolaris

see comments
 xxxxx@xxxxx.com 2004-11-12 20:56:53 GMT
Among many ways of encountering this bug, the most common shows
up via entries in /var/adm/messages similar to the following:

<date/time> <hostname> cron[<pid>]: [ID 832980 auth.error] pam_unix_cred: project.max-shm-memory resource control assignment failed for project "<name_of_project>"

with matching entries appearing at the same times in /var/cron/log :

! project.max-shm-memory resource control assignment failed for project "<name_of_project>" <date/time>
! bad user (<username>) <date/time>
! <username> <pid> c <date/time> rc=1

and where <username> has been associated with <name_of_project> and where
shared memory resource control settings for this project are configured.

Moreover, inspection of <username>'s crontab will show that two or more
cronjobs were scheduled to run for this user at the time in question
(on the same minute).  The <pid> is that of the cron child process
attempting (and failing) to execute one of these job;  another job for
this user at the same time would have run normally.

When feasible, rearranging the crontab to run jobs in a staggered
fashion  (no two jobs scheduled for the same minute, ever)  will
much reduce the occurrences of this problem.
Note however that there are other things (login(1), su(1m),...)
besides cronjobs which may exercise the same facility and which
could still result in failures when several processes attempt to
do so simultaneously for the same project.

Read new taskid in order to serialize setprojects()'s

This uses fifo's to serialize the setproject()'s be reading each taskid between
each invocation of newtask.

#!/bin/sh

safe_newtask() {
	project = $1
	shift

        /usr/bin/rm -f /tmp/fifo.$$
        /usr/bin/mkfifo /tmp/fifo.$$
        newtask -v -p $project $@ 2>/tmp/fifo.$$ &
        cat /tmp/fifo.$$ | while read taskid ; do
                /usr/bin/rm -f /tmp/fifo.$$
                cat 1>&2
                break
        done
}

safe_newtask foo program1&
safe_newtask foo program2&
safe_newtask foo program3&
safe_newtask foo program4&
safe_newtask foo program5&
safe_newtask foo program6&
safe_newtask foo program7&
safe_newtask foo program8&
 xxxxx@xxxxx.com 2004-11-12 21:53:24 GMT
Note that the workaround only applies when running newtask(1M) simultaneously.  It does not resolve the problem when seen through cron or a login process.
The majority of customer's who have run into this bug have been configuring project.max-shm-memory for the Oracle project.  An alternative workaround - for these customers - would be to set this through the old /etc/system interface, ie 

  shmsys:shminfo_shmmax  -    Maximum shared memory segment size 
  shmsys:shminfo_shmmni  -    Number of shared memory identifiers 

If these values are specified, the default value for ALL project.max-shm-memory is simply a result of shminfo_shmmax * shminfo_shmmni[1], you may then not need te have a project entry for Oracle.

[1] see project_init() at 
   http://cvs.opensolaris.org/source/xref/on/usr/src/uts/common/os/project.c#792

N/A