Transport tmp directory - File not found

[Former Member]

We get occasional errors with temporary log files not being found during a transport and "tp" terminates the import. When I search for the file mentioned in the error log, I can find the file in the log subdirectory under DIR_TRANS.

DIR_TRANS=/usr/sap/etrans (yes, "etrans" is intentional)

Error message "Temporary log /usr/sap/etrans/tmp/DEVG938685.PRD not found"

Actual File Path= "/usr/sap/etrans/log/DEVG938685.PRD"

It appears the TMS system is writing the tmp files correctly in the log subdirectory so why does it fail after writing them saying it can't find them in the tmp subdirectory? When DIR_TRANS=/usr/sap/etrans, does the kernel append "tmp" or "log" to it when performing transport file maintenance?

[Former Member]

Hi Roger,

Could you please check the rights for these directories at OS level? Ensure it has all the proper rights to allow write operation.

regards,

Vinodh.

[Former Member]

Please read question again as your response is unrelated. Thank you.

[Former Member]

HI Roger,

When the import is running temporary files are created in tmp directory.These files contain info abot generation of the objects in tne transport.

After the import is completed a file having this data is created in log directory.

Now the question is are you getting this error when always importing transports in a particular system or is it happening randomly for different systems?

In first case it can be an issue with the mount or with the OS level permissions as pointed out earlier.

For second case you need to investigate.

Regards.

Ruchit.

[Former Member]

Hi Roger,

in folder tmp of trans directory, it stores temporary files when a transport is done, or a support package is being updated based on the various phases its processing.

Once the phase is done, the corresponding file from tmp folder will move to log folder and is viewed there permenantly (unless you intentionally delete it).

So, i think you would have viewed this file during the transition period, during which time, the file from tmp folder would have moved to log folder.

Thanks and Regards,

Sailesh K

[Former Member]

Thanks all for the replies but I'm not trying to view the file. This error is coming from the TMS system during a transport. See error message below.

Generation of programs and screens

Transport request___: DEVK939114

System______________: PRD

tp path : tp

Version and Release: 340.16.21 640

Temporary log /usr/sap/etrans/tmp/DEVG939114.PRD not found

Generation of programs and screens

End date and time : 20070605120520

Ended with return code: ===> 12 <===

[Former Member]

Hello Roger,

Well of course we all know that you are not tryin to view the file but the user <sid>adm is trying to do it. In your case PRDADM. Unless it is able to read/write the file you will keep on getting this error.

Regards.

Ruchit.

[Former Member]

Ruchit,

Permissions were checked as a first measure since that's the most obvious. I'm going to go with your other suggestion about checking the mount. That seems more like the issue.

Also, would there be any timing issues between asynchronous transports writing to the log directory after tmp files are deleted? The tmp files are being deleted from the tmp directory properly so I'm wondering why it's looking for them after they've obviously been deleted by the TMS system.

Thanks,

Roger

[Former Member]

Hello Rodger,

It could be an issue with asynchronous imports. I can not vouch for it since I always import synchronously. But one question are you having mutiple application servers on your production?

Regards.

Ruchit.

[Former Member]

Ruchit,

We do have multiple application servers on the production system. Our transport system doesn't use them however but I would entertain the idea that the app servers could be interfering with the mount but it would be unlikely.

Roger

[Former Member]

Hello Roger,

Transports may use mutiple application servers without us knowing them unless we check carefully.

When an import is done a job named RDDFDBCK runs with takes files from /usr/sap/trans( etrans in your case)//tmp directory and then saves them in the //usr/sap/trans/log directory.

For the last transport that has ended in error please check the log of this job. Just give the job name, user as * . In date give the date when that transport ended in error and in time fields give at 3-4 minute window which includes the time when the error came. You will get the error of tmp files not found in the job logs most likely.Also check the application server on which the job has run.

Also incase you are using an import job look out for the corresponding import job as well. Check the application server as well.

My theory is that :

In case there is mount issue then the issue is being caused in application server on which the job RDDFDBCK ran. Logon to that application server and go to transaction AL11 and check if you are able to view the files in /tmp directory.If you are not then it is a mount issue.

Regards.

Ruchit.

[Former Member]

One addition. I dont know your release but if it is 4.6C then please check OSS note 326935 as well.

Regards.

Ruchit.

[Former Member]

Ruchit,

We're using R/3 release 4.70, Basis 6.20

I looked in the log file and it unfortunately doesn't show the application server it used because the termination prevents it from being displayed. I did log into all the application servers and checked the tmp directory in AL11 and was able to display the files. Although this might suggest your theory is incorrect, I think your theory has good basis and we may have an intermittent problem with our mount.

I'm sure it would be almost impossible to view the conditions of the mount at the time the error occurs but do you have any other troubleshooting ideas?

Thanks,

Roger

[Former Member]

Hi Roger,

You wont find application server details in the log. For that you need to click on the pushbutton job details. it will let you know on which server the job ran. Double click on the job and then select job details and look for executing server.

Also I would suggest that you go for synchronous mode to bring more cohesiveness.

Regards.

Ruchit.

[Former Member]

Ruchit,

Using the various clues scattered throughout your responses, I took another look at the system and noticed a new application server was brought online a few days ago. The mounts were not setup correctly on the server and this made your questions earlier make more sense. We have solved the problem now the mounts are correct but I will make notes below on some corrections to your responses so that someone else may save time when troubleshooting the same problem.

1) When referring to permissions earlier in the chain, I thought you meant the central instance listed in the transport domain. I didn't realize at the time the application servers could pick up the work processes performed by the TMS system. I now know you were referring to checking the permissions and read/write ability at the application server level. This is why it would happen only some of the time since the TMS processes would hit the bad sever every now and then.

2) Using AL11 is a good quick method and I checked the /tmp directory while logged into the application servers as mentioned earlier but actually DIR_TRANS should have been checked. I verified the mount problem looking in DIR_TRANS on AL11 and looking at the mount on the OS level.

Thanks again for your patience. In the end it did pay off....much appreciated!

Regards,

Roger

[Former Member]

Hello Roger,

Thanks for the explanation.It is very useful and I really hope that it will indeed help some one else in resolving his queries on this topic. This is exactly how the forum can be made useful for everyone.

Additionally I would suggest one more thing not just specific for your issue but generally when a new application server is involvd as also when there is an IP address change to Hardware migration. In all such cases all the mounts must be checked carefully otherwise we may have issues not only for TMS but for other topics as well.

Regards.

Ruchit.

[Former Member]

Roger / Ruchit

Exactly two weeks after Roger's problem I had encountered the same problem today and thank goodness, I found this reply on the dot. One of the rogue application server had a mount problem and this problem got solved.

Thanks to both of you guys.

Sundar