Skip to Content
avatar image
Former Member

Massive creation of CPICTRC files in work directory

Dear experts,

I've searched for a solution to this for months now - without success. So maybe you can help me find the reason...

We've got an ERP 6 EhP 6 (NW 7.31 BASIS 18) Unicode with Kernel 7.22 ext PL101 which massively produces CPICTRC<no> files in its work directory. And I can't find the cause for this.

I already went through SAP note 47682.

There are no traces active in any RFC Destination. I've also already turned off the gateway trace for external programs in SMGW. I've checked SM50 - but there are no cpic traces active in any kind. I've checked SM54 - it's empty.

Other sources of information didn't suggest anything else and I'm running out of ideas now...

Does anybody have a suggestion where to search for the trigger of these traces?

Thanks & regards

Marie

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

5 Answers

  • Jul 26, 2017 at 09:25 AM

    Hi Marie,

    As per the attachment the trace level is set to 2. You can change the parameter value to 1 or 0 (0 = No trace will be written). This will write less info in the file keeping it small.

    You need to also check for environment variable CPIC_TRACE

    Also check if any RFCs have Trace checkbox checked.

    Regards,

    Prithviraj

    Add comment
    10|10000 characters needed characters exceeded

    • Hello,

      I would not recommend running the system with trace level zero.

      That is because you would not have any trace information to start an analysis, in case any issue occurs.

      Now, from the trace file attached by Marie:

      STACCP: my TP_name: >sapftp<

      So, these files are being written by the sapftp program.

      Check the CPIC_TRACE and RFC_TRACE environment variables ;-).

      Regards,

      Isaías

  • avatar image
    Former Member
    Aug 08, 2017 at 11:32 AM

    Dear Marie,

    as all the parameters mentioned by Isaías can be changed dynamically (see Tx RZ11) and there's a function module
    SPFL_PARAMETER_CHANGE_VALUE to do this, there may be a customer program that changes them for its runtime
    (This is really unbelievable, but I've seen so much nutty coding yet). Try to find the active processes around the time period when the trace is started using Tx ST03N. Analyzing three or four periods should reduce the scope of programs to be viewed.

    Regards,
    Volker

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member

      Dear Volker, dear other helpers,

      yeah custom code as the root cause is exactly what I was assuming.... but this system is so busy that it's pretty hard to localize the probable cause. But because it seems, only sapftp is being logged in these CPICTRC files, I checked for programs doing ftp at the times when files have been created - I found at least one customer program that ran nearly every time. Which lead me to AGAIN checking the RFC destinations - focus on SAPFTPA which is used by the above mentioned program.

      And I don't get it... I've checked them several times - never found an active RFC trace - but here it was - active RFC trace in destination SAPFTPA.... I've now deactivated this trace and voilà - since then no more CPICTRC<no> files. Unfortunately I forgot to look when and by whom the RFC destination has been changed the last time, before I did so - so I'll never find out.

      Hope this really was the solution and this trace option is not being reactivated by some kind of custom automatism again... so I'll keep an eye on it. I'll leave this question open for a while in case the problem isn't solved after all.

      Thank you all for your support by now!

      I don't get it, I really don't get it....

      Thanks & regards

      Marie

  • Jul 25, 2017 at 06:26 PM

    Hello Marie,

    Try setting the parameters "gw/accept_remote_trace_level", "rdisp/accept_remote_trace_level" and "icm/accept_remote_trace_level" to zero.

    Please also attach one of the files to this question, so we can view its contents to see whether we can help you further.

    Regards,

    Isaías

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Jul 26, 2017 at 07:19 AM

    Hello Isaías,

    thanks for your response. I've set gw/accept_remote_trace_level and rdisp/accept_remote_trace_level dynamically (RZ11) to zero - icm/accept_remote_trace_level already had that value.

    Unfortunately this doesn't seem to stop the CPICTRC files from being created.

    Attached you can find one of the smallest trace files (they grow up to 1,5/2GBs sometimes...). I've just changed SID, IP and hostname for security reasons.

    Hope this might give a hint...

    Thanks & regards

    Marie

    Add comment
    10|10000 characters needed characters exceeded

  • avatar image
    Former Member
    Jul 27, 2017 at 12:41 PM

    Dear Prithviraj, dear Isaías,

    first of all, thanks for your answers.

    Unfortunately there are no environment variables like CPIC_TRACE or RFC_TRACE set for the erpadm user - that is, what really confuses me, because I really don't get where this trace level 2 comes from...

    As already mentioned, there are no traces set in any RFC connection etc. (see original post). As per Isaías recommendation I've already set the mentioned parameters online to 0.

    Any idea where trace level 2 could come from?

    Thanks & regards

    Marie

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member

      Dear Prithviraj,

      but how does that help? This is just an example - it's not always the same user. And I don't think that he himself has got any influence on these traces.

      As far as I understand, these CPICTRC<no> files are written by gateway access from external programs. But this trace option is deactivated in this ERP System - as well as nearly every other trace at the moment. So I guess there has to be another parameter or switch to turn these kind of traces off. To me this all seems like I'm missing some kind of configuration or something keeps on activating these traces or the like.

      Or do you think, these traces are triggered externally without being able to prevent them from the SAP system? That would be kind of a real security gap...

      Thanks & regards

      Marie