OEM agent suddently not running for daylight saving time changes.
Problem:
$ ./emctl start agent
Oracle Enterprise Manager 10g Release 10.2.0.1.0.
Copyright (c) 1996, 2005 Oracle Corporation. All rights reserved.
Starting agent ..... failed.
The agentTZRegion value in /oracle/app/em/agent10g/sysman/config/emd.properties is not in agreement with what agent thinks it should be.Please verify your environment to make sure that TZ setting has not changed since the last start of the agent.
If you modified the timezone setting in the environment, please stop the agent and exectute 'emctl resetTZ agent' and also execute the script mgmt_target.set_agent_tzrgn(
Consult the log files in: /oracle/app/em/agent10g/sysman/log
Solutions:
Download the Patch 5632264 for the latest version for your platform, DO NOT APPLY IT with opatch but:
Manually replace the oracore [/zoneinfo/timez*.dat] files in the Central Agent ORACLE_HOME:
Agent ORACLE_HOME
- backup the initial oracore files $ORACLE_HOME/oracore/[/zoneinfo/timez*.dat]
- replace the oracore [/zoneinfo/timez*.dat] files in the Central Agent ORACLE_HOME with the oracore [/zoneinfo/timez*.dat] files extracted from the patch
- ./emctl resetTZ agent
Oracle Enterprise Manager 10g Release 10.2.0.1.0.
Copyright (c) 1996, 2005 Oracle Corporation. All rights reserved.
Updating /oracle/oracle/agent10g/sysman/config/emd.properties...
Successfully updated /oracle/oracle/agent10g/sysman/config/emd.properties.
Login as the em repository user and run the script:
exec mgmt_target.set_agent_tzrgn('oradiscprod.amestruetemper.com:3872','US/Eastern')
This can be done for example by logging into sqlplus and doing
SQL> exec mgmt_target.set_agent_tzrgn('oradiscprod.amestruetemper.com:3872','US/Eastern')
- start the Central Agent
./emctl start agent
./emctl status agent
Reference:
Enterprise Manager DST Quick Fix Guide: 418792.1
2 comments:
Hello.
we have a problem of our OEM.
we can't login in OEM, however the agent is started normaly.
and when we try to login shown this message
"java.lang.Exception: Exception in sending Request :: null"
we need help for you
cordialement.
This is a really useful troubleshooting writeup, especially for anyone still supporting legacy OEM 10g environments. Daylight saving time issues are notoriously hard to diagnose because nothing appears “wrong” until a service suddenly refuses to start, and the error message alone does not always point clearly to the root cause.
What stands out here is the emphasis on understanding how the agent determines timezone consistency rather than blindly restarting services. Manually updating the zoneinfo files and explicitly resetting the agent timezone shows a deep understanding of how OEM agents validate their runtime environment. These are exactly the kinds of fixes that are rarely obvious from official documentation but make all the difference in real world operations.
From a quality perspective, this kind of operational knowledge is just as important as application testing. Capturing these edge cases and resolutions helps teams avoid repeat incidents and reduces dependency on tribal knowledge. Using a central place to document and track these learnings, such as Tuskr test management software, can turn one off fixes into shared team wisdom.
Post a Comment