Feedback
Did this article resolve your question/issue?

   

Article

Database log file shows the wrong time stamp for exceptions or signals from other processes

« Go Back

Information

 
TitleDatabase log file shows the wrong time stamp for exceptions or signals from other processes
URL Name000051874
Article Number000169282
EnvironmentProduct: OpenEdge
Version: 11.2.1 and later
OS: UNIX
Question/Problem Description
Database log file shows the wrong time stamp for exceptions or signals from other processes
Why does the database logfile not show local time for interrupt signals and exceptions?
Why does SYSTEM ERROR show GMT with 0 hours TZ offset and no milliseconds?

When a client receives a hangup signal the message being written to the database log file is showing the wrong time stamp.
The time stamp for the messages mentioned above can be off by several hours.
 
The HANGUP signal has the wrong time stamp where regular messages use the correct timezone:
[2019/08/27@15:34:02.415-0400] P-5274       T-1     I ABL     5: (452)   Login by <userid> on /dev/pts/3.
[2019/08/27@15:34:02.452-0400] P-5274       T-1     I ABL     5: (7129)  Usr 5 set name to <userid>.
[2019/08/27@19:35:39.000+0000] P-5274       T-1     I ABL     5: (562)   HANGUP signal received.
[2019/08/27@15:35:39.396-0400] P-5274       T-1     I ABL     5: (453)   Logout by <userid> on /dev/pts/3.

The timestamp  changes from 14:42 to 12:42, without the TZ offset and no milliseconds:
[2019/08/27@14:42:46.806+0200] P-31196402 T-1 I IDXCHEC16: (452) Login by <userid> on /dev/pts/3.
[2019/08/27@12:42:46.000+0000] P-31196402 T-1 I IDXCHEC16: (49) SYSTEM ERROR: Memory violation
 
Steps to ReproduceSteps to demonstrate the database lg timestamp difference:

prodb sports2000 sports2000
proserve sports2000
mpro sports2000

From client, run the following:

for each customer:
update custnum.

tail sports2000.lg to get the client Process id.

kill -1 <client pid from above>

The message regarding the HANGUP signal has the wrong time stamp where regular messages use the correct timezone:
tail sports2000.lg file.
Clarifying Information
Error Message
Defect Number
Enhancement Number
Cause
Resolution
The timestamp is not wrong, it is being reported in Greenwich Mean Time (GMT) format. 

This is working as expected due to a change that was made in OpenEdge 11.2.1 and later with regards to how the Progress Signal Handler shows the timestamp header in Greenwich Mean Time (GMT) format.

Library functions to do conversion to local time are not async signal safe.  This change in timestamp formatting allows OpenEdge to avoid calling certain UNIX system functions which can cause a process to hang or not properly terminate when called from within the Signal Handler code.

During regular execution, when OpenEdge processes write to the database log file (.lg) the timestamp header of the message shows the time in local time format. This header with local time information includes the offset of the local time from Greenwich Mean Time (GMT):
 
[2019/08/27@14:42:46.806+0200] - which shows that the time is 2 hours offset from GMT.
 
On UNIX systems, when OpenEdge processes exceptions (either internal fatal errors or signals from other processes), messages may be written to the database log (.lg) file from within the process' Signal Handler code. These messages when written from the Signal Handler, show a timestamp header in Greenwich Mean Time (GMT) format. 
 
[2019/08/27@12:42:46.000+0000] -which shows that the time is actual GMT with 0 hours offset. In addition, the time information written from the process' Signal Handler does not show milliseconds.  

This change in timestamp formatting allows OpenEdge to avoid calling certain UNIX system functions which can cause a process to hang or not properly terminate if called from within the Signal Handler code.
Workaround
There is no workaround for this issue as it was a design change to address async unsafe signal handling described above on UNIX/LINUX systems.
Notes


 
Last Modified Date3/30/2022 12:21 PM
Attachment 
Files
Disclaimer The origins of the information on this site may be internal or external to Progress Software Corporation (“Progress”). Progress Software Corporation makes all reasonable efforts to verify this information. However, the information provided is for your information only. Progress Software Corporation makes no explicit or implied claims to the validity of this information.

Any sample code provided on this site is not supported under any Progress support program or service. The sample code is provided on an "AS IS" basis. Progress makes no warranties, express or implied, and disclaims all implied warranties including, without limitation, the implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample code is borne by the user. In no event shall Progress, its employees, or anyone else involved in the creation, production, or delivery of the code be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample code, even if Progress has been advised of the possibility of such damages.