Files failing in deployment

Hi there,

We are running a deployment from which, some of the files are getting deployed successfully while others are not. All the files reside in same directory and they are failing intermittently. Reason that OD tells for the failure in receiver logs is:

LIB: 2012-10-30 08:04:55 ERROR: Could not create file (/web/prod/salesman/docs/sales/salesmanual/images/NA/primary/features_attachment/2720/r4a014658.jpg.iwtmp), errno=116.
LIB 00017: 2012-10-30 08:04:55 ERROR: Could not get file data(./features_attachment/2720/r4a014658.jpg) from socket.

Has anybody seen this error? Can somebody explain what it means and how to fix it?

OD sender-version=Interwoven OpenDeploy(6.2.1.0.0 Build 71309 Interwoven 20081020)
receiver-version=Interwoven OpenDeploy(7.1.0.0.0 Build 225 Interwoven 20091218)

Please let me know if any other information is needed.

Find more posts tagged with

Comments

archanavonteddu

Do you see any file names appended with .iwold/.iwnew on the reciever end in that particular directory?

FYI: I had a similar kind of issue (where some files deploy and some do not) and when i looked into receiver end, i figured out there were some files not deployed completely (created .iwold and .iwnew but did not replace it some how). we restarted the receiver and everything started worked fine for us.

Thanks
Archie

nipper

Two things, check the disk on the remote server, make certain it is not full.

Also does anything get deployed ? Just certain files or all files.

Finally you may want to check the release notes to verify that 6.2.1 can deploy to 7.1

Typically A/I is pretty good about keeping the disparate versions inter-operable, but there have been a couple issues with 7 and 6 OD

Adam Stoller

Is this a transactional, or non-transactional deployment?

archanavonteddu's response is with regard to failed transactional deployments - but if you are saying that some files manage to get deployed while other's don't, and the error message references ".iwtmp" - thus it sounds like a non-transactional deployment.

As per nipper's response, there was an issue with OD 7.2.1 deploying to down-rev receivers that required a patch to OD 7.2.1 - however, your case is an up-rev deployment to OD 7.1. You should double-check with Support, but I don't think this is the issue.

That being said, one should generally upgrade the senders (Base) before upgrading the receivers - you might consider upgrading your Base server to 7.1 and see if the problem goes away.

You might see if you can find an entry for 116 in /usr/include/sys/errno.h on your server(s), as usually the error number referenced in the log files in such messages refer to OS error numbers (not always) and that might shed some light on the issue.

As nipper also said, verify the amount of free disk space (both amount and percentage) on both your sender and receiver (mostly the latter) to make sure you're not running into a system resource limitation.

Also, please verify: Is this a Unix-to-Unix deployment, or Windows-to-Unix deployment? And what flavor of Unix is involved?

Uttara

Thanks everyone for the replies.

Here are the answers:

We checked free diskspace and that doesn't seem to be an issue (617 G free diskspace on receiver).

This is a non-transactional deployment.

This is Windows to Unix deployment. I've requested exact OS name and version to the server team, waiting for their response.

We may consider upgrading sender to OD 7.1 as more of a maintenance task, but less of a Production issue fix task.

The path for errno.h that you suggested seems to be a Unix path. Could you please suggest similar path on Windows?

Needless to say, this issue is not yet resolved for us and its on a production environment, so clock is ticking. Opening a case with Iwov support usually takes longer fro resolution. We are sure to open a case, but can't rely on that alone for the fix as the turn around time is not that quick.

Adam Stoller

[...]
This is Windows to Unix deployment. I've requested exact OS name and version to the server team, waiting for their response.
[...]
The path for errno.h that you suggested seems to be a Unix path. Could you please suggest similar path on Windows?

I was thinking the Windows/Unix thing might be important, but it's actually Unix->Windows that has the issue where Unix you can have two files ("foo", "Foo") and Windows would treat them as being the same name. Since you're going Windows->Unix, that shouldn't be an issue.

The error was reported on your Receiver, which is Unix, so that's where you want to look.

There is an errno.h on Windows too - somewhere in C:\System or C:\System32 if memory serves correctly - you should be able to Search for it. However, I don't think that's as important as the one on the Receiver since that's where you appear to be encountering the error.

Rohan_t1

In our case it was due to network issues between TS and OD servers. You might want to check on that. Is it failing for specific OD receiver servers or all? (Non-prod). Checking permission on directories at runtime should also be worth testing.

bagman

LIB: 2012-10-30 08:04:55 ERROR: Could not create file (/web/prod/salesman/docs/sales/salesmanual/images/NA/primary/features_attachment/2720/r4a014658.jpg.iwtmp), errno=116.
LIB 00017: 2012-10-30 08:04:55 ERROR: Could not get file data(./features_attachment/2720/r4a014658.jpg) from socket.

One hint is the "errno=116", which is a Linux system error code for a stale NFS file handle.

That errno is usually what I start with when researching issues.