Archive error

Content Authoring
1

(imported topic written by mgemma91)

I have a recurring task that has been running for a year, but I’ve started seeing failures recently with the archiving part of it, which is the last line in the action. The console log shows that the “archive now” command is failing on around 5% of PCs. Checking on a few, I’m seeing that the last successful archive for these computers happened at different points between April and June. But the other 95% are working perfectly.

The code I’m using for archiving is:

setting “_BESClient_ArchiveManager_MaxArchiveSize”=“50000000” on “{parameter “action issue date” of action}” for client

setting “_BESClient_ArchiveManager_OperatingMode”=“2” on “{parameter “action issue date” of action}” for client

setting “_BESClient_ArchiveManager_FileSet-CST_SW3”=“C:\Support\SWI{parameter “FName”}” on “{parameter “action issue date” of action}” for client

setting “_BESClient_ArchiveManager_SendAll”=“1” on “{parameter “action issue date” of action}” for client

archive now

And an example client log would be:

Command succeeded setting “_BESClient_ArchiveManager_MaxArchiveSize”=“50000000” on “Wed, 27 Jul 2011 18:00:02 +0000” for client (fixlet 23122)

Command succeeded setting “_BESClient_ArchiveManager_OperatingMode”=“2” on “Wed, 27 Jul 2011 18:00:02 +0000” for client (fixlet 23122)

Command succeeded setting “_BESClient_ArchiveManager_FileSet-CST_SW3”=“C:\Support\SWI\swi3_CANL3AA_7676767.gz” on “Wed, 27 Jul 2011 18:00:02 +0000” for client (fixlet 23122)

Command succeeded setting “_BESClient_ArchiveManager_SendAll”=“1” on “Wed, 27 Jul 2011 18:00:02 +0000” for client (fixlet 23122)

Command failed (Unable to archive now; failure while building archive: class ArchiveManagerBuildArchiveError) archive now (fixlet 23122)

At 20:23:23 -0400 -

ActionLogMessage: (action 23122 ) ending action

I’ve checked on a few PCs that the file name is correct and the file exists. The same ArchiveManagerBuildArchiveError message appears any time an archive is attempted. Any idea what may be causing the archive failure, or a way for me to get more details on what is happening?

2

(imported comment written by BenKus)

Hmm… I haven’t seen that before… are maybe the files locked? Can you manually move/rename them to see if some other process has a lock on them?

Ben

3

(imported comment written by mgemma91)

I ran the task again on 5 computers that failed earlier, but this time I made a copy of the file before archiving the copy. They all still failed with the same error. I verified that I could rename, copy, and delete both the original and the copy.

Command succeeded copy “C:\Support\SWI\swi3_CANR847_51800.gz” “C:\Support\SWI\testcopy.gz” (fixlet 23137)

Command succeeded setting “_BESClient_ArchiveManager_MaxArchiveSize”=“50000000” on “Fri, 29 Jul 2011 20:12:41 +0000” for client (fixlet 23137)

Command succeeded setting “_BESClient_ArchiveManager_OperatingMode”=“2” on “Fri, 29 Jul 2011 20:12:41 +0000” for client (fixlet 23137)

Command succeeded setting “_BESClient_ArchiveManager_FileSet-CST_SWT”=“C:\Support\SWI\testcopy.gz” on “Fri, 29 Jul 2011 20:12:41 +0000” for client (fixlet 23137)

Command succeeded setting “_BESClient_ArchiveManager_SendAll”=“1” on “Fri, 29 Jul 2011 20:12:41 +0000” for client (fixlet 23137)

Command failed (Unable to archive now; failure while building archive: class ArchiveManagerBuildArchiveError) archive now (fixlet 23137)

4

(imported comment written by mgemma91)

Today I have a even more serious issue… now I have 10,000 machines reporting

Command failed (Unable to archive now because last archive is still in the UploadManager queue.) archive now (fixlet 18515)

. I thought it was because the server was low on disk space, but after freeing up 20GB yesterday I’m still seeing the same problem today. My __Global\Archive folder does indeed have a Last and a Next folder that both contain archives waiting to be uploaded. I tried restarting the BES client, but that did nothing. How do I get these archives moving so that I can at least get back to my original problem?

Or will I have to wait 3 days for the default cleanup timer to kick in?

5

(imported comment written by BenKus)

Hey mgemma,

I bet your upload manager folder is full…

By default, the maximum size of the Upload Manager directory on a BES Relay is 20 MB. The BES Support site contains a Fixlet message that will alert you if a BES Relay’s Upload Manager directories are at maximum capacity: “WARNING: Upload Manager Directory Full - BES Server / Relay” and lets you change the max size (max max size is 2 GB).

Ben

6

(imported comment written by mgemma91)

I see, there is no default listed in the Upload Archive Manager document. I increased the size of one of the relays and it immediately filled up to the new size. I guess that’s not the real problem though, because the relay isn’t pushing any of these files to the BES server. Does the BES server itself have a max size that may have been reached?

7

(imported comment written by mgemma91)

We tried restarting the BES server and restarting the relay service on a relay.

8

(imported comment written by BenKus)

yea… you need to change the size on your server and it will allow the relay to upload the files…

Ben

9

(imported comment written by Thacker91)

Hi Ben,

Nice to meet you.

This forum is often seen, and I uses it for operation.

There is below 2 questions in the following points

when the setting of the size of the up-loading file of the relay is changed.

  1. Should I change the setting of all relays of it is from the client in the network communication path?

  2. When above-mentioned (1) is positive, is the change necessary for setting the server with a high-ranking relay?

We are confirming the following points now.

a) The client has succeeded in the following script execution.

“archive now”

b) In the relay, data up-loads it to the following directory.

“C:\Program Files\BigFix Enterprise\BES Relay\UploadManagerData\BufferDir\sha1”

c) In the server(high-ranking relay), data up-loads it to the following directory.

“C:\Program Files\BigFix Enterprise\BES Server\UploadManagerData\BufferDir\sha1”

d) When it becomes impossible to confirm data on the server, the following have been generated.

-1 – It seems that all the following functions have stopped.

-> “upload archive manager”

-2 – The folder is not made though the file can be confirmed by the following directories usually.

-> “C:\Program Files\BigFix Enterprise\BES Server\UploadManagerData\BufferDir\sha1[xx][yyyyyyy]”

-> (Additional question:)

A detailed functional specification when the

xx

folder exceeds 99 is not understood. Please tell me.

-3 – The following files are made.

-> ex) “C:\Program Files\BigFix Enterprise\BES Server\UploadManagerData\BufferDir\sha1_52636ade43e8f1d6aa3a08e455702d2bb346f6d2”

Regards,

Thacker

10

(imported comment written by mgemma91)

We had to change a couple things to get this working again.

On the server:

_BESRelay_Uploadmanager_BufferDirectoryMaxCount

We never changed it from the default, but it didn’t seem to fail until we hit 60,000 folders. The relays just horded archives until this was changed.

On the relays:

_BESRelay_UploadManager_CompressedFileMaxSize

I guess the relays were picking up files bigger than they could handle and then wouldn’t do anything while those files were there. Once this was increased on all relays, everything looked normal again, but I have no idea why this was suddenly an issue.

I don’t think this affects my original “failure while building archive” issue, but I need to wait for the rest of the errors to clear out so that I can see where I stand now.