nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Iwtrace.log errro as "Trying to restore /iw-store/default/d0/d73/d47/points ..."

PadmaKumara

We have upgraded the TS 6.5 to TS 6.72 version.

In this box we had two iw-stores one is pointed to the TS when we do the upgrade and other one is read only store which was keep as a backup and it was syncing with other TS server which also had the TS.6.5.

After the TS upgrade in this box we wanted to mount the backup store to the upgraded TS and we have don that and we have manually migrated default store content to 6.5 to 6.7 using below command

walkArchive.pl –p default
Iwusermigrate
Iwaccessmigrate

After that TS is working fine and all functionalities are working correctly but we have some issue with the iwtrace.log file

This log file growing very rapidly it is increasing the size by 1 Mb per one second.
Log file is getting updated with below messages repeatedly

Mon Jun 8 10:16:34 2009] Trying to restore /iw-store/default/d0/d73/d47/points which is greater than latest id 0x734646
[Mon Jun 8 10:16:34 2009] Trying to restore /iw-store/default/d0/d74/d31/points which is greater than latest id 0x734646
[Mon Jun 8 10:16:34 2009] Trying to restore /iw-store/default/d0/d73/d47/points which is greater than latest id 0x734646
[Mon Jun 8 10:16:34 2009] Trying to restore /iw-store/default/d0/d74/d31/points which is greater than latest id 0x734646
[Mon Jun 8 10:16:34 2009] Trying to restore /iw-store/default/d0/d73/d47/points which is greater than latest id 0x734646
[Mon Jun 8 10:16:34 2009] Trying to restore /iw-store/default/d0/d74/d31/points which is greater than latest id 0x734646
[Mon Jun 8 10:16:34 2009] Trying to restore /iw-store/default/d0/d73/d47/points which is greater than latest id 0x734646

Can some one help me on resolving this issue?

Padma.

Find more posts tagged with

Comments

Adam Stoller

We have upgraded the TS 6.5 to TS 6.72 version.

In this box we had two iw-stores one is pointed to the TS when we do the upgrade and other one is read only store which was keep as a backup and it was syncing with other TS server which also had the TS.6.5.

After the TS upgrade in this box we wanted to mount the backup store to the upgraded TS and we have don that and we have manually migrated default store content to 6.5 to 6.7 using below command

walkArchive.pl –p default
Iwusermigrate
Iwaccessmigrate

After that TS is working fine and all functionalities are working correctly but we have some issue with the iwtrace.log file

This log file growing very rapidly it is increasing the size by 1 Mb per one second.
Log file is getting updated with below messages repeatedly

Mon Jun 8 10:16:34 2009] Trying to restore /iw-store/default/d0/d73/d47/points which is greater than latest id 0x734646
[Mon Jun 8 10:16:34 2009] Trying to restore /iw-store/default/d0/d74/d31/points which is greater than latest id 0x734646
[Mon Jun 8 10:16:34 2009] Trying to restore /iw-store/default/d0/d73/d47/points which is greater than latest id 0x734646
[Mon Jun 8 10:16:34 2009] Trying to restore /iw-store/default/d0/d74/d31/points which is greater than latest id 0x734646
[Mon Jun 8 10:16:34 2009] Trying to restore /iw-store/default/d0/d73/d47/points which is greater than latest id 0x734646
[Mon Jun 8 10:16:34 2009] Trying to restore /iw-store/default/d0/d74/d31/points which is greater than latest id 0x734646
[Mon Jun 8 10:16:34 2009] Trying to restore /iw-store/default/d0/d73/d47/points which is greater than latest id 0x734646

Can some one help me on resolving this issue?

Padma.

walkArchive.pl is a custom script - and thus I doubt any of us have any idea what it actually does.

What I suggest you do is deactivate the stores and run iwfsck on them. In fact, you should have run iwfsck on the stores before copying / migrating them to 672.

