Bug 469388 - master core dumps after plugin reconfiguration
master core dumps after plugin reconfiguration
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: grid (Show other bugs)
All Linux
high Severity urgent
: 1.1
: ---
Assigned To: Matthew Farrellee
Kim van der Riet
Depends On: 470167
  Show dependency treegraph
Reported: 2008-10-31 11:54 EDT by Robert Rati
Modified: 2009-02-04 11:04 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-02-04 11:04:33 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Robert Rati 2008-10-31 11:54:37 EDT
Description of problem:
Condor was running on RHEL5 with plugins enabled via PLUGIN_DIR, then reconfigured to use <subsys>.PLUGINS and restarted.  The master seems to coredump on shutdown.  This was seem on multiple nodes of different configurations (HA CM only, HA Schedd only, execute node).

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Actual results:
10/31 09:49:22 DaemonCore: Command Socket at <>
10/31 09:49:22 Failed to load plugin: /usr/libexec/condor/MgmtScheddPlugin-plugin.so reason: /usr/libexec/condor/MgmtScheddPlugin-plugin.so: undefined symbol: _ZTI16ClassAdLogPlugin
10/31 09:49:22 MasterPlugin registration succeeded
10/31 09:49:22 Successfully loaded plugin: /usr/libexec/condor/MgmtMasterPlugin-plugin.so
10/31 09:49:22 Failed to load plugin: /usr/libexec/condor/MgmtNegotiatorPlugin-plugin.so reason: /usr/libexec/condor/MgmtNegotiatorPlugin-plugin.so: undefined symbol: _ZTI16NegotiatorPlugin
10/31 09:49:22 Failed to load plugin: /usr/libexec/condor/MgmtCollectorPlugin-plugin.so reason: /usr/libexec/condor/MgmtCollectorPlugin-plugin.so: undefined symbol: _ZTI15CollectorPlugin
10/31 09:49:22 MgmtMasterPlugin initializing...
10/31 09:49:22 Started DaemonCore process "/usr/sbin/condor_startd", pid and pgroup = 12940
10/31 10:10:02 Got SIGTERM. Performing graceful shutdown.
10/31 10:10:02 Sent SIGTERM to STARTD (pid 12940)
10/31 10:10:02 The STARTD (pid 12940) exited with status 0
10/31 10:10:02 All daemons are gone.  Exiting.
10/31 10:10:02 **** condor_master (condor_MASTER) EXITING WITH STATUS 0
Stack dump for process 12934 at timestamp 1225465802 (12 frames)

Expected results:

Additional info:
Comment 1 Matthew Farrellee 2008-11-06 14:14:13 EST
This is fixed in condor-7.1.4-0.4

The testing procedure is the same as for BZ470167, except run the condor_master in place of the qmf-agent example.

Plugins currently live in /usr/libexec/condor and can be configured with PLUGIN_DIR = /usr/libexec/condor

Plugins must be enabled and loaded for the test to be meaningful. Verify plugins are loaded by looking at log output. Successful loading is reported as part of daemon startup.

Running the master will also start other daemons that used to fail with an error as well. To see if any daemons are crashing: grep -i stack `condor_config_val LOG`/* Alternatively you can check the MasterLog for any non 0 exit values.
Comment 3 Frantisek Reznicek 2008-11-20 03:48:15 EST
RHTS test qpid_test_qmf_agent_bz470167 validates that this issue has been fixed.
Comment 5 errata-xmlrpc 2009-02-04 11:04:33 EST
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.