Skip to Content
0

Massive creation of CPICTRC files in work directory

Jul 25, 2017 at 02:00 PM

179

avatar image
Former Member

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

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

5 Answers

Prithviraj Rajpurohit Jul 26, 2017 at 09:25 AM
1

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

Show 1 Share
10 |10000 characters needed characters left 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

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

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

Show 1 Share
10 |10000 characters needed characters left 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

0
Isaias Freitas
Jul 25, 2017 at 06:26 PM
0

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

Share
10 |10000 characters needed characters left characters exceeded
avatar image
Former Member Jul 26, 2017 at 07:19 AM
0

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


cpictrc6029498.txt (17.2 kB)
Share
10 |10000 characters needed characters left characters exceeded
avatar image
Former Member Jul 27, 2017 at 12:41 PM
0

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

Show 4 Share
10 |10000 characters needed characters left characters exceeded

Hi Marie,

Execute lsof CPIC.trcfile this will return the process ID whose written the data in file.

Also increase the gateway trace and share the CPIC.trc and gateway trace file.

Regards,

Prithviraj

0
Former Member

Dear Prithviraj,

I've uploaded a part of the gateway trace on trace level 2 (dev_rd) because the whole tracefile would've been to huge - it's the part right at the time the also attached CPICTRC file was written today on 10:01:13. In both files I've changed SID etc. as before.

lsof unfortunately doesn't work on that server...

Thanks & regards

Marie

dev-rd.txt (1.0 MB)
cpictrc19136516.txt (178.4 kB)
0

Hi Marie

I could see below details in trace files...

--------------------------------------------------------------------

long TP : sapftp

long LU : SAPHOSTERP

GwMkTimeStamp: create conversation id 41166485

GwFiCreateConvId: created 41166485

GwICheckSecInfo: check tp=sapftp, user=BALSSLE , host=*, addr=192.168.2.1

--------------------------------------------------------------------

NiHLGetNodeAddr: got hostname 'MOMOS2010' from operating system

NiIGetNodeAddr: hostname 'MOMOS2010' = addr 10.212.20.27

--------------------------------------------------------------------

Regards,

Prithviraj

0
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

0