The lbi file is left behind after a 4GL client session quits

The lbi file is left behind after an ABL client session quits when the Progress client session is started up with the Save Temp Files (-t) startup parameter and the Client Temporary file directory has the sticky bit

Apr 7, 2015
Knowledge

Title

URL Name

P107152

Article Number

000127602

Environment

Product: Progress Version: 9.1x Product: OpenEdge Version: 10.x, 11.x, 12.x OS: UNIX

Question/Problem Description

The lbi client-temporary file is left behind after an ABL client session quits.

The lbi temporary file remains on disk after a 4GL client session quits.

The srt and DBI client-temporary files are cleaned up correctly.

Steps to Reproduce

Clarifying Information

The Progress client session is started up with the Save Temp Files (-t) startup parameter

The directory where the lbi file resides has the directory sticky bit set on.

Error Message

Defect Number

Enhancement Number

Cause

This is expected behavior resulting from the directory having the sticky bit set. It can be verified that the sticky bit is on by running:

$ ls -ld <directoryName>

Example: When the directory sticky bit is switched on, notice the "t" at the end of the permissions list:

drwxrwxrwt 12 root root 4096 Aug 3 09:24 /tmp

In addition to this, a directory listing (ls -l) on the temporary directory where a 4GL session is active, notice that the lbi file is owned by root, as opposed to the DBI and srt files, which are owned by the UNIX user that started up the 4GL client session. :

-rw-r--r--    1 myuser   support      3072 Aug 3 09:29 DBIl0bMpj
-rw-r--r--    1 root     support         0 Aug 3 09:29 lbiFdXs4b
-rw-r--r--    1 myuser   support         0 Aug 3 09:29 srts6lGre

The man pages for chmod with regard to the implications of the directory sticky bit, it is noted that [snipped from the man pages on Linux]:

STICKY DIRECTORIES
       When the sticky bit is set on a directory, files in that directory may
       be unlinked or renamed only by root or their owner. Without the sticky
       bit, anyone able to write to the directory can delete or rename files.

Putting all this information together, the following is happening when the Progress client session is started up with the Save Temp Files (-t) startup parameter and the Client Temporary file directory has the sticky bit:

When the 4GL client session starts up, the UNIX permissions are temporarily upgraded to those of root; that happens thanks to the sticky bit on the Progress client executable. This is the stage when the lbi file is created.
Shortly after that, the permissions are downgraded to those of the UNIX user that started the session up [in the example above: myuser]. This is the stage when the DBI and srt files are created. Once permissions are downgraded, there is no way for the executable to gain root permissions again.
When the 4GL session exists, the executable can clean up the DBI and srt files because they are owned by the UNIX user running the session [myuser]; on the other hand, the lbi file is owned by root, and because of the directory sticky bit, it cannot be cleaned up.

Please note that this problem does not occur if -t is not used when starting up the 4GL client session. In that case, the temporary files are unlinked without any problems when the session exits.

Resolution

Remove the Client Temporary file directory sticky bit as the root user:

$ chmod a-t <directoryname>

Workaround

Notes

Progress Articles:

Why are my lbi files growing substantially?
What is the difference between the local before image (lbi) file and the before image (bi) file?
Are temporary files deleted during client operation?
What are the temporary files used by the OpenEdge client?
Receiving many 5408 Warnings

Keyword Phrase

Last Modified Date

10/19/2022 2:58 PM

The lbi file is left behind after a 4GL client session quits

Files(0)

Was this article helpful?

Was this article helpful?

The lbi file is left behind after a 4GL client session quits

Information

Related Articles