nfs and cifs port display in yawn page.

Jan Synacek jsynacek at redhat.com
Mon Oct 7 05:30:16 UTC 2013


Yes, that's exactly what I described below. You need to attach a debugger.

Please, keep the replies on the mailing list.

On 10/04/2013 05:04 PM, sunil kumar wrote:
> hi!.
> 
> To sorry!. we are writing code in networking to view nfs port (4200)  and
> CIFS port (4201). Just to view that nfs port is running in the web page of
> localhost/yawn page. we need to trace the program of ProtocolEndPoint.
> Which File and what value is in the variables, we need to know. we used to
> write code and find the bug using break point and trace in python and java.
> In same way i want to know the value of all the  variable while running.
> example:
> 
>  pid = (int) *port_get_id(port);
> 
> i want to know what value present in the pid in every loop iteration..
> 
> i got to know wt u told in the past mail and i will try that.
> 
> if any information regarding debugging will be helpful..
> 
> 
> On Fri, Oct 4, 2013 at 12:52 PM, Jan Synacek <jsynacek at redhat.com> wrote:
> 
>> Hi,
>>
>> On 10/03/2013 09:08 PM, sunil kumar wrote:
>>> hi!.
>>>
>>> we need to know, how to debug and trace the program from where i start.
>> We
>>> have return to view the nfs port and cifs port in the yawn page..
>>>
>>>
>>> here is the code for that.!..
>>>
>>> CMPIStatus res = { CMPI_RC_OK, NULL };
>>>     Network *network = mi->hdl;
>>>     const char *ns = KNameSpace(cop);
>>>
>>>     char *name;
>>>     Port *port;
>>>     int pid;
>>>
>>>     network_lock(network);
>>>     const Ports *ports = network_get_ports(network);
>>>     for (size_t i = 0; i < ports_length(ports); ++i) {
>>>         if (!KOkay(res)) {
>>>             break;
>>>         }
>>>         port = ports_index(ports, i);
>>>
>>>             asprintf(&name, "%s_%ld", port_get_id(port), i);
>>>             LMI_ProtocolEndpoint w;
>>>             LMI_ProtocolEndpoint_Init(&w, _cb, ns);
>>>             LMI_ProtocolEndpoint_Set_SystemName(&w, get_system_name());
>>>             LMI_ProtocolEndpoint_Set_SystemCreationClassName(&w,
>>> get_system_creation_class_name());
>>>             LMI_ProtocolEndpoint_Set_CreationClassName(&w,
>>> LMI_ProtocolEndpoint_ClassName);
>>>             LMI_ProtocolEndpoint_Set_Name(&w, name);
>>>             free(name);
>>>           pid = (int) *port_get_id(port);
>>>
>>>             switch (pid) {
>>>                 case 4200:
>>>                     LMI_ProtocolEndpoint_Set_ProtocolIFType_NFS(&w);
>>>                     LMI_ProtocolEndpoint_Set_ProtocolIFType(&w,
>>> LMI_ProtocolEndpoint_ProtocolIFType_NFS);
>>>                     break;
>>>                 case 4201:
>>>                     LMI_ProtocolEndpoint_Set_ProtocolIFType_CIFS(&w);
>>>                     LMI_ProtocolEndpoint_Set_ProtocolIFType(&w,
>>> LMI_ProtocolEndpoint_ProtocolIFType_CIFS);
>>>                     break;
>>>                 default:
>>>                     break;
>>>             }
>>>             if (!ReturnInstance(cr, w)) {
>>>                 error("Unable to return instance of class "
>>> LMI_ProtocolEndpoint_ClassName);
>>>                 CMSetStatus(&res, CMPI_RC_ERR_FAILED);
>>>                 break;
>>>             }
>>>         }
>>>
>>>     network_unlock(network);
>>>     return res;
>>>
>>>
>>>
>>> i need to know how to trace this.. how could i do this..
>>
>> If I understand correctly, you want to know how to attach a debugger to the
>> provider process.
>>
>> This is probably server dependent. I'll try to describe how it works when
>> using
>> tog-pegasus, which is the CIMOM we prefer.
>>
>> Everytime you make a request that needs your provider to be run, the server
>> forks a new process (unless you are running it with
>> forceProviderProcesses=false
>> option). The process exists in the system until it gets automatically
>> cleaned up
>> by the server. That happens after 5 minutes of idleness. So you have 5
>> minutes
>> to do the following.
>>
>> The process' name is usually in form of "cimprovagt <provider_name>". You
>> can
>> identify it e.g. by using 'top'. Then, you can attach your favorite
>> debugger to
>> the running process like so:
>>
>> $ gdb /usr/bin/cimprovagt <process_id>
>>
>> Hope this helps.
>>
>> --
>> Jan Synacek
>> Software Engineer, Red Hat
>>
> 


-- 
Jan Synacek
Software Engineer, Red Hat


More information about the openlmi-devel mailing list