PadmaKumara

According to the TS upgrade user guide Alternatively we can use a script (will only exist from ver 6.7.1 SP1 upwards) named /iw-home/private/bin/walkArchive.pl, which does the equivalent of chown and chmod steps at a much faster pace.
e.g. /iw-home/private/bin/walkArchive.pl –p default where ‘default’ is the store to be migrated

Do any one have idea why this error is coming there is no clue from any other log files on this issue

thanks
Padma.

Adam Stoller

According to the TS upgrade user guide Alternatively we can use a script (will only exist from ver 6.7.1 SP1 upwards) named /iw-home/private/bin/walkArchive.pl, which does the equivalent of chown and chmod steps at a much faster pace.
e.g. /iw-home/private/bin/walkArchive.pl –p default where ‘default’ is the store to be migrated

Do any one have idea why this error is coming there is no clue from any other log files on this issue

thanks
Padma.

Hmm, interesting - that script is not documented in the 672 docs - nor does the script exist in the 672SP1 IWHOME/private/bin/ directory
(nor IWHOME/bin nor IWHOME/install) - perhaps it didn't do what it was supposed to?

Again - I think you need to run iwfsck on your backing store and contact Support.

nipper

Hmm, interesting - that script is not documented in the 672 docs - nor does the script exist in the 672SP1 IWHOME/private/bin/ directory
(nor IWHOME/bin nor IWHOME/install) - perhaps it didn't do what it was supposed to?

Again - I think you need to run iwfsck on your backing store and contact Support.

I see it on my SP1 (installed as 672 then added SP1)

[aknipp@whitehorse apps]$ cd Interwoven/iw-home/private/bin/
[aknipp@whitehorse bin]$ ls
chkFatDir.ipl iwdir iwfsck iwsci iwutildtestclt
chkLargePts.ipl iwetcboot iwfsfix iwstart iwxmlval
gen_ssl.ipl iwevent iwi18nclt.pl iwstop walkArchive.pl
iwauthdstart iweventsubd iwidtopath iwuiboot wfmsetup.pl
iwauthdstop iwextract iwinsert iwutildstart
iwdelete iwfixpubtime iwnamedexec iwutildstop
[aknipp@whitehorse bin]$ iwversion
iwserver: 6.7.2 Build 69983 Interwoven
[aknipp@whitehorse bin]$

Though the first 3 lines imply this is Unix only:

#!/bin/sh
eval 'exec `/usr/bin/iwgethome`/iw-perl/bin/iwperl -x -S $0 ${1+"$@"}';
#!iwperl

Adam Stoller

I see it on my SP1 (installed as 672 then added SP1)

[aknipp@whitehorse apps]$ cd Interwoven/iw-home/private/bin/

Hmm, curiouser and curiouser - mine was a fresh 672 + SP1 installation (i.e. not an upgrade from 671).

The exec stuff in the script is a means of not having to put the path to iwperl in the #! line proper.
It works on Unix because it does the eval in bourne-shell mode first and then execs the iwperl engine on the script.
It works on Windows because command line scripts on Windows use ftype and assocs to determine the scripting engine to use - not the #! line.

nipper

Hmm, curiouser and curiouser - mine was a fresh 672 + SP1 installation (i.e. not an upgrade from 671).

The exec stuff in the script is a means of not having to put the path to iwperl in the #! line proper.
It works on Unix because it does the eval in bourne-shell mode first and then execs the iwperl engine on the script.
It works on Windows because command line scripts on Windows use ftype and assocs to determine the scripting engine to use - not the #! line.

I did not realize that. It will not help with CGIs I assume, don't they need the shebang line ?

Adam Stoller

I did not realize that. It will not help with CGIs I assume, don't they need the shebang line ?

I believe that to be correct - but perhaps we've hijacked this thread too much already...

With respect to the original thread:

Again - I think you need to run iwfsck on your backing store and contact Support.