I have received several complaints that new papers and institutions do not make it to RAS after several days. Are these update processes running? 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
Christian Zimmermann writes
I have received several complaints that new papers and institutions do not make it to RAS after several days. Are these update processes running?
There are no changes to the updates. Can I have some specifics? Cheers, Thomas Krichel http://openlib.org/home/krichel http://authorclaim.org/profile/pkr1 skype: thomaskrichel
There have been complaints about the following: RePEc:edi:irkmwin RePEc:aee:wpaper:1010 RePEc:taf:specan:v:5:y:2010:i:2:p:205-227 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, 5 Jan 2011, Thomas Krichel wrote:
Christian Zimmermann writes
I have received several complaints that new papers and institutions do not make it to RAS after several days. Are these update processes running?
There are no changes to the updates. Can I have some specifics?
Cheers,
Thomas Krichel http://openlib.org/home/krichel http://authorclaim.org/profile/pkr1 skype: thomaskrichel
Christian Zimmermann writes
There have been complaints about the following:
RePEc:edi:irkmwin
U DATAFILE_START: edi/inst/aiuvanl.rdf Wed Jan 5 21:27:01 2011 Error: Assertion failed! at /usr/share/perl5/Carp/Assert.pm line 281 Carp::Assert::assert(undef) called at /home/aras/acis/lib/RePEc/Index/Storage/BDBwithTxn.pm line 120 RePEc::Index::Storage::load_record_from_db_txn(undef, '/home/aras/acis/RI/data/RePEc/history', 'repec:edi:aiuvanl') called at /home/aras/acis/lib/RePEc/Index/History/Handle.pm line 127 RePEc::Index::History::Handle::event_record('RePEc::Index::Update::RECORD', 'repec:edi:aiuvanl', 'ARDB::Record::ReDIF=HASH(0xa3f5e88)', 'ReDIF-Institution 1.0', 'edi/inst/aiuvanl.rdf', 4, 'aDzV+F10j4RLNp0P4SutRQ', 'RePEc::Index::Update=HASH(0x9c048a8)') called at (eval 106) line 6 RePEc::Index::Update::RECORD('RePEc::Index::Update::RECORD', 'repec:edi:aiuvanl', 'ARDB::Record::ReDIF=HASH(0xa3f5e88)', 'ReDIF-Institution 1.0', 'edi/inst/aiuvanl.rdf', 4, 'aDzV+F10j4RLNp0P4SutRQ', 'RePEc::Index::Update=HASH(0x9c048a8)') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 519 RePEc::Index::Update::read_file('RePEc::Index::Update=HASH(0x9c048a8)', '/home/adrepec/RePEc/remo/edi/inst/aiuvanl.rdf', 'RePEc::Index::FILE=ARRAY(0xa385e68)') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 432 RePEc::Index::Update::check_file('RePEc::Index::Update=HASH(0x9c048a8)', 'edi/inst/aiuvanl.rdf') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 872 RePEc::Index::Update::process_directory('RePEc::Index::Update=HASH(0x9c048a8)', 'edi/inst') called at /home/aras/acis/lib/RePEc/Index/Update.pm line 861 RePEc::Index::Update::process_directory('RePEc::Index::Update=HASH(0x9c048a8)', 'edi', undef) called at /home/aras/acis/lib/RePEc/Index/Update.pm line 741 RePEc::Index::Update::process_this('RePEc::Index::Update=HASH(0x9c048a8)', '/edi') 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(0x9749918)', 0) called at /home/aras/acis/bin/control_daemon.pl line 319 I suspect some bdb corruption. Cheers, Thomas Krichel http://openlib.org/home/krichel http://authorclaim.org/profile/pkr1 skype: thomaskrichel
Thomas Krichel writes
I suspect some bdb corruption.
I suspect it comes from running out of disk space. I have been urging a bigger disk for years. With a tera costing 100 bucks, it is worth me spending hour on manually fixing disk issues? Cheers, Thomas Krichel http://openlib.org/home/krichel http://authorclaim.org/profile/pkr1 skype: thomaskrichel
But why would we be running out of disk space? It was at 80% a couple of weeks ago? 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, 5 Jan 2011, Thomas Krichel wrote:
Thomas Krichel writes
I suspect some bdb corruption.
I suspect it comes from running out of disk space.
I have been urging a bigger disk for years. With a tera costing 100 bucks, it is worth me spending hour on manually fixing disk issues?
Cheers,
Thomas Krichel http://openlib.org/home/krichel http://authorclaim.org/profile/pkr1 skype: thomaskrichel
Christian Zimmermann writes
But why would we be running out of disk space? It was at 80% a couple of weeks ago?
We had a 100% a few days before... the BDB's are corrupt. I have removed the cron. Cheers, Thomas Krichel http://openlib.org/home/krichel http://authorclaim.org/profile/pkr1 skype: thomaskrichel
What is eating so much space in so little time? logs? In any case, once I am in St Louis, the first priority will be to move the two machines so that we have better sysadmin support, then acquire a replacement for nebka with more space and power. After that, get a programmer to fix and amend ACIS to satisfy what I have calling for for years. 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, 5 Jan 2011, Thomas Krichel wrote:
Christian Zimmermann writes
But why would we be running out of disk space? It was at 80% a couple of weeks ago?
We had a 100% a few days before...
the BDB's are corrupt. I have removed the cron.
Cheers,
Thomas Krichel http://openlib.org/home/krichel http://authorclaim.org/profile/pkr1 skype: thomaskrichel
Christian Zimmermann writes
What is eating so much space in so little time? logs?
Yes, I thihnk so.
In any case, once I am in St Louis, the first priority will be to move the two machines so that we have better sysadmin support, then acquire a replacement for nebka with more space and power. After that, get a programmer to fix and amend ACIS to satisfy what I have calling for for years.
Sounds good. For a replacement, I think a cloud-based solution sholud be considered. Cheers, Thomas Krichel http://openlib.org/home/krichel http://authorclaim.org/profile/pkr1 skype: thomaskrichel
It looks like we can not recover... aras@nebka:~$ *** glibc detected *** db4.6_dump: double free or corruption (!prev): 0x0896cd38 *** ======= Backtrace: ========= /lib/i686/cmov/libc.so.6[0xb7d46764] /lib/i686/cmov/libc.so.6(cfree+0x96)[0xb7d48966] /usr/lib/libdb-4.6.so(__os_free+0x40)[0xb7f566d0] /usr/lib/libdb-4.6.so(__ham_salvage+0x215)[0xb7ea66d5] /usr/lib/libdb-4.6.so(__db_salvage+0x257)[0xb7ed2e17] /usr/lib/libdb-4.6.so[0xb7ed48c9] /usr/lib/libdb-4.6.so(__db_verify_internal+0x108)[0xb7ed68a8] /usr/lib/libdb-4.6.so(__db_verify_pp+0x43)[0xb7ed6a13] db4.6_dump[0x80497ee] /lib/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7cee455] db4.6_dump[0x8048931] ======= Memory map: ======== 08048000-0804a000 r-xp 00000000 08:01 4440615 /usr/bin/db4.6_dump 0804a000-0804b000 rwxp 00002000 08:01 4440615 /usr/bin/db4.6_dump 08802000-0898b000 rwxp 08802000 00:00 0 [heap] b7b00000-b7b21000 rwxp b7b00000 00:00 0 b7b21000-b7c00000 ---p b7b21000 00:00 0 b7c71000-b7c7d000 r-xp 00000000 08:01 14319630 /lib/libgcc_s.so.1 b7c7d000-b7c7e000 rwxp 0000b000 08:01 14319630 /lib/libgcc_s.so.1 b7c83000-b7cd8000 rwxp b7c83000 00:00 0 b7cd8000-b7e2d000 r-xp 00000000 08:01 14172175 /lib/i686/cmov/libc-2.7.so b7e2d000-b7e2e000 r-xp 00155000 08:01 14172175 /lib/i686/cmov/libc-2.7.so b7e2e000-b7e30000 rwxp 00156000 08:01 14172175 /lib/i686/cmov/libc-2.7.so b7e30000-b7e34000 rwxp b7e30000 00:00 0 b7e34000-b7e49000 r-xp 00000000 08:01 14239170 /lib/i686/cmov/libpthread-2.7.so b7e49000-b7e4b000 rwxp 00014000 08:01 14239170 /lib/i686/cmov/libpthread-2.7.so b7e4b000-b7e4d000 rwxp b7e4b000 00:00 0 b7e4d000-b7f7d000 r-xp 00000000 08:01 4456487 /usr/lib/libdb-4.6.so b7f7d000-b7f80000 rwxp 00130000 08:01 4456487 /usr/lib/libdb-4.6.so b7f85000-b7f87000 rwxp b7f85000 00:00 0 b7f87000-b7f88000 r-xp b7f87000 00:00 0 [vdso] b7f88000-b7fa2000 r-xp 00000000 08:01 14319985 /lib/ld-2.7.so b7fa2000-b7fa4000 rwxp 0001a000 08:01 14319985 /lib/ld-2.7.so bff8f000-bffa4000 rw-p bffeb000 00:00 0 [stack] Cheers, Thomas Krichel http://openlib.org/home/krichel http://authorclaim.org/profile/pkr1 skype: thomaskrichel
I will try to see if I can get a copy from backup.... Cheers, Thomas Krichel http://openlib.org/home/krichel http://authorclaim.org/profile/pkr1 skype: thomaskrichel
Christian Zimmermann writes
What is eating so much space in so little time? logs?
In any case, once I am in St Louis, the first priority will be to move the two machines so that we have better sysadmin support,
I doubt you will get much better than me, look when the exim problem was apparent, I patched nebka with 30 minutes, a box that I know got rootkitted three days later via that exim route... But I'd be happy to give up this thankless task! Cheers, Thomas Krichel http://openlib.org/home/krichel http://authorclaim.org/profile/pkr1 skype: thomaskrichel
They have a server farm, and they are obsessed about security... 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, 5 Jan 2011, Thomas Krichel wrote:
Christian Zimmermann writes
What is eating so much space in so little time? logs?
In any case, once I am in St Louis, the first priority will be to move the two machines so that we have better sysadmin support,
I doubt you will get much better than me, look when the exim problem was apparent, I patched nebka with 30 minutes, a box that I know got rootkitted three days later via that exim route...
But I'd be happy to give up this thankless task!
Cheers,
Thomas Krichel http://openlib.org/home/krichel http://authorclaim.org/profile/pkr1 skype: thomaskrichel
Christian Zimmermann writes
They have a server farm, and they are obsessed about security...
I don't think you want to be dealing with that. Cheers, Thomas Krichel http://openlib.org/home/krichel http://authorclaim.org/profile/pkr1 skype: thomaskrichel
participants (2)
-
Christian Zimmermann -
Thomas Krichel