Verbrugge, Troy | 2 Oct 19:53 2015

Indication Filter Association to Indication Subscription Missing

We are running into an issue dealing with associations and indications.  My guess is that it is something we
are doing wrong, but we can't figure out what that might be.

We have some tests on our provider that act as clients.  One of those tests is trying to create and verify the
existence of an subscription.  Here are the steps:

1. We create our own IndicationFilter, which is a subclass of CIM_IndicationFilter in our own namespace
2. We create an event handler (CIM_ListenerDestinationCIMXML)
3. We create a CIM_IndicationSubscription with that event handler and indication filter
4. We then query for association names on the filter where the association class is an indication subscription.
5. We verify that an association exists.

This works fine.  But, when I change step 1 to directly create a CIM_IndicationFilter instead of our
subclass, we don't get any associations back in step 5.  

Some other notes:

1) Even without the association being present, we are still getting indications.
2) The created filter for CIM_IndicationFilter has more fields filled out, while our sub-classed version
does not:
CIM_IndicationFilter: //"CIM_IndicationFilter",Name="TemporaryPoolNameChange",SystemCreationClassName="CIM_ComputerSystem",SystemName=""

NETAPP_IndicationFilter: //"",Name="TemporaryPoolNameChange",SystemCreationClassName="",SystemName=""

Thanks for any help.

Troy Verbrugge
AppAware Engineer
5400 Airport Boulevard Suite 100
Boulder CO 80301
(Continue reading)

Johnny Hwang | 1 Oct 03:05 2015

OpenPegasus crash upon bad request

Hello all,


I noticed that OpenPegasus crashes after 1 minute if SCVMM sends a bad (malformed) request over:


1443657185s-800557us: XmlIO [20195:140164881024992:HTTPConnection.cpp:2328]: <!-- Request: queue id: 40 -->

POST /cimom HTTP/1.1^M

Connection: Keep-Alive^M

Content-Type: application/xml; charset="utf-8"^M



User-Agent: msftsm^M

CIMOperation: MethodCall^M

CIMMethod: Associators^M

CIMObject: interop^M

Content-Length: 627^M


<?xml version="1.0" encoding="UTF-8"?>^M




      <IMETHODCALL NAME="Associators">^M


          <NAMESPACE NAME="interop" />^M


        <IPARAMVALUE NAME="ObjectName" />^M

        <IPARAMVALUE NAME="AssocClass">^M

          <CLASSNAME NAME="CIM_ElementConformsToProfile" />^M


        <IPARAMVALUE NAME="ResultClass">^M

          <CLASSNAME NAME="CIM_ComputerSystem" />^M






1443657185s-800585us: Http [20195:140164881024992:HTTPConnection.cpp:2343]: Now setting state to 1

1443657185s-800599us: Http [20195:140164881024992:HTTPAuthenticatorDelegator.cpp:297]: HTTPAuthenticatorDelegator - HTTP processing start

1443657185s-800624us: Authentication [20195:140164881024992:HTTPAuthenticatorDelegator.cpp:431]: HTTPAuthenticatorDelegator - Authentication processing start

1443657185s-800661us: Authentication [20195:140164881024992:HTTPAuthenticatorDelegator.cpp:1169]: HTTPAuthenticatorDelegator - Authentication processing ended

1443657185s-800677us: Http [20195:140164881024992:HTTPAuthenticatorDelegator.cpp:1283]: HTTPAuthenticatorDelegator - CIMOperation: MethodCall

1443657185s-800691us: Http [20195:140164881024992:CIMOperationRequestDecoder.cpp:420]: CIMOperationRequestDecoder::handleHTTPMessage()- httpMessage->getCloseConnect() returned 0

1443657185s-800763us: L10N [20195:140164881024992:MessageLoader.cpp:418]: Message ID = Common.XmlParser.VALIDATION_ERROR

1443657185s-800784us: L10N [20195:140164881024992:MessageLoader.cpp:418]: Message ID = Common.XmlReader.INVALID_NULL_IPARAMVALUE

1443657185s-800860us: Http [20195:140164881024992:HTTPConnection.cpp:384]: HTTPConnection::handleEnqueue - HTTP_MESSAGE

