Re: [RAS] Can't add papers to profile
I am getting numerous such complaints. While I was first attributing them to the recent downtime, it seems the difficulties are still lasting and date to before the downtime. The adrepec account looks up-to-date, so something must be wrong elsewhere. For example, I find that entries I added to EDIRC on May 27 are not available in EDIRC, while they are certainly present in the adrepec account. Christian Zimmermann FIGUGEGL! Department of Economics University of Connecticut 341 Mansfield Road, Unit 1063 Storrs, CT 06269-1063 http://ideas.repec.org/zimm/ christian.zimmermann@uconn.edu http://ideas.repec.org/e/pzi1.html On Wed, 10 Jun 2009, Pedro S. Martins wrote:
Hi
I've been trying to add two papers to my profile during the last two weeks but always without success. Do you know why?
My profile is http://ideas.repec.org/e/pma50.html and the papers are RePEc:ucp:jlabec:v:27:y:2009:i:2:p:257-279 and RePEc:iza:izadps:dp4187
Thank you
Pedro
---------------------------------------------------------------------- Dr Pedro Martins
Reader [Associate Professor] in Applied Economics School of Business and Management, Queen Mary, University of London Mile End Road, London, E1 4NS, United Kingdom
Research Fellow, IZA, Institute for the Study of Labor, Bonn Research Fellow, CEG-IST, Instituto Superior Tecnico, Lisbon
Email: p.martins@qmul.ac.uk Web: http://webspace.qmul.ac.uk/pmartins/ Fax: +44/0 2078823615 Phone: +44/0 2078827472, +351 961303907 ----------------------------------------------------------------------
Christian Zimmermann writes
I am getting numerous such complaints. While I was first attributing them to the recent downtime, it seems the difficulties are still lasting and date to before the downtime. The adrepec account looks up-to-date, so something must be wrong elsewhere.
The update daemon is broken. load_record_from_db_txn( repec:emp:wpaper:wpe03-18, BerkeleyDB::Hash=ARRAY(0xa9d1590) ): Storable binary image v60.57 more recent than I am (v2.7) at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/thaw.al) line 415, <FILE> line 19, at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/logcroak.al) line 76 Storable::logcroak('Storable binary image v60.57 more recent than I am (v2.7) at ...') called at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/thaw.al) line 416 Storable::thaw('y9z0tw\x{4}\x{2}\x{5}\x{0}\x{0}\x{0}\x{6}\x{bc}M6C\x{a}\x{7}present\x{a}\x{1a}emp/wpaper/empWPE03-18.rdf\x{8}\x{80}\x{a}\x{16}FFo...') called at /home/aras/acis/lib/RePEc/Index/Storage/BDBwithTxn.pm line 135 eval {...} called at /home/aras/acis/lib/RePEc/Index/Storage/BDBwithTxn.pm line 135 RePEc::Index::Storage::load_record_from_db_txn('BerkeleyDB::Txn=ARRAY(0xab4c238)', '/home/aras/acis/RI/data/RePEc/history', 'repec:emp:wpaper:wpe03-18') called at /home/aras/acis/lib/RePEc/Index/History/Handle.pm line 114 RePEc::Index::History::Handle::event_record('RePEc::Index::Update::RECORD', 'repec:emp:wpaper:wpe03-18', 'ARDB::Record::ReDIF=HASH(0xaa89898)', 'ReDIF-Paper 1.0', 'emp/wpaper/empWPE03-18.rdf', 0, '0C4ZTJg6rZXoYtBE8oCBGA', 'RePEc::Index::Update=HASH(0x9fb4de8)') called at (eval 103) line 6 RePEc::Index::Update::RECORD('RePEc::Index::Update::RECORD', 'repec:emp:wpaper:wpe03-18', 'ARDB::Record::ReDIF=HASH(0xaa89898)', 'ReDIF-Paper 1.0', 'emp/wpaper/empWPE03-18.rdf', 0, '0C4ZTJg6rZXoYtBE8oCBGA', 'RePEc::Index::Update=HASH(0x9fb4de8)') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 527 RePEc::Index::Update::read_file('RePEc::Index::Update=HASH(0x9fb4de8)', '/home/adrepec/RePEc/remo/emp/wpaper/empWPE03-18.rdf', 'RePEc::Index::FILE=ARRAY(0xaacee68)') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 440 RePEc::Index::Update::check_file('RePEc::Index::Update=HASH(0x9fb4de8)', 'emp/wpaper/empWPE03-18.rdf') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 875 RePEc::Index::Update::process_directory('RePEc::Index::Update=HASH(0x9fb4de8)', 'emp/wpaper') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 863 RePEc::Index::Update::process_directory('RePEc::Index::Update=HASH(0x9fb4de8)', 'emp') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 863 RePEc::Index::Update::process_directory('RePEc::Index::Update=HASH(0x9fb4de8)', '', undef) called at /home/aras/acis/lib/RePEc/Index/Update.pm line 750 RePEc::Index::Update::process_this('RePEc::Index::Update=HASH(0x9fb4de8)', '/') called at /home/aras/acis/bin/control_daemon.pl line 443 eval {...} called at /home/aras/acis/bin/control_daemon.pl line 429 main::process_request('HASH(0xa42a7f8)', 0) called at /home/aras/acis/bin/control_daemon.pl line 319 I have seen this problem before. Make a note on the server that we are aware of the issue. Cheers, Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel new phone: +7 913 748 8056 skype: thomaskrichel
OK, I added a message. Christian Zimmermann FIGUGEGL! Department of Economics University of Connecticut 341 Mansfield Road, Unit 1063 Storrs, CT 06269-1063 http://ideas.repec.org/zimm/ christian.zimmermann@uconn.edu http://ideas.repec.org/e/pzi1.html On Wed, 10 Jun 2009, Thomas Krichel wrote:
Christian Zimmermann writes
I am getting numerous such complaints. While I was first attributing them to the recent downtime, it seems the difficulties are still lasting and date to before the downtime. The adrepec account looks up-to-date, so something must be wrong elsewhere.
The update daemon is broken.
load_record_from_db_txn( repec:emp:wpaper:wpe03-18, BerkeleyDB::Hash=ARRAY(0xa9d1590) ): Storable binary image v60.57 more recent than I am (v2.7) at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/thaw.al) line 415, <FILE> line 19, at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/logcroak.al) line 76 Storable::logcroak('Storable binary image v60.57 more recent than I am (v2.7) at ...') called at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/thaw.al) line 416 Storable::thaw('y9z0tw\x{4}\x{2}\x{5}\x{0}\x{0}\x{0}\x{6}\x{bc}M6C\x{a}\x{7}present\x{a}\x{1a}emp/wpaper/empWPE03-18.rdf\x{8}\x{80}\x{a}\x{16}FFo...') called at /home/aras/acis/lib/RePEc/Index/Storage/BDBwithTxn.pm line 135 eval {...} called at /home/aras/acis/lib/RePEc/Index/Storage/BDBwithTxn.pm line 135 RePEc::Index::Storage::load_record_from_db_txn('BerkeleyDB::Txn=ARRAY(0xab4c238)', '/home/aras/acis/RI/data/RePEc/history', 'repec:emp:wpaper:wpe03-18') called at /home/aras/acis/lib/RePEc/Index/History/Handle.pm line 114 RePEc::Index::History::Handle::event_record('RePEc::Index::Update::RECORD', 'repec:emp:wpaper:wpe03-18', 'ARDB::Record::ReDIF=HASH(0xaa89898)', 'ReDIF-Paper 1.0', 'emp/wpaper/empWPE03-18.rdf', 0, '0C4ZTJg6rZXoYtBE8oCBGA', 'RePEc::Index::Update=HASH(0x9fb4de8)') called at (eval 103) line 6 RePEc::Index::Update::RECORD('RePEc::Index::Update::RECORD', 'repec:emp:wpaper:wpe03-18', 'ARDB::Record::ReDIF=HASH(0xaa89898)', 'ReDIF-Paper 1.0', 'emp/wpaper/empWPE03-18.rdf', 0, '0C4ZTJg6rZXoYtBE8oCBGA', 'RePEc::Index::Update=HASH(0x9fb4de8)') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 527 RePEc::Index::Update::read_file('RePEc::Index::Update=HASH(0x9fb4de8)', '/home/adrepec/RePEc/remo/emp/wpaper/empWPE03-18.rdf', 'RePEc::Index::FILE=ARRAY(0xaacee68)') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 440 RePEc::Index::Update::check_file('RePEc::Index::Update=HASH(0x9fb4de8)', 'emp/wpaper/empWPE03-18.rdf') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 875 RePEc::Index::Update::process_directory('RePEc::Index::Update=HASH(0x9fb4de8)', 'emp/wpaper') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 863 RePEc::Index::Update::process_directory('RePEc::Index::Update=HASH(0x9fb4de8)', 'emp') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 863 RePEc::Index::Update::process_directory('RePEc::Index::Update=HASH(0x9fb4de8)', '', undef) called at /home/aras/acis/lib/RePEc/Index/Update.pm line 750 RePEc::Index::Update::process_this('RePEc::Index::Update=HASH(0x9fb4de8)', '/') called at /home/aras/acis/bin/control_daemon.pl line 443 eval {...} called at /home/aras/acis/bin/control_daemon.pl line 429 main::process_request('HASH(0xa42a7f8)', 0) called at /home/aras/acis/bin/control_daemon.pl line 319
I have seen this problem before.
Make a note on the server that we are aware of the issue.
Cheers,
Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel new phone: +7 913 748 8056 skype: thomaskrichel
a message like this: Storable binary image v60.57 more recent than I am (v2.7) basically means that the data in the update daemon database is broken. There is no version 60.57 of Storable and never was. I don't know why it is broken or how it got broken. I think I've seen that happen a couple of times in the old days of RAS on nebka, but that were rare occasions, for specific records. Never on a system-wide scale. i'd suggest to throw away all of the rid data (update daemon data) and start from scratch, unless anyone has a better suggestion. -ivan On Wed, Jun 10, 2009 at 5:58 PM, Thomas Krichel<krichel@openlib.org> wrote:
Christian Zimmermann writes
I am getting numerous such complaints. While I was first attributing them to the recent downtime, it seems the difficulties are still lasting and date to before the downtime. The adrepec account looks up-to-date, so something must be wrong elsewhere.
The update daemon is broken.
load_record_from_db_txn( repec:emp:wpaper:wpe03-18, BerkeleyDB::Hash=ARRAY(0xa9d1590) ): Storable binary image v60.57 more recent than I am (v2.7) at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/thaw.al) line 415, <FILE> line 19, at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/logcroak.al) line 76 Storable::logcroak('Storable binary image v60.57 more recent than I am (v2.7) at ...') called at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/thaw.al) line 416 Storable::thaw('y9z0tw\x{4}\x{2}\x{5}\x{0}\x{0}\x{0}\x{6}\x{bc}M6C\x{a}\x{7}present\x{a}\x{1a}emp/wpaper/empWPE03-18.rdf\x{8}\x{80}\x{a}\x{16}FFo...') called at /home/aras/acis/lib/RePEc/Index/Storage/BDBwithTxn.pm line 135 eval {...} called at /home/aras/acis/lib/RePEc/Index/Storage/BDBwithTxn.pm line 135 RePEc::Index::Storage::load_record_from_db_txn('BerkeleyDB::Txn=ARRAY(0xab4c238)', '/home/aras/acis/RI/data/RePEc/history', 'repec:emp:wpaper:wpe03-18') called at /home/aras/acis/lib/RePEc/Index/History/Handle.pm line 114 RePEc::Index::History::Handle::event_record('RePEc::Index::Update::RECORD', 'repec:emp:wpaper:wpe03-18', 'ARDB::Record::ReDIF=HASH(0xaa89898)', 'ReDIF-Paper 1.0', 'emp/wpaper/empWPE03-18.rdf', 0, '0C4ZTJg6rZXoYtBE8oCBGA', 'RePEc::Index::Update=HASH(0x9fb4de8)') called at (eval 103) line 6 RePEc::Index::Update::RECORD('RePEc::Index::Update::RECORD', 'repec:emp:wpaper:wpe03-18', 'ARDB::Record::ReDIF=HASH(0xaa89898)', 'ReDIF-Paper 1.0', 'emp/wpaper/empWPE03-18.rdf', 0, '0C4ZTJg6rZXoYtBE8oCBGA', 'RePEc::Index::Update=HASH(0x9fb4de8)') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 527 RePEc::Index::Update::read_file('RePEc::Index::Update=HASH(0x9fb4de8)', '/home/adrepec/RePEc/remo/emp/wpaper/empWPE03-18.rdf', 'RePEc::Index::FILE=ARRAY(0xaacee68)') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 440 RePEc::Index::Update::check_file('RePEc::Index::Update=HASH(0x9fb4de8)', 'emp/wpaper/empWPE03-18.rdf') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 875 RePEc::Index::Update::process_directory('RePEc::Index::Update=HASH(0x9fb4de8)', 'emp/wpaper') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 863 RePEc::Index::Update::process_directory('RePEc::Index::Update=HASH(0x9fb4de8)', 'emp') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 863 RePEc::Index::Update::process_directory('RePEc::Index::Update=HASH(0x9fb4de8)', '', undef) called at /home/aras/acis/lib/RePEc/Index/Update.pm line 750 RePEc::Index::Update::process_this('RePEc::Index::Update=HASH(0x9fb4de8)', '/') called at /home/aras/acis/bin/control_daemon.pl line 443 eval {...} called at /home/aras/acis/bin/control_daemon.pl line 429 main::process_request('HASH(0xa42a7f8)', 0) called at /home/aras/acis/bin/control_daemon.pl line 319
I have seen this problem before.
Make a note on the server that we are aware of the issue.
Cheers,
Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel new phone: +7 913 748 8056 skype: thomaskrichel
_______________________________________________ RAS-run mailing list RAS-run@lists.openlib.org http://lists.openlib.org/cgi-bin/mailman/listinfo/ras-run
Thomas did a general software update, and this must have broken things (again)... Christian Zimmermann FIGUGEGL! Department of Economics University of Connecticut 341 Mansfield Road, Unit 1063 Storrs, CT 06269-1063 http://ideas.repec.org/zimm/ christian.zimmermann@uconn.edu http://ideas.repec.org/e/pzi1.html On Wed, 10 Jun 2009, Ivan Kurmanov wrote:
a message like this:
Storable binary image v60.57 more recent than I am (v2.7)
basically means that the data in the update daemon database is broken. There is no version 60.57 of Storable and never was. I don't know why it is broken or how it got broken. I think I've seen that happen a couple of times in the old days of RAS on nebka, but that were rare occasions, for specific records. Never on a system-wide scale.
i'd suggest to throw away all of the rid data (update daemon data) and start from scratch, unless anyone has a better suggestion.
-ivan
On Wed, Jun 10, 2009 at 5:58 PM, Thomas Krichel<krichel@openlib.org> wrote:
Christian Zimmermann writes
I am getting numerous such complaints. While I was first attributing them to the recent downtime, it seems the difficulties are still lasting and date to before the downtime. The adrepec account looks up-to-date, so something must be wrong elsewhere.
The update daemon is broken.
load_record_from_db_txn( repec:emp:wpaper:wpe03-18, BerkeleyDB::Hash=ARRAY(0xa9d1590) ): Storable binary image v60.57 more recent than I am (v2.7) at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/thaw.al) line 415, <FILE> line 19, at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/logcroak.al) line 76 Storable::logcroak('Storable binary image v60.57 more recent than I am (v2.7) at ...') called at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/thaw.al) line 416 Storable::thaw('y9z0tw\x{4}\x{2}\x{5}\x{0}\x{0}\x{0}\x{6}\x{bc}M6C\x{a}\x{7}present\x{a}\x{1a}emp/wpaper/empWPE03-18.rdf\x{8}\x{80}\x{a}\x{16}FFo...') called at /home/aras/acis/lib/RePEc/Index/Storage/BDBwithTxn.pm line 135 eval {...} called at /home/aras/acis/lib/RePEc/Index/Storage/BDBwithTxn.pm line 135 RePEc::Index::Storage::load_record_from_db_txn('BerkeleyDB::Txn=ARRAY(0xab4c238)', '/home/aras/acis/RI/data/RePEc/history', 'repec:emp:wpaper:wpe03-18') called at /home/aras/acis/lib/RePEc/Index/History/Handle.pm line 114 RePEc::Index::History::Handle::event_record('RePEc::Index::Update::RECORD', 'repec:emp:wpaper:wpe03-18', 'ARDB::Record::ReDIF=HASH(0xaa89898)', 'ReDIF-Paper 1.0', 'emp/wpaper/empWPE03-18.rdf', 0, '0C4ZTJg6rZXoYtBE8oCBGA', 'RePEc::Index::Update=HASH(0x9fb4de8)') called at (eval 103) line 6 RePEc::Index::Update::RECORD('RePEc::Index::Update::RECORD', 'repec:emp:wpaper:wpe03-18', 'ARDB::Record::ReDIF=HASH(0xaa89898)', 'ReDIF-Paper 1.0', 'emp/wpaper/empWPE03-18.rdf', 0, '0C4ZTJg6rZXoYtBE8oCBGA', 'RePEc::Index::Update=HASH(0x9fb4de8)') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 527 RePEc::Index::Update::read_file('RePEc::Index::Update=HASH(0x9fb4de8)', '/home/adrepec/RePEc/remo/emp/wpaper/empWPE03-18.rdf', 'RePEc::Index::FILE=ARRAY(0xaacee68)') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 440 RePEc::Index::Update::check_file('RePEc::Index::Update=HASH(0x9fb4de8)', 'emp/wpaper/empWPE03-18.rdf') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 875 RePEc::Index::Update::process_directory('RePEc::Index::Update=HASH(0x9fb4de8)', 'emp/wpaper') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 863 RePEc::Index::Update::process_directory('RePEc::Index::Update=HASH(0x9fb4de8)', 'emp') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 863 RePEc::Index::Update::process_directory('RePEc::Index::Update=HASH(0x9fb4de8)', '', undef) called at /home/aras/acis/lib/RePEc/Index/Update.pm line 750 RePEc::Index::Update::process_this('RePEc::Index::Update=HASH(0x9fb4de8)', '/') called at /home/aras/acis/bin/control_daemon.pl line 443 eval {...} called at /home/aras/acis/bin/control_daemon.pl line 429 main::process_request('HASH(0xa42a7f8)', 0) called at /home/aras/acis/bin/control_daemon.pl line 319
I have seen this problem before.
Make a note on the server that we are aware of the issue.
Cheers,
Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel new phone: +7 913 748 8056 skype: thomaskrichel
_______________________________________________ RAS-run mailing list RAS-run@lists.openlib.org http://lists.openlib.org/cgi-bin/mailman/listinfo/ras-run
a general software update couldn't / shouldn't have caused this. On Wed, Jun 10, 2009 at 7:58 PM, Christian Zimmermann<christian.zimmermann@uconn.edu> wrote:
Thomas did a general software update, and this must have broken things (again)...
Christian Zimmermann FIGUGEGL! Department of Economics University of Connecticut 341 Mansfield Road, Unit 1063 Storrs, CT 06269-1063 http://ideas.repec.org/zimm/ christian.zimmermann@uconn.edu http://ideas.repec.org/e/pzi1.html
On Wed, 10 Jun 2009, Ivan Kurmanov wrote:
a message like this:
Storable binary image v60.57 more recent than I am (v2.7)
basically means that the data in the update daemon database is broken. There is no version 60.57 of Storable and never was. I don't know why it is broken or how it got broken. I think I've seen that happen a couple of times in the old days of RAS on nebka, but that were rare occasions, for specific records. Never on a system-wide scale.
i'd suggest to throw away all of the rid data (update daemon data) and start from scratch, unless anyone has a better suggestion.
-ivan
On Wed, Jun 10, 2009 at 5:58 PM, Thomas Krichel<krichel@openlib.org> wrote:
Christian Zimmermann writes
I am getting numerous such complaints. While I was first attributing them to the recent downtime, it seems the difficulties are still lasting and date to before the downtime. The adrepec account looks up-to-date, so something must be wrong elsewhere.
The update daemon is broken.
load_record_from_db_txn( repec:emp:wpaper:wpe03-18, BerkeleyDB::Hash=ARRAY(0xa9d1590) ): Storable binary image v60.57 more recent than I am (v2.7) at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/thaw.al) line 415, <FILE> line 19, at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/logcroak.al) line 76 Storable::logcroak('Storable binary image v60.57 more recent than I am (v2.7) at ...') called at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/thaw.al) line 416
Storable::thaw('y9z0tw\x{4}\x{2}\x{5}\x{0}\x{0}\x{0}\x{6}\x{bc}M6C\x{a}\x{7}present\x{a}\x{1a}emp/wpaper/empWPE03-18.rdf\x{8}\x{80}\x{a}\x{16}FFo...') called at /home/aras/acis/lib/RePEc/Index/Storage/BDBwithTxn.pm line 135 eval {...} called at /home/aras/acis/lib/RePEc/Index/Storage/BDBwithTxn.pm line 135
RePEc::Index::Storage::load_record_from_db_txn('BerkeleyDB::Txn=ARRAY(0xab4c238)', '/home/aras/acis/RI/data/RePEc/history', 'repec:emp:wpaper:wpe03-18') called at /home/aras/acis/lib/RePEc/Index/History/Handle.pm line 114
RePEc::Index::History::Handle::event_record('RePEc::Index::Update::RECORD', 'repec:emp:wpaper:wpe03-18', 'ARDB::Record::ReDIF=HASH(0xaa89898)', 'ReDIF-Paper 1.0', 'emp/wpaper/empWPE03-18.rdf', 0, '0C4ZTJg6rZXoYtBE8oCBGA', 'RePEc::Index::Update=HASH(0x9fb4de8)') called at (eval 103) line 6 RePEc::Index::Update::RECORD('RePEc::Index::Update::RECORD', 'repec:emp:wpaper:wpe03-18', 'ARDB::Record::ReDIF=HASH(0xaa89898)', 'ReDIF-Paper 1.0', 'emp/wpaper/empWPE03-18.rdf', 0, '0C4ZTJg6rZXoYtBE8oCBGA', 'RePEc::Index::Update=HASH(0x9fb4de8)') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 527
RePEc::Index::Update::read_file('RePEc::Index::Update=HASH(0x9fb4de8)', '/home/adrepec/RePEc/remo/emp/wpaper/empWPE03-18.rdf', 'RePEc::Index::FILE=ARRAY(0xaacee68)') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 440
RePEc::Index::Update::check_file('RePEc::Index::Update=HASH(0x9fb4de8)', 'emp/wpaper/empWPE03-18.rdf') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 875
RePEc::Index::Update::process_directory('RePEc::Index::Update=HASH(0x9fb4de8)', 'emp/wpaper') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 863
RePEc::Index::Update::process_directory('RePEc::Index::Update=HASH(0x9fb4de8)', 'emp') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 863
RePEc::Index::Update::process_directory('RePEc::Index::Update=HASH(0x9fb4de8)', '', undef) called at /home/aras/acis/lib/RePEc/Index/Update.pm line 750
RePEc::Index::Update::process_this('RePEc::Index::Update=HASH(0x9fb4de8)', '/') called at /home/aras/acis/bin/control_daemon.pl line 443 eval {...} called at /home/aras/acis/bin/control_daemon.pl line 429 main::process_request('HASH(0xa42a7f8)', 0) called at /home/aras/acis/bin/control_daemon.pl line 319
I have seen this problem before.
Make a note on the server that we are aware of the issue.
Cheers,
Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel new phone: +7 913 748 8056 skype: thomaskrichel
_______________________________________________ RAS-run mailing list RAS-run@lists.openlib.org http://lists.openlib.org/cgi-bin/mailman/listinfo/ras-run
perl moved to 5.10. Previous moves have been problematic, if I remember right. Christian Zimmermann FIGUGEGL! Department of Economics University of Connecticut 341 Mansfield Road, Unit 1063 Storrs, CT 06269-1063 http://ideas.repec.org/zimm/ christian.zimmermann@uconn.edu http://ideas.repec.org/e/pzi1.html On Wed, 10 Jun 2009, Ivan Kurmanov wrote:
a general software update couldn't / shouldn't have caused this.
On Wed, Jun 10, 2009 at 7:58 PM, Christian Zimmermann<christian.zimmermann@uconn.edu> wrote:
Thomas did a general software update, and this must have broken things (again)...
Christian Zimmermann FIGUGEGL! Department of Economics University of Connecticut 341 Mansfield Road, Unit 1063 Storrs, CT 06269-1063 http://ideas.repec.org/zimm/ christian.zimmermann@uconn.edu http://ideas.repec.org/e/pzi1.html
On Wed, 10 Jun 2009, Ivan Kurmanov wrote:
a message like this:
Storable binary image v60.57 more recent than I am (v2.7)
basically means that the data in the update daemon database is broken. There is no version 60.57 of Storable and never was. I don't know why it is broken or how it got broken. I think I've seen that happen a couple of times in the old days of RAS on nebka, but that were rare occasions, for specific records. Never on a system-wide scale.
i'd suggest to throw away all of the rid data (update daemon data) and start from scratch, unless anyone has a better suggestion.
-ivan
On Wed, Jun 10, 2009 at 5:58 PM, Thomas Krichel<krichel@openlib.org> wrote:
Christian Zimmermann writes
I am getting numerous such complaints. While I was first attributing them to the recent downtime, it seems the difficulties are still lasting and date to before the downtime. The adrepec account looks up-to-date, so something must be wrong elsewhere.
The update daemon is broken.
load_record_from_db_txn( repec:emp:wpaper:wpe03-18, BerkeleyDB::Hash=ARRAY(0xa9d1590) ): Storable binary image v60.57 more recent than I am (v2.7) at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/thaw.al) line 415, <FILE> line 19, at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/logcroak.al) line 76 Storable::logcroak('Storable binary image v60.57 more recent than I am (v2.7) at ...') called at ../../lib/Storable.pm (autosplit into ../../lib/auto/Storable/thaw.al) line 416
Storable::thaw('y9z0tw\x{4}\x{2}\x{5}\x{0}\x{0}\x{0}\x{6}\x{bc}M6C\x{a}\x{7}present\x{a}\x{1a}emp/wpaper/empWPE03-18.rdf\x{8}\x{80}\x{a}\x{16}FFo...') called at /home/aras/acis/lib/RePEc/Index/Storage/BDBwithTxn.pm line 135 eval {...} called at /home/aras/acis/lib/RePEc/Index/Storage/BDBwithTxn.pm line 135
RePEc::Index::Storage::load_record_from_db_txn('BerkeleyDB::Txn=ARRAY(0xab4c238)', '/home/aras/acis/RI/data/RePEc/history', 'repec:emp:wpaper:wpe03-18') called at /home/aras/acis/lib/RePEc/Index/History/Handle.pm line 114
RePEc::Index::History::Handle::event_record('RePEc::Index::Update::RECORD', 'repec:emp:wpaper:wpe03-18', 'ARDB::Record::ReDIF=HASH(0xaa89898)', 'ReDIF-Paper 1.0', 'emp/wpaper/empWPE03-18.rdf', 0, '0C4ZTJg6rZXoYtBE8oCBGA', 'RePEc::Index::Update=HASH(0x9fb4de8)') called at (eval 103) line 6 RePEc::Index::Update::RECORD('RePEc::Index::Update::RECORD', 'repec:emp:wpaper:wpe03-18', 'ARDB::Record::ReDIF=HASH(0xaa89898)', 'ReDIF-Paper 1.0', 'emp/wpaper/empWPE03-18.rdf', 0, '0C4ZTJg6rZXoYtBE8oCBGA', 'RePEc::Index::Update=HASH(0x9fb4de8)') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 527
RePEc::Index::Update::read_file('RePEc::Index::Update=HASH(0x9fb4de8)', '/home/adrepec/RePEc/remo/emp/wpaper/empWPE03-18.rdf', 'RePEc::Index::FILE=ARRAY(0xaacee68)') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 440
RePEc::Index::Update::check_file('RePEc::Index::Update=HASH(0x9fb4de8)', 'emp/wpaper/empWPE03-18.rdf') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 875
RePEc::Index::Update::process_directory('RePEc::Index::Update=HASH(0x9fb4de8)', 'emp/wpaper') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 863
RePEc::Index::Update::process_directory('RePEc::Index::Update=HASH(0x9fb4de8)', 'emp') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 863
RePEc::Index::Update::process_directory('RePEc::Index::Update=HASH(0x9fb4de8)', '', undef) called at /home/aras/acis/lib/RePEc/Index/Update.pm line 750
RePEc::Index::Update::process_this('RePEc::Index::Update=HASH(0x9fb4de8)', '/') called at /home/aras/acis/bin/control_daemon.pl line 443 eval {...} called at /home/aras/acis/bin/control_daemon.pl line 429 main::process_request('HASH(0xa42a7f8)', 0) called at /home/aras/acis/bin/control_daemon.pl line 319
I have seen this problem before.
Make a note on the server that we are aware of the issue.
Cheers,
Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel new phone: +7 913 748 8056 skype: thomaskrichel
_______________________________________________ RAS-run mailing list RAS-run@lists.openlib.org http://lists.openlib.org/cgi-bin/mailman/listinfo/ras-run
Still not knowing where that function lives, I have now just commented this part of the code where the client dies, in Update.pm if ( $ABORT ) { return 0; } ## commented out to circumvent files_list bug ## ##my $flist = $drecord->files_list(); ##foreach ( @$flist ) { ## if ( $children{$_} ) { ## } else { ## $self->disappeared_file( "$dir$_" ); # XXX ## if ( $ABORT ) { return 0; } ## while ( $PAUSE ) { sleep 3; } ## } ##} Cheers, Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel new phone: +7 913 748 8056 skype: thomaskrichel
this is not a solution. files_list is a property of a directory object (something::DIR if i remember right). In your attempts to run "updareq foo / 0" it is being attempted on a file object. Which is wrong. You need to find out on which particular file it is being attempted and why. But commenting out this piece would not solve anything. -i On Thu, Jun 11, 2009 at 6:32 PM, Thomas Krichel<krichel@openlib.org> wrote:
Still not knowing where that function lives, I have now just commented this part of the code where the client dies, in Update.pm
if ( $ABORT ) { return 0; }
## commented out to circumvent files_list bug ## ##my $flist = $drecord->files_list(); ##foreach ( @$flist ) { ## if ( $children{$_} ) { ## } else { ## $self->disappeared_file( "$dir$_" ); # XXX ## if ( $ABORT ) { return 0; } ## while ( $PAUSE ) { sleep 3; } ## } ##}
Cheers,
Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel new phone: +7 913 748 8056 skype: thomaskrichel
_______________________________________________ RAS-run mailing list RAS-run@lists.openlib.org http://lists.openlib.org/cgi-bin/mailman/listinfo/ras-run
Thomas Krichel writes
Still not knowing where that function lives, I have now just commented this part of the code where the client dies, in Update.pm
if ( $ABORT ) { return 0; }
## commented out to circumvent files_list bug ## ##my $flist = $drecord->files_list(); ##foreach ( @$flist ) { ## if ( $children{$_} ) { ## } else { ## $self->disappeared_file( "$dir$_" ); # XXX ## if ( $ABORT ) { return 0; } ## while ( $PAUSE ) { sleep 3; } ## } ##}
The current arrangements are more sophisticated. ## commented out to circumvent files_list bug my $flist = eval { $drecord->files_list(); } || []; if($@) { error(Dumper $drecord); } foreach ( @$flist ) { if ( $children{$_} ) { } else { $self->disappeared_file( "$dir$_" ); # XXX if ( $ABORT ) { return 0; } while ( $PAUSE ) { sleep 3; } } } eval { $drecord -> files_list_set ( \@children ); }; $drecord -> last_observed_set ( $session_time ); I just added the if($@) { error(Dumper $drecord); } with a use Data::Dumper; at the top, maybe that will point to the error. Cheers, Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel skype: thomaskrichel
I have no solution, but I have written a workaround, firing up rid for an archive when there are some changes in that archive. This is done at rsyncing time from raneb. The following says it all. adrepec@raneb:~/perl$ cat rsync_to_nebka_with_rid #!/usr/bin/perl my $home=$ENV{'HOME'}; my $tmp_file="/tmp/rsync_to_nebka_with_rid"; my $exclude_file="$home/etc/nebka_repec_remo.exclude"; my $rsync="rm $tmp_file ; /usr/bin/rsync -va --exclude-from $exclude_file --delete $home/RePEc/opt/remo/ 'adrepec\@nebka:RePEc/remo' > $tmp_file"; #print "$rsync\n"; system($rsync); # # parse tmp_file, collect archives to do # my $archive_to_do; foreach my $line (`cat $tmp_file`) { chomp $line; if($line=~m|[^/]\.rdf$|i) { #print "found: $line\n"; if($line=~m|^([^/]{3})/|) { $archive_to_do->{$1}=1; } } } foreach my $archive (keys %{$archive_to_do}) { my $s="ssh aras\@nebka acis/bin/updareq RePEc /$archive 31556926"; print "$s\n"; system($s); sleep 300; } Cheers, Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel skype: thomaskrichel Thomas Krichel writes
Thomas Krichel writes
Still not knowing where that function lives, I have now just commented this part of the code where the client dies, in Update.pm
if ( $ABORT ) { return 0; }
## commented out to circumvent files_list bug ## ##my $flist = $drecord->files_list(); ##foreach ( @$flist ) { ## if ( $children{$_} ) { ## } else { ## $self->disappeared_file( "$dir$_" ); # XXX ## if ( $ABORT ) { return 0; } ## while ( $PAUSE ) { sleep 3; } ## } ##}
The current arrangements are more sophisticated.
## commented out to circumvent files_list bug my $flist = eval { $drecord->files_list(); } || []; if($@) { error(Dumper $drecord); } foreach ( @$flist ) { if ( $children{$_} ) { } else { $self->disappeared_file( "$dir$_" ); # XXX if ( $ABORT ) { return 0; } while ( $PAUSE ) { sleep 3; } } }
eval { $drecord -> files_list_set ( \@children ); }; $drecord -> last_observed_set ( $session_time );
I just added the
if($@) { error(Dumper $drecord); }
with a
use Data::Dumper;
at the top, maybe that will point to the error.
Cheers,
Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel skype: thomaskrichel
_______________________________________________ RAS-run mailing list RAS-run@lists.openlib.org http://lists.openlib.org/cgi-bin/mailman/listinfo/ras-run
-- Cheers, Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel skype: thomaskrichel
what does updareq RePEc / result with? does it fail? it appears very stupid to me to monitor filesystem to run update deamon which then monitors filesystem. (in a way) -ivan On Mon, Jul 13, 2009 at 3:47 PM, Thomas Krichel<krichel@openlib.org> wrote:
I have no solution, but I have written a workaround, firing up rid for an archive when there are some changes in that archive. This is done at rsyncing time from raneb. The following says it all.
adrepec@raneb:~/perl$ cat rsync_to_nebka_with_rid #!/usr/bin/perl
my $home=$ENV{'HOME'}; my $tmp_file="/tmp/rsync_to_nebka_with_rid"; my $exclude_file="$home/etc/nebka_repec_remo.exclude"; my $rsync="rm $tmp_file ; /usr/bin/rsync -va --exclude-from $exclude_file --delete $home/RePEc/opt/remo/ 'adrepec\@nebka:RePEc/remo' > $tmp_file";
#print "$rsync\n"; system($rsync);
# # parse tmp_file, collect archives to do # my $archive_to_do; foreach my $line (`cat $tmp_file`) { chomp $line; if($line=~m|[^/]\.rdf$|i) { #print "found: $line\n"; if($line=~m|^([^/]{3})/|) { $archive_to_do->{$1}=1; } } }
foreach my $archive (keys %{$archive_to_do}) { my $s="ssh aras\@nebka acis/bin/updareq RePEc /$archive 31556926"; print "$s\n"; system($s); sleep 300; }
Cheers,
Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel skype: thomaskrichel Thomas Krichel writes
Thomas Krichel writes
Still not knowing where that function lives, I have now just commented this part of the code where the client dies, in Update.pm
if ( $ABORT ) { return 0; }
## commented out to circumvent files_list bug ## ##my $flist = $drecord->files_list(); ##foreach ( @$flist ) { ## if ( $children{$_} ) { ## } else { ## $self->disappeared_file( "$dir$_" ); # XXX ## if ( $ABORT ) { return 0; } ## while ( $PAUSE ) { sleep 3; } ## } ##}
The current arrangements are more sophisticated.
## commented out to circumvent files_list bug my $flist = eval { $drecord->files_list(); } || []; if($@) { error(Dumper $drecord); } foreach ( @$flist ) { if ( $children{$_} ) { } else { $self->disappeared_file( "$dir$_" ); # XXX if ( $ABORT ) { return 0; } while ( $PAUSE ) { sleep 3; } } }
eval { $drecord -> files_list_set ( \@children ); }; $drecord -> last_observed_set ( $session_time );
I just added the
if($@) { error(Dumper $drecord); }
with a
use Data::Dumper;
at the top, maybe that will point to the error.
Cheers,
Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel skype: thomaskrichel
_______________________________________________ RAS-run mailing list RAS-run@lists.openlib.org http://lists.openlib.org/cgi-bin/mailman/listinfo/ras-run
--
Cheers,
Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel skype: thomaskrichel
_______________________________________________ RAS-run mailing list RAS-run@lists.openlib.org http://lists.openlib.org/cgi-bin/mailman/listinfo/ras-run
Ivan Kurmanov writes
what does updareq RePEc / result with? does it fail?
We have crontabbed 33 2 * * * /home/aras/acis/bin/updareq RePEc / 1000000000 and that fails to include some recent files, as CZ has been complaining about for some time now. I agree my approach is a cludge.
it appears very stupid to me to monitor filesystem to run update deamon which then monitors filesystem. (in a way)
Yeah, but it is done at rsync time, so at that time you will monitor anyway. Cheers, Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel skype: thomaskrichel
Thomas, what do the logs say? -ivan On Mon, Jul 13, 2009 at 4:57 PM, Thomas Krichel<krichel@openlib.org> wrote:
Ivan Kurmanov writes
what does updareq RePEc / result with? does it fail?
We have crontabbed
33 2 * * * /home/aras/acis/bin/updareq RePEc / 1000000000
and that fails to include some recent files, as CZ has been complaining about for some time now. I agree my approach is a cludge.
it appears very stupid to me to monitor filesystem to run update deamon which then monitors filesystem. (in a way)
Yeah, but it is done at rsync time, so at that time you will monitor anyway.
Cheers,
Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel skype: thomaskrichel
Ivan Kurmanov writes
Thomas, what do the logs say?
There are some reported errors pdate_ch0.log:Mon Jul 13 03:31:22 2009 Error: Can't locate object method "last_read" via package "RePEc::Index::DIR" at /home/aras/acis/lib/RePEc/Index/Update.pm line 389, <FILE> line 8. update_ch0.log:Mon Jul 13 03:51:05 2009 Error: Can't locate object method "last_read" via package "RePEc::Index::DIR" at /home/aras/acis/lib/RePEc/Index/Update.pm line 389. update_ch0.log:Mon Jul 13 04:09:43 2009 Error: Wide character in subroutine entry at /home/aras/acis/lib/RePEc/Index/Collection/CitationsAMF.pm line 163. update_ch1.log:Mon Jul 13 09:01:00 2009 Error: Assertion failed! update_ch1.log:Mon Jul 13 09:06:20 2009 Error: Assertion failed! update_ch1.log:Mon Jul 13 09:07:10 2009 Error: Assertion failed! update_ch1.log:Mon Jul 13 09:47:14 2009 Error: cannot store record 'repec:per:2005-04-12:robert_j_barro' in ObjectDB at /home/aras/acis/lib/ARDB.pm line 190. update_ch1.log:Mon Jul 13 09:52:52 2009 Error: cannot store record 'repec:per:1944-04-19:james_j__heckman' in ObjectDB at /home/aras/acis/lib/ARDB.pm line 190. update_ch2.log:Mon Jul 13 09:01:00 2009 Error: Assertion failed! update_ch3.log:Mon Jul 13 09:01:00 2009 Error: Assertion failed! update_ch4.log:Mon Jul 13 09:01:00 2009 Error: Assertion failed! Remember I still have two evals that provent the code from bombing out, in ~/acis/lib/RePEc/Index/Update.pm ## commented out to circumvent files_list bug my $flist = eval { $drecord->files_list(); } || []; if($@) { error(Dumper $drecord); } foreach ( @$flist ) { if ( $children{$_} ) { } else { $self->disappeared_file( "$dir$_" ); # XXX if ( $ABORT ) { return 0; } while ( $PAUSE ) { sleep 3; } } } eval { $drecord -> files_list_set ( \@children ); }; $drecord -> last_observed_set ( $session_time ); # $drecord -> present_set ( 1 ); We are also getting tons of errors save record problem: Inappropriate ioctl for device / Logging region out of memory; you may need to increase its size I have tried to understand this, to no avail. Cheers, Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel skype: thomaskrichel
until you fix that, nothing will help On Mon, Jul 13, 2009 at 5:31 PM, Thomas Krichel<krichel@openlib.org> wrote:
Ivan Kurmanov writes
Thomas, what do the logs say?
There are some reported errors
pdate_ch0.log:Mon Jul 13 03:31:22 2009 Error: Can't locate object method "last_read" via package "RePEc::Index::DIR" at /home/aras/acis/lib/RePEc/Index/Update.pm line 389, <FILE> line 8. update_ch0.log:Mon Jul 13 03:51:05 2009 Error: Can't locate object method "last_read" via package "RePEc::Index::DIR" at /home/aras/acis/lib/RePEc/Index/Update.pm line 389. update_ch0.log:Mon Jul 13 04:09:43 2009 Error: Wide character in subroutine entry at /home/aras/acis/lib/RePEc/Index/Collection/CitationsAMF.pm line 163. update_ch1.log:Mon Jul 13 09:01:00 2009 Error: Assertion failed! update_ch1.log:Mon Jul 13 09:06:20 2009 Error: Assertion failed! update_ch1.log:Mon Jul 13 09:07:10 2009 Error: Assertion failed! update_ch1.log:Mon Jul 13 09:47:14 2009 Error: cannot store record 'repec:per:2005-04-12:robert_j_barro' in ObjectDB at /home/aras/acis/lib/ARDB.pm line 190. update_ch1.log:Mon Jul 13 09:52:52 2009 Error: cannot store record 'repec:per:1944-04-19:james_j__heckman' in ObjectDB at /home/aras/acis/lib/ARDB.pm line 190. update_ch2.log:Mon Jul 13 09:01:00 2009 Error: Assertion failed! update_ch3.log:Mon Jul 13 09:01:00 2009 Error: Assertion failed! update_ch4.log:Mon Jul 13 09:01:00 2009 Error: Assertion failed!
Remember I still have two evals that provent the code from bombing out, in ~/acis/lib/RePEc/Index/Update.pm
## commented out to circumvent files_list bug my $flist = eval { $drecord->files_list(); } || []; if($@) { error(Dumper $drecord); } foreach ( @$flist ) { if ( $children{$_} ) { } else { $self->disappeared_file( "$dir$_" ); # XXX if ( $ABORT ) { return 0; } while ( $PAUSE ) { sleep 3; } } }
eval { $drecord -> files_list_set ( \@children ); }; $drecord -> last_observed_set ( $session_time ); # $drecord -> present_set ( 1 );
We are also getting tons of errors
save record problem: Inappropriate ioctl for device / Logging region out of memory; you may need to increase its size
I have tried to understand this, to no avail.
Cheers,
Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel skype: thomaskrichel
Ivan Kurmanov writes
until you fix that, nothing will help
You are probably right, but there appear to be tons of issuse here. I have stopped rid. Cheers, Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel skype: thomaskrichel
I ran a db4.6_upgrade on the files in RI/data/ACIS. Started rid. Cheers, Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel skype: thomaskrichel
Ivan Kurmanov writes
i'd suggest to throw away all of the rid data (update daemon data) and start from scratch, unless anyone has a better suggestion.
With a create_tables -f ? This would imply a day of downtime at least. I would rather try an 'updareq foo / 0' Cheers, Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel new phone: +7 913 748 8056 skype: thomaskrichel
Thomas Krichel writes
I would rather try an 'updareq foo / 0'
I have done that, it runs fines for a while, then it dies Error: Can't locate object method "files_list" via package "RePEc::Index::FILE" at /home/aras/acis/lib/RePEc/Index/Update.pm line 884, <FILE> line 2992. This is a problem I have not spotted before. Again, this could just be an environment variable thing. I am adding PERL5LIB=$HOME/usr/lib/perl:$HOME/acis/lib:$HOME/acis/lib/ARDB to etc/crontab and export PERL5LIB=$HOME/usr/lib/perl:$HOME/acis/lib:$HOME/acis/lib/ARDB to .bash_profile and .bashrc Cheers, Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel new phone: +7 913 748 8056 skype: thomaskrichel
Another try, same thing, the client dies with Thu Jun 11 02:13:11 2009 Error: Can't locate object method "files_list" via pack age "RePEc::Index::FILE" at /home/aras/acis/lib/RePEc/Index/Update.pm line 884, <FILE> line 1364. I don't see where files_list is defined aras@nebka:~/acis/lib$ grep -r files_list . ./RePEc/Index.pm: my $files = $root -> files_list(); ./RePEc/Index.pm: qw( filename first_observed last_observed files_list present ); ./RePEc/Index/Update.pm: my $list = $frecord -> files_list(); ./RePEc/Index/Update.pm: my $flist = $drecord->files_list(); ./RePEc/Index/Update.pm: $drecord -> files_list_set ( \@children ); ./RePEc/Index/Update.pm: my $flist = $drecord->files_list(); ./RePEc/Index/Update.pm: $drecord -> files_list_set ( $flist ); ./RePEc/Index/Update.pm~: my $list = $frecord -> files_list(); ./RePEc/Index/Update.pm~: my $flist = $drecord->files_list(); ./RePEc/Index/Update.pm~: $drecord -> files_list_set ( \@children ); ./RePEc/Index/Update.pm~: my $flist = $drecord->files_list(); ./RePEc/Index/Update.pm~: $drecord -> files_list_set ( $flist ); awho@chichek:~/acis/lib$ grep -r files_list . grep: ./ACIS/Web/.#Contributions_cardiff.pm: No such file or directory ./RePEc/Index.pm: my $files = $root -> files_list(); ./RePEc/Index.pm: qw( filename first_observed last_observed files_list present ); ./RePEc/Index/Update.pm: my $list = $frecord -> files_list(); ./RePEc/Index/Update.pm: my $flist = $drecord->files_list(); ./RePEc/Index/Update.pm: $drecord -> files_list_set ( \@children ); ./RePEc/Index/Update.pm: my $flist = $drecord->files_list(); ./RePEc/Index/Update.pm: $drecord -> files_list_set ( $flist ); Cheers, Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel new phone: +7 913 748 8056 skype: thomaskrichel
With a create_tables -f ?
no. create_tables creates mysql tables. update deamon data is in berkeley db. I don't remember how to recreate that.
I would rather try an 'updareq foo / 0'
i don't understand what is "foo" here and how that is supposed to help. -i On Thu, Jun 11, 2009 at 6:21 AM, Thomas Krichel<krichel@openlib.org> wrote:
Ivan Kurmanov writes
i'd suggest to throw away all of the rid data (update daemon data) and start from scratch, unless anyone has a better suggestion.
With a create_tables -f ?
This would imply a day of downtime at least.
I would rather try an 'updareq foo / 0'
Cheers,
Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel new phone: +7 913 748 8056 skype: thomaskrichel
Ivan Kurmanov writes
With a create_tables -f ?
no. create_tables creates mysql tables. update deamon data is in berkeley db. I don't remember how to recreate that.
But you would still have to delete the mysql tables, otherwise you run the risk of zombie records.
I would rather try an 'updareq foo / 0'
i don't understand what is "foo" here and how that is supposed to help.
Would be RePEc, ACIS, CitEc, all db's rid knows about. Cheers, Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel new phone: +7 913 748 8056 skype: thomaskrichel
On the other hand aras@nebka:~/acis/RI$ tail update_ch0.log RECORD PROCESS: repec:gde:journl:gde_v61_n1_p1-28|ReDIF-Article 1.0 RECORD NEW: repec:gde:journl:gde_v61_n1_p1-28 RECORD PROCESS: repec:gde:journl:gde_v61_n1_p29-59|ReDIF-Article 1.0 RECORD NEW: repec:gde:journl:gde_v61_n1_p29-59 RECORD PROCESS: repec:gde:journl:gde_v61_n1_p61-101|ReDIF-Article 1.0 RECORD NEW: repec:gde:journl:gde_v61_n1_p61-101 RECORD PROCESS: repec:gde:journl:gde_v61_n1_p103-126|ReDIF-Article 1.0 RECORD NEW: repec:gde:journl:gde_v61_n1_p103-126 RECORD PROCESS: repec:gde:journl:gde_v61_n2_p131-169|ReDIF-Article 1.0 RECORD NEW: repec:gde:journl:gde_v61_n2_p131-169 It seems to be updating now. There is a crontab entry for it, maybe when called from cron it does not work (environment variable issue?) My gf is calling me to bed... Cheers, Thomas Krichel http://openlib.org/home/krichel RePEc:per:1965-06-05:thomas_krichel new phone: +7 913 748 8056 skype: thomaskrichel
participants (3)
-
Christian Zimmermann -
Ivan Kurmanov -
Thomas Krichel