Kbase P107152: The lbi file is left behind after a 4GL client session quits
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
12/3/2008 |
|
Status: Verified
SYMPTOM(s):
The lbi temporary file is left behind after a 4GL client session quits|
The lbi temporary file remains on disk after a 4GL client session quits|
The srt and DBI temporary files are cleaned up correctly.
4GL client session is started up with -t
The directory where the lbi file resides has the directory sticky bit set on.
FACT(s) (Environment):
UNIX
Progress 9.x
OpenEdge 10.x
CAUSE:
The problem is the directory sticky bit. You can verify that the sticky bit is on by running:
ls -ld <directoryName>
If the directory sticky bit is switched on, you will see something like:
drwxrwxrwt 12 root root 4096 Aug 3 09:24 /tmp
Please notice the "t" at the end of the permissions list.
In addition to that, if you run ls -l into the temporary directory while a 4GL session is active, you will see something similar to the following:
-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
Please notice that the lbi is owned by root, as opposed to the DBI and srt files, which are owned by the UNIX use that started up the 4GL client session.
If we look into the man pages for chmod with regard to the implications of the directory sticky bit, we see [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, we can now understand what happens:
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 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. Incidentally, after permissions are downgraded, there is no way for the executable to gain root permissions again.
When the 4GL session exist, 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.
FIX:
Remove the directory sticky bit by running:
chmod a-t <directoryname>
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.