We just recently upgraded to Tru64 5.1b to fix a bug in our SAN. But now it appears that texis runs out of Semaphores every 48 hours or so. Have you guys had any experiences like this with Tru64? It's most annoying to be woken at 4am.. ;>)
No. Texis will keep using the same semaphore for any given database unless it disappears or is otherwise unaccessable. Make sure all of your texis processes are running as the same non-root user all of the time. And that there's nothing going around deleting shared mems.
Check your monitor.log and vortex.log files to see if there are any complaints about semaphores or shared mem segments or anything permission related.
200 Nov 4 01:38:38 (76022) Removed semaphore (pid=0) in the function Clear semaphore
014 Nov 4 01:38:38 (76022) Invalid argument in the function semunlock
200 Nov 4 01:39:08 (76022) Removed semaphore (pid=0) in the function Clear semaphore
000 Nov 4 01:42:00 (76022) Unable to remove semaphore: Invalid argument in the function Clear semaphore
200 Nov 4 01:44:23 (76022) Removed semaphore (pid=0) in the function Clear semaphore
014 Nov 4 01:44:23 (76022) Invalid argument in the function semunlock
200 Nov 4 01:47:40 (76022) Removed semaphore (pid=0) in the function Clear semaphore
000 Nov 4 01:48:25 (76022) Unable to remove semaphore: Invalid argument in the function Clear semaphore
200 Nov 4 01:48:46 (76022) Removed semaphore (pid=0) in the function Clear semaphore
000 Nov 4 01:51:16 (76022) Unable to remove semaphore: Invalid argument in the function Clear semaphore
200 Nov 4 01:51:47 (76022) Removed semaphore (pid=0) in the function Clear semaphore
000 Nov 4 01:55:06 (76022) Unable to remove semaphore: Invalid argument in the function Clear semaphore
000 Nov 4 01:55:16 (76022) Unable to remove semaphore: Invalid argument in the function Clear semaphore
The other possible cause of that, seeing as you are using a SAN, would be if you have two different servers trying to access the same database. The semaphore is only valid on one or other of the servers, so each tries to create their own.
Well we have an HSG80 SAN but there is only one head unit attached to it. I will try the rmlocks -f when I get a chance. Have you guys run 5.1b in house yet? Could it be an OS conflict of some sort?
If all was working across reboots before the OS update I would suspect a new OS bug was introduced or something about kernel settings has changed.
If you don't know whether it worked across reboots before the update (since unix machines tend not to be booted much) triple check your permissions and what user texis might run as under every circumstance (rc scripts, cgi, cron, etc). Make sure monitor and related programs are setuid to the DBA to help ensure that it's always run as the correct user.
Sounds like perms problem. It can't read the shared mem telling it the monitor is already running, so it tries to start one automatically. That monitor fails because the shared mem already exists.
Check ownership of the shared mems with your system's "ipcs" command. Make sure monitor and all texis programs that are currently running (use the "ps" command) and any that might run (INSTALLDIR/bin/*, CGIDIR/texis, any API programs you've created) are always running as the same unix userid.
