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.
ARGH !! ... I just realised - I have a dev and a live machine, both sharing the same user dir (i.e. install dir) and both sharing the web tree (inc. cgi-bin) ... This may not affect the db build, because I initiated it by hand on the dev machine, but now I see the monitor process and texis are running on the live box, and they seem to open semaphores too. Could these be affecing the db build ??
Also, will this mean that any attempt to run a scheduled walk would kick off on both boxes at the same time ??
Can I safely kill the processes on the live box - since I only want to be able to offer search on that box, but build via the dev box ??
You may NOT use the same database from multiple machines. See msg 10 above. The install directory and profile dataspaces must be different between machines if they are sharing the same nfs disk.
Walk on the dev box then copy or move the database to a different location for the live box to use for searching.
What will happen is that if the install directory is shared, then the default database, where schedules are stored, is also shared, and looked at by both machines.
The semaphore created by the dev box is not valid on the live box, so the live box will create another one, and that is not valid on the dev box, so it will create another...
The default database is in use whenever any Texis process is in use. It and any other database, can only be accessed by one machine at a time.
Ahaaa ... many thanks gurus ... now I have to rethink my process to get it sorted out ... BTW - I ran Verity EMEA Tech Support for 18 months, and I can assure you that you're worth your weight in gold ... great response, good product, and right on the mark with your answers. Well done and thank you.
