Linux hidden file /dev/shm/.tomcat.ptc_p caused backup failed

[ZHH]

Hello all,

There is a hidden Linux file /dev/shm/.tomcat.ptc_p after running Thingworx. The file's attribute is question mark "?". This file is still there even if Tomcat shutdown. And also cannot delete it by root user. It caused backup software failed.

jsvc service running mode, tomcat:tomcat user&group created and tomcat user is with nologin.

Any method to avoid creating, delete this hidden file, or change file attribute to normal?

Thanks.

[slangley]

Hi @ZHH.

That hidden file, among others, are necessary for ThingWorx to start.  It does not get removed upon shutdown and you should not try to delete it.

What is your driving your desire to remove this file?

Regards.

--Sharon

[ZHH]

Hello Sharon,

An application agent is running on the Linux server to backup the whole Linux system automatically, backup process will be broken if this file is there. 

Even root user cannot delete it, the file attribute of .tomcat.ptc_p likes "d??????????     ?       ? ", based on Google search results, it seems abnormal.

This case happens on Thingworx 9.1, 9.2 and 9.3.

What the customer expected is:

1, best if .tomcat.ptc_p can be removed after stopping Tomcat, so that backup can be done automatically.

2, if .tomcat.ptc_p cannot be removed, grant normal file attribute so that root user can delete it, then start backup manually.

Thanks.

[slangley]

Hi @WilliamZhao.

After reading your response, I realized that the file you mentioned is not named correctly and is possibly a copy of the one created by ThingWorx--not the one actually in use.  To verify, please navigate to the $HOME directory of the Tomcat process owner.  Do you see a file there called ptc_p.0?

Are you running any other PTC products that may have created the file?  If not, you will need to find a way at the o/s level to remove it.  Have you tried changing the attributes in order to delete it?  You may have to use a 3rd party utility for getting rid of it.

I assume the backup is failing to run because of the invalid attributes.   If you're unable to remove the file, have you tried excluding it from the backup process?

Regards.

--Sharon

[ZHH]

Hello Sharon,

Thanks for your response.

.tomcat.ptc_p is related to ThingWorx, the reason why say "related" is when launch Thingworx Platform, this file must be there. But I am not sure if configurations have problem or not. May I know if it can be found at your side or not?

Linux command "ll -a /dev/shm" can list this hidden file.

As the file attribute is "d???????", root user cannot delete, change, or move this file, if any tools are available kindly advise.

Backup software does not have exception rule to exclude this directory. At this moment the customer have to backup manually, change Linux setting, reboot, backup, change setttings back, reboot again, and then validate. Luckly, not require to do such backup every day.

Just one doubt for me, is this file created by Thingworx or not?

Thanks.

[slangley]

Hi @WilliamZhao.

This isn't a normal scenario for ThingWorx.  Did you confirm if the ptc_p.0 file exists under the $HOME directory of the Tomcat owner?  ThingWorx does not use the file at the path you provided.  You need to somehow force the removal of this file.  You mentioned this same scenario exists under 3 different versions of ThingWorx.  Is this the same instance that has been upgraded, or are you running 3 instances that have the same issue?  Is ThingWorx running as expected?

The current process for backing up is a little unclear.  What settings are getting changed?

At this point, it might be best to open a case so we can take a look at the system.  If this works for you, please let me know and I will create a case on your behalf.

Regards.

--Sharon

[ZHH]

Will raise a new case again from my side. Thanks a lot!

[slangley · Accepted solution]

Hi @WilliamZhao.

As you know, a case was opened for this issue and subsequently the solution was documented in an article.  Please feel free to add any additional details of the case.

Regards.

--Sharon