Maybe we've got a cursed table, I'm not sure, but these messages appear when trying to select from it:
000 Could not create semaphore (No space left on device)
000 Unable to obtain semaphore
000 Could not open locking mechanism in the function ddopen
000 Couldn't connect to . in the function SQLConnect
It's a very small table (1 record), and the kicker is, even when we delete it and try to recreate, that message keeps coming back up. The disk we're using is only 35% full, too.
Even when we created a new directory and renamed the table, that error still came up. We're not having trouble selecting from other tables on this machine, so it appears isolated to this one we're trying to make.
Semaphores are a kernel resource. No space means the kernel will not allow more semaphores. It's nothing to do with memory or disk. Use "ipcs" to list semaphores, "ipcrm" to delete stale ones. You may just need to increase the number of semaphores the system allows. You need one per database.
This is from sysdef -i. Do you know if any of the semaphore parameters below would look questionable to texis' eyes? We've got.. maybe 15 databases on this Solaris box of ours.
* IPC Semaphores
*
10 semaphore identifiers (SEMMNI)
60 semaphores in system (SEMMNS)
200 undo structures in system (SEMMNU)
25 max semaphores per id (SEMMSL)
10 max operations per semop call (SEMOPM)
10 max undo entries per process (SEMUME)
32767 semaphore maximum value (SEMVMX)
16384 adjust on exit max value (SEMAEM)
Yeah, 10 SEMMNI < 15. Sun's defaults are rather low. Try this in your /etc/system file. A reboot is required to activate.
* Number of undo structures in system:
set semsys:seminfo_semmnu = 200
* Max number of undo entries per process:
set semsys:seminfo_semume = 200
* Max number of semaphore identifiers:
set semsys:seminfo_semmni = 200
* Max entries in semaphore map:
set semsys:seminfo_semmap = 40
Interesing explanation. I am currently creating only one database, and texis first generated three, then added a fourth, fifth, sixth, seventh and eighth semaphore as time progressed ... Once the eighth was created, it was only a matter of time before the dreaded "Could not create Semaphore" message apeared, and the walk status page crashed out ...
I thought it might be to do with the threading (I originally used 4 threads) so I cut it back to two threads, but still the same symptoms. How do you define a "database" in the above explanation ??
We will be upping out semaphore count tonight and I'll try again.
Sounds like you have permission issues such as not always running texis as the same userid. You can delete the old semaphores.
Make sure you are always running texis and it's programs as the same userid, whether from the webserver's CGI or from the command line. The installation attempts to ensure this by making the programs setuid to the correct user and will warn if it can't. Check your texis programs for being setuid. Then make sure all of the texis database directories and files are owned by the correct user.
Also look in INSTALLDIR/texis/monitor.log and INSTALLDIR/texis/vortex.log to check for errors.
Thanks for the fast reply Mark. I did check the logs - no other reported problems. I looked at the +S bit - all set on the installed programs (monitor, gw, anytotx)
I'm trying with the larger semaphore count right now ...
That will only hide the problem for a little longer. It really won't use more than one semaphore per database if everything's running correctly. If it's losing them it will probably continue to lose them.
Try to spot what action causes a new semaphore to be created. Are all of the semaphores owned by the same user? What version of Texis(texis -version) and Webinator(displayed on the walk settings page) are you using?
You're right .. it's still amassing semaphores. It does drop the occasional one, but the trend is ever upwards. All the semaphores are owned by the web administrator and have the same group, and these match the owner and group for the executables, in fact for every file in the installed directories.
I'm using Texis version 4.03.105272396 of May 12, 2003 (sparc-sun-solaris2.6-64-32) and webinator 4.3.2-unix-wo/plugin.
There doesn't seem to be a detectable pattern, but it is hard to follow.
Here are my semaphore settings from sysdef -i .. all seems OK ...
* IPC Semaphores
*
250 semaphore identifiers (SEMMNI)
60 semaphores in system (SEMMNS)
250 undo structures in system (SEMMNU)
25 max semaphores per id (SEMMSL)
10 max operations per semop call (SEMOPM)
250 max undo entries per process (SEMUME)
32767 semaphore maximum value (SEMVMX)
16384 adjust on exit max value (SEMAEM)
*
Now there's an interesting thing ... the user dir where I keep my executables, and probably the web-root (and hence the cgi-bin and web directories) are NFS mounted from other machines ...
There are definitely not 2 machines accessing the same db, because nobody but me is working on this db at present ... but there is certainly a lot of NFS-ing going on around here.
It also appears that if I don't watch the progress using the web admin interface->status page, the semaphore count stays a lot more constant ... I'll test that more thoroughly tomorrow, when I don't already have a fistful of redundant semaphores to confuse the issue.