1443657185s-800885us: Http [20195:140164881024992:HTTPConnection.cpp:924]: HTTPConnection::_handleWriteEvent: Server write event.

1443657185s-800900us: XmlIO [20195:140164881024992:HTTPConnection.cpp:932]: <!-- Response: queue id: 40 -->

HTTP/1.1 400 Bad Request^M

CIMError: request-not-valid^M

PGErrorDetail: Validation%20error%3A%20on%20line%209%3A%20A%20null%20value%20is%20not%20valid%20for%20IPARAMVALUE%20%22ObjectName%22.^M



1443657185s-800912us: Http [20195:140164881024992:HTTPConnection.cpp:1040]: HTTPConnection::_handleWriteEvent: Sending non-chunked data.

1443657185s-800943us: Http [20195:140164881024992:HTTPConnection.cpp:1181]: A response has been sent (192 of 192 bytes have been written). A total of 15 requests have been processed on this connection.

1443657185s-800959us: Http [20195:140164881024992:HTTPConnection.cpp:1222]: Now setting state to 0

1443657185s-800981us: Http [20195:140164881024992:Monitor.cpp:597]: Exited HTTPConnection::run()

1443657185s-801003us: Http [20195:140164881024992:Monitor.cpp:543]: Monitor::run select event received events = 1, monitoring 5 idle entries

1443657185s-801015us: Http [20195:140164881024992:Monitor.cpp:555]: Monitor::run indx = 0, queueId = 1, q = 0x17f8460

1443657185s-801659us: Http [20195:140164881024992:Monitor.cpp:543]: Monitor::run select event received events = 1, monitoring 5 idle entries

1443657185s-801680us: Http [20195:140164881024992:Monitor.cpp:555]: Monitor::run indx = 5, queueId = 40, q = 0x1a94450

1443657185s-801690us: Http [20195:140164881024992:Monitor.cpp:563]: entries[5].type is TYPE_CONNECTION

1443657185s-801700us: Http [20195:140164881024992:Monitor.cpp:584]: Entering HTTPConnection::run() for indx = 5, queueId = 40, q = 0x1a94450

1443657185s-801713us: Http [20195:140164881024992:HTTPConnection.cpp:374]: HTTPConnection::handleEnqueue - SOCKET_MESSAGE

1443657185s-801727us: Http [20195:140164881024992:HTTPConnection.cpp:2252]: Total bytesRead = 0; Bytes read this iteration = 0

1443657185s-801738us: XmlIO [20195:140164881024992:HTTPConnection.cpp:2284]: <!-- No request message received; connection closed: queue id: 40 -->

1443657185s-801748us: Http [20195:140164881024992:HTTPConnection.cpp:1614]: Now setting state to 2

1443657185s-801758us: Http [20195:140164881024992:Monitor.cpp:597]: Exited HTTPConnection::run()

1443657185s-801814us: Http [20195:140164881024992:Monitor.cpp:543]: Monitor::run select event received events = 1, monitoring 4 idle entries

1443657185s-801840us: Http [20195:140164881024992:Monitor.cpp:555]: Monitor::run indx = 0, queueId = 1, q = 0x17f8460

1443657245s-637744us: Thread [17137:140360732653536:Thread.cpp:380]: Thread: able to create a thread key





And here is the stack trace from the crash:


warning: Can't read pathname for load map: Input/output error.

[Thread debugging using libthread_db enabled]

Using host libthread_db library "/lib64/".

