Yesterday & today, I am plagued with an lbi file that is growing and filling the hard disk. The code base has been stable, so it must be something in the current data that is looping, calling recursively, etc.
Is there any way to tell what process/user/program is associated with a given lbi file? I'm running with -t so the lbi files are visible, but all of them are owned by root. I did a "strings lbixxx |pg" on the big one and saw some program names in all caps, and a few lines of report output, but they did not lead me to a smoking gun yet.
Any advice? ProTop to the rescue ??
This is 11.7.1 on RHEL. Thx in advance --
(And yes, this is urgent!)
ProTop might be able to rescue you in that the user who is doing this is probably a pretty active user and is likely at or near the top of the "User IO Activity" screen. And you could enable the client statement cache (perhaps for just one user) to see what such a user is doing.
However... that assumes that the user is actually doing stuff with the db. And they might not be. So what you really want to do is to run:
sudo fuser filename
This will give you a list of process ids that have that file open. Since it is an LBI file I expect that there will only be a single PID.
The next thing to do would be to get a 4gl stack trace with:
proGetStack <pidFromAbove>
Examples:
28828 ls -l --time-style=full-iso lbitaoXQc -rw-r--r--. 1 root root 0 2019-11-20 20:04:21.612734866 +0300 lbitaoXQc 28828 tail -2 sports.lg [2019/11/20@20:04:03.811+0300] P-28275 T-140480595711808 I ABL 5: (452) Login by root on /dev/pts/5. [2019/11/20@20:04:21.618+0300] P-28748 T-140480595711808 I ABL 5: (7129) Usr 5 set name to root.
Timestamps: 20:04:21 (wrong example, see below )
fuser
$ fuser lbitaoXQc lbitaoXQc: 28748
lsof
$ lsof lbitaoXQc COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME _progres 28748 root 5u REG 8,2 0 416428 lbitaoXQc
Update: Example with 'ls' command is wrong: the common filesystems used in Linux don't store the creation time. But the ext4 file system does store it: stat -c %W lbi*
lbi is created by vars and TTs which have defaulted to "undo" instead of having a 'no-undo' phrase added.
If you have "undo" elements in your code and the structure of the data you're processing has changed, that could be the cause of this "all of the sudden".
KB on lbi:
knowledgebase.progress.com/.../P66690
In addition to "undo" vars and TTs, lbi is also used for subtransactions:
Only subtransactions (a transaction block nested within another transaction block) and UNDO objects (variables and temp tables) are written to the ABL client local-before-image (lbi) file.