We have noticed that when a session has a record lock, cleanupd won't clean it up right away.  Is there any documentation about the rules of cleanupd, as to how the times can be configured - or even IF the times can be configured - and how long it waits for a record lock to be released before it reaps the disconnected session?

Kevin,
  Not sure about UD, but with UV, the configuration for uvcleanupd is stored in the uvcleanupd.config file.  A similar one is available for the uvdlockd as well (uvdlockd.config).

  Both of those processes appear to be able to be launched with specified parameters (instead of what is in the config) as well.

  I'd check your Admin guide for details.

---

We have noticed that when a session has a record lock, cleanupd won't clean it up right away.  Is there any documentation about the rules of cleanupd, as to how the times can be configured - or even IF the times can be configured - and how long it waits for a record lock to be released before it reaps the disconnected session?

Kevin,

In terms of intervals and how cleanupd works I have covered this in several technical presentations in the past. I'd have to check to see if they are still posted on the Rocket sites. Please excuse the length of response but this should answer all your questions.

The cleanupd.log in the $UDTBIN directory will tell you the checking interval time and by default it's 20 seconds.

# more cleanupd.log
Starting: Tue May 24 03:50:21 2022

CLEANUPD daemon:
CLEANUPD checking interval: 20 seconds
CLEANUPD minimum interval: 10 seconds
CLEANUPD process id.....: 11665560
Successfully Started.

The minimum and checking interval are also shown when running showud

showud
USER PID TIME COMMAND
root 11665560 0:16 /disk1/ud82/bin/cleanupd -m 10 -t 20


The minimum interval and checking interval are set when the cleanupd process is started (normally via startud) and the values can be edited
The lines in startud are as follows

$UDTBIN/cleanupd -m 10 -t 20 > cleanupd.log 2>cleanupd.errlog &
PID=$!

Starting at UniData 8 on UNIX the method for determining if a process is still valid is done by testing the ownership of semaphore (hence why more semaphores are required at UniData 8). Each process slot in the lct table (whose size is defined by NUSERS)  has a semaphore related to it (these are now identified as live detection semaphores in ipcstat). When a process get it's slot in the lct table (you would see this as the udtno of the process) it locks a semaphore. It is the ownership or non-ownership of processes noted in the lct table which now determine if a process is active (On Windows we use a different method).

Once UniData has identified a process is no longer active any left over locks will be released.

So if a lock is taking more than 40 seconds to clear any left over locks then you would need to look at what's happening to that process. I have seen certain processes take longer to actually exit on AIX than on other platforms and this comes down to sockets and keepalive settings on AIX.

Some tools to help you understand the components involved.

!ps
PID TTY TIME CMD
18940104 pts/1 0:00 ps
19661004 pts/1 0:00 -ksh
19923136 pts/1 0:00 udt (my udt pid)
:LISTUSER

Licensed(UDT+CP)/Effective Udt Sql iPhtm Pooled Total

( 32 + 2 ) / 34 1 0 0 0 1

UDTNO USRNBR UID USRNAME USRTYPE TTY TIME DATE
1 19923136 0 root udt pts/1 03:51:32 Jun 01 2022 (Note UDTNO = 1 and PID of 19923136)

:!sms -l | more (Note The sms -l command displays the LCT table and my PID is the first in list so gets UDTNO 1, sometimes in other tools it will be zero but for now it's 1 on the subject we are talking about, -1 notes an empty slot)
-------------------- LCTs (1024) ---------------------
19923136 -1 -1 -1 -1
-1 -1 -1 -1 -1

UniData uses these tables and the ownership of semaphore on Unix (at 8 and onwards) to work out if resources need to be cleaned up.

I hope I've provided enough information to help you work out why your locks are waiting around. If a process that has terminated left over locks are taking more than 40 seconds (two iterations of the cleanupd cycle) then this should help you work out why.

Thanks,
Jonathan

---