Core was generated by `/opt/pegasus/bin/cimserver daemon=false enableAuthentication=true traceLevel=4'.

Program terminated with signal 6, Aborted.

#0  0x00007fd77c79f815 in raise () from /lib64/

(gdb) bt full

#0  0x00007fd77c79f815 in raise () from /lib64/

No symbol table info available.

#1  0x00007fd77c7a0ff5 in abort () from /lib64/

No symbol table info available.

#2  0x00007fd77c7dc66b in __libc_message () from /lib64/

No symbol table info available.

#3  0x00007fd77c8672b7 in __fortify_fail () from /lib64/

No symbol table info available.

#4  0x00007fd77c867249 in ____longjmp_chk () from /lib64/

No symbol table info available.

#5  0x00007fd77c8671b3 in __longjmp_chk () from /lib64/

No symbol table info available.

#6  0x00007fd77b7d6885 in alarmfunc (sig=<optimized out>) at hostip.c:518

No locals.

#7  <signal handler called>

No symbol table info available.

#8  0x00007fd77c846193 in select () from /lib64/

No symbol table info available.

#9  0x00007fd77da5696e in Pegasus::Monitor::run (this=0x649530, milliseconds=500000) at Monitor.cpp:511

        tv = {tv_sec = 440, tv_usec = 230163}

        fdread = {fds_bits = {14368, 0 <repeats 15 times>}}

        autoEntryMutex = {_mutex = <at> 0x649538}

        __PRETTY_FUNCTION__ = "void Pegasus::Monitor::run(Pegasus::Uint32)"

        timeNow = {tv_sec = 1443641567, tv_usec = 565472}

        entries = {_data = 0x649610, _size = 32}

        _idleEntries = 4

        maxSocketCurrentPass = 14

        events = 1

#10 0x00007fd7815c2784 in Pegasus::CIMServer::runForever (this=0x649470) at CIMServer.cpp:743

        lastIdleCleanupTime = {tv_sec = 1443641442, tv_usec = 0}

        now = {tv_sec = 1443641567, tv_usec = 565500}

#11 0x0000000000406dd2 in CIMServerProcess::cimserver_run (this=0x63c830, argc=0, argv=0x7fffeb7dcb48, shutdownOption=false, debugOutputOption=false) at cimserver.cpp:1307

        daemonOption = false

        configManager = 0x643190

#12 0x00007fd781a28a9b in Pegasus::ServerProcess::platform_run (this=0x63c830, argc=9, argv=0x7fffeb7dcb48, shutdownOption=false, debugOutputOption=false) at ServerProcessUnix.cpp:187

No locals.

#13 0x00000000004051de in main (argc=9, argv=0x7fffeb7dcb48) at cimserver.cpp:708

        pegasusHome = {static EMPTY = {static EMPTY = <same as static member of an already seen type>, _rep = 0x7fd77dd57080}, _rep = 0x643150}

        shutdownOption = false

        debugOutputOption = false

        tmp = 0x7fffeb7dcfd0 "/opt/pegasus"



Monitor.cpp:511 has this line (this is 2.13.0):


    int events = select(maxSocketCurrentPass, &fdread, NULL, NULL, &tv);



My guess is Bad Request doesn’t clean up properly. Where in the code should I start looking?


Thank you,


Hegde, Ramesh (CMS | 21 Apr 18:05 2015

RHEL 7: SNMP V3 trap does not work anymore with cimserver

Hello All,


We are trying to explore snmp V3 traps on RHEL 7. We are getting following error from cimserver side.


“Failed to deliver an indication: Snmp Indication Handler failed to send the trap: USM unknown security name (no such user exists)”


When we drill down further and check the function on net-snmp i.e usm_get_user_from_list returns null and hence the comparison falls.


Do you know how to populate this list and which file does it read to populate this list?


Mainly we want to know how this list gets  populated and does it use snmpd by any chance and use any snmpd.conf file?


Currently we use wbemexec and xml file to subscribe and provide all security name, auth key and priv key in the same xml file.


I also see that on RHEL 7 there are some fixes around this usm user in the change log i.e


net-snmp-5.7.2/ChangeLog:      - make usm_get_user_from_list() handle a bogus initial user flag.

net-snmp-5.7.2/ChangeLog:      - use usm_get_user_from_list to ask not to return the default initial user.


This has created any regression on snmpv3 trap functionality in cimserver?



Ramesh Hegde
Project Manager- ACE OCMP/USP-M

rameshh <at>
T +91 80 338 66486
M +91 8197863555
Hewlett-Packard Company
No.192, Whitefield Road
Bangalore, Karnataka, 560048



Follow us on:          


Attachment (smime.p7s): application/pkcs7-signature, 8 KiB
Chang CrazyRushStar | 7 Apr 13:02 2015

Do you plan to come out a OpenPegasus "C" clinet interface?

There has be a OpenPegasus C++ Client Interface, but it is not enough for widely using C users. Do you have plan to create a C client Interface library? Or there are some others client library which highly complies with OpenPegasus server for C language users.


Karl Schopmeyer | 1 Apr 14:23 2015

OpenPegasus 2.14.1 Released

OpenPegasus 2.14.1 has been released specifically to bypass a problem in 
the ssl certificates and testing with 2.14.0.

This release only includes a fix for that bug (test certificates expired 
shortly after 2.14.0 release) but should be used in place of 2.14.0 if 
any of the OpenPegasus testing tools are to be used.

This release is defined:

     On the OpenPegasus wiki at:

And is available on the OpenPegasus web site at

and also through the wiki at:

The source RPM will be released shortly
Karl Schopmeyer
OpenPegasus Project Lead

Khushboo Sancheti | 31 Mar 19:25 2015

How can one disable the creation of TEST, SENT and RECV logs of Pegasus?


Is there a switch to disable the creation of TEST, SENT and RECV log created by Open Pegasus? Is there a configuration variable to change the location where these are created?

I am using Pegasus 2.13.


Karl Schopmeyer | 31 Mar 15:55 2015

Pegasus 2.14.0 Release - Warning

Shortly after the version 2.14.0 release a problem was created in the 
OpenPegasus tests in that the ssl certificate used for any tests 
involving ssl expired.  Since this blocks much testing, we are going to 
release 2.14.1 immediatly to fix this issue.

Karl Schopmeyer
OpenPegasus Project Lead

Karl Schopmeyer | 28 Mar 16:46 2015

The CVS Head of tree Open For Commits

The CVS head of tree (OpenPegasus 2.15) is now open for new commits.  It 
has been updated to include the new version and marked as

The same procedure as previous releases will be followed for new commits:

1. Documented in bugs
2. Bugs voted and marked approved if votes are positive
3. Only bugs with + votes to be committed.

The planning for this next version can be followed, commented on, etc. at

Karl Schopmeyer
Project Lead

Karl Schopmeyer | 28 Mar 16:40 2015

OpenPegasus Version 2.14.0 Released

OpenPegasus 2.14.0 has been formally released and is available for use.

This release includes a number of extensions, the primary of which is 
the inclusion of the
CIM/XML pull operations defined by the DMTF for the CIM/XML protocol.  
The full list of changes for this release are documented in the 
ReleaseNotes and the OpenPegasus bugzilla

For more details on the release, please use the Release Notes that are:

1. In the root directory of the source code
2. In the Release Table at
3. On the OpenPegasus Wiki at
4. Documented as OpenPegasus PEP 368.

The source code is available at on the OpenPegasus web page at:

2 Through the OpenPegasus WIKI on the ReleaseStatus Page
3. Through the OpenPegasus CVS using the CVS tag RELEASE_2_14_0

The source RPM will also be made available shortly and will be announced 

Karl Schopmeyer
Project Lead

Karl Schopmeyer | 24 Mar 17:06 2015

OpenPegasus 2.14 branch created.

Effective immediatly, in preperation for the release of OpenPegasus 
2.14.0, the RELEASE_2_14 pegasus branch has been created.

This means that any future patches for OpenPegasus 2.14 must be put into 
this branch and, further, no patches will be inserted into
the branch without a prior patch for 2.15 (the CVS head of tree).


Karl Schopmeyer | 14 Mar 15:04 2015

Pegasus 2.14 Source Freeze (Release Canidate 1) tag RELEASE_2_14_0-RC1 has been set

The RC1 tag (RELEASE_2_14_0-RC1) has been set in the head of tree for 
OpenPegasus indicating that the source code is frozen.

 From this point to the release:

1. Only critical bugs will be committed and those must have at least 2 
votes (not that documentation bugs are excepted)

The remaining steps are:

1. Complete cho test
2. Complete release notes review
3. Create the 2.14 branch
4. Set release tag

Karl Schopmeyer
Project Lean