[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[EP-tech] Re: Unable to upload files to repository



Hi John,


Thanks for the info on the POST response. At least that rules out one possibility!


As best I can tell, there are no overridden plugins in the repository. Contents of the plugins.pl file below:


# Generic Plugin Options

# To disable the plugin "Export::BibTeX":
# $c->{plugins}->{"Export::BibTeX"}->{params}->{disable} = 1;

# To enable the plugin "Export::LocalThing":
# $c->{plugins}->{"Export::LocalThing"}->{params}->{disable} = 0;

# Screen Plugin Configuration
# (Disabling a screen will also remove it and it's actions from all lists)

# To add the screen Screen::Items to the key_tools list at postion 200:
# $c->{plugins}->{"Screen::Items"}->{appears}->{key_tools} = 200;

# To remove the screen Screen::Items from the key_tools list:
# $c->{plugins}->{"Screen::Items"}->{appears}->{key_tools} = undef;


# Screen Actions Configuration

# To disable action "blah" of Screen::Items
# (Disabling an action will also remove it from all lists)
# $c->{plugins}->{"Screen::Items"}->{actions}->{blah}->{disable} = 1;

# To add action "blah" of Screen::Items to the key_tools list at postion 200:
# $c->{plugins}->{"Screen::Items"}->{actions}->{blah}->{appears}->{key_tools} = 200;

# To remove action "blah" of Screen::Items from the key_tools list
# $c->{plugins}->{"Screen::Items"}->{actions}->{blah}->{appears}->{key_tools} = undef;


# Import/export plugins

# to make a plugin only available to staff
# $c->{plugins}->{"Export::Text"}->{params}->{visible} = "staff";

# to only command line tools
# $c->{plugins}->{"Export::Text"}->{params}->{visible} = "api";

# to prevent a import/export plugin from being shown as an option, but
# not actually disable it.
# $c->{plugins}->{"Export::BibTeX"}->{params}->{advertise} = 0;


# Plugin Mapping

# The following would make the repository use the LocalDC export plugin
# anytime anything asks for the DC plugin - this is a handy way to override
# the behaviour without hacking the existing plugin.
# $c->{plugin_alias_map}->{"Export::DC"} = "Export::LocalDC";
# This line just means that the LocalDC plugin doesn't appear in addition
# as that would be confusing.
# $c->{plugin_alias_map}->{"Export::LocalDC"} = undef;

# CrossRef registration

# You should replace this with your own CrossRef account username and password.

$c->{plugins}->{"Import::DOI"}->{params}->{pid} = "ourl_eprintsorg:eprintsorg";


There is nothing at all in ~/archives/ARCHIVEID/cfg/plugins/EPrints/..., (the folder plugins doesn't even exist).


I'm not 100% certain I have the right 'files' workflow stage but, assuming you mean the section in the ~/archives/ARCHIVEID/cfg/workflows/eprint/default.xml file, there were a couple of minor differences between ours and the current version. Changing this to reflect the newer version, followed by a reload of the repository config and an Apache restart, has made no difference to the behaviour we're encountering. Perhaps you meant another file, and I've misunderstood?


I'll try to include another Apache error log entry below, in the hopes that the formatting is preserved better.


Many thanks,


James



Apache error log:


[Thu Apr 24 14:52:39 2014] [error] [client 74.112.131.245] Software caused connection abort at /usr/share/eprints/perl_lib/EPrints/Page.pm line 78.\n
document.4653 failed to create subdataobj on document.files at /usr/share/eprints/perl_lib/EPrints/DataObj.pm line 313
    EPrints::DataObj::create_from_data('EPrints::DataObj::Document', 'EPrints::Repository=HASH(0x7fd1572dcf68)', 'HASH(0x7fd157c4f6f8)', 'EPrints::DataSet=HASH(0x7fd1577dcf80)') called at /usr/share/eprints/perl_lib/EPrints/DataObj/SubObject.pm line 78
    EPrints::DataObj::SubObject::create_from_data('EPrints::DataObj::Document', 'EPrints::Repository=HASH(0x7fd1572dcf68)', 'HASH(0x7fd157c4f6f8)', 'EPrints::DataSet=HASH(0x7fd1577dcf80)') called at /usr/share/eprints/perl_lib/EPrints/DataObj/Document.pm line 313
    EPrints::DataObj::Document::create_from_data('EPrints::DataObj::Document', 'EPrints::Repository=HASH(0x7fd1572dcf68)', 'HASH(0x7fd157c4f6f8)', 'EPrints::DataSet=HASH(0x7fd1577dcf80)') called at /usr/share/eprints/perl_lib/EPrints/DataSet.pm line 1012
    EPrints::DataSet::create_dataobj('EPrints::DataSet=HASH(0x7fd1577dcf80)', 'HASH(0x7fd157c4f6f8)') called at /usr/share/eprints/perl_lib/EPrints/DataObj.pm line 395
    EPrints::DataObj::create_subdataobj('EPrints::DataObj::EPrint=HASH(0x7fd157cfa530)', 'documents', 'HASH(0x7fd157c4f6f8)') called at /usr/share/eprints/perl_lib/EPrints/Plugin/Screen/EPrint/UploadMethod/File.pm line 109
    EPrints::Plugin::Screen::EPrint::UploadMethod::File::action_add_format('EPrints::Plugin::Screen::EPrint::UploadMethod::File=HASH(0x7f...') called at /usr/share/eprints/perl_lib/EPrints/Plugin/Screen.pm line 240
    EPrints::Plugin::Screen::from('EPrints::Plugin::Screen::EPrint::UploadMethod::File=HASH(0x7f...') called at /usr/share/eprints/perl_lib/EPrints/Plugin/InputForm/Component/Upload.pm line 84
    EPrints::Plugin::InputForm::Component::Upload::update_from_form('EPrints::Plugin::InputForm::Component::Upload=HASH(0x7fd1561e...', 'EPrints::ScreenProcessor=HASH(0x7fd157c57e68)') called at /usr/share/eprints/perl_lib/EPrints/Plugin/Screen/EPrint/Edit.pm line 74
    EPrints::Plugin::Screen::EPrint::Edit::from('EPrints::Plugin::Screen::EPrint::Edit=HASH(0x7fd157c55620)') called at /usr/share/eprints/perl_lib/EPrints/ScreenProcessor.pm line 310
    EPrints::ScreenProcessor::process('EPrints::ScreenProcessor', 'session', 'EPrints::Repository=HASH(0x7fd1572dcf68)', 'template', undef, 'url', '/cgi/users/home') called at /usr/share/eprints/cgi/users/home line 25
    ModPerl::ROOT::ModPerl::Registry::usr_share_eprints_cgi_users_home::handler('Apache2::RequestRec=SCALAR(0x7fd1533a36e8)') called at /usr/lib64/perl5/vendor_perl/ModPerl/RegistryCooker.pm line 204
    eval {...} called at /usr/lib64/perl5/vendor_perl/ModPerl/RegistryCooker.pm line 204
    ModPerl::RegistryCooker::run('ModPerl::Registry=HASH(0x7fd156a53b30)') called at /usr/lib64/perl5/vendor_perl/ModPerl/RegistryCooker.pm line 170
    ModPerl::RegistryCooker::default_handler('ModPerl::Registry=HASH(0x7fd156a53b30)') called at /usr/lib64/perl5/vendor_perl/ModPerl/Registry.pm line 31
    ModPerl::Registry::handler('ModPerl::Registry', 'Apache2::RequestRec=SCALAR(0x7fd1533a36e8)') called at -e line 0
    eval {...} called at -e line 0



________________________________
From: eprints-tech-bounces at ecs.soton.ac.uk <eprints-tech-bounces at ecs.soton.ac.uk> on behalf of John Salter <J.Salter at leeds.ac.uk>
Sent: 24 April 2014 12:21
To: 'eprints-tech at ecs.soton.ac.uk'
Subject: [EP-tech] Re: Unable to upload files to repository

The ?Cancel? response to the initial POST is correct ? it would display a button to cancel the upload ? if it was on screen long enough!

If you copy the errors from the log into a text editor that doesn?t wrap the lines, it?s a bit clearer (although not necessarily easier to understand).
I can?t immediately see what the problem is.

Do you have any overridden plugins in the repository (anything in ~/archives/ARCHIVEID/cfg/cfg.d/plugins.pl)?
Anything in ~/archives/ARCHIVEID/cfg/plugins/EPrints/??

Did you update the ?files? workflow stage when you upgraded?

Cheers,
John

From: eprints-tech-bounces at ecs.soton.ac.uk [mailto:eprints-tech-bounces at ecs.soton.ac.uk] On Behalf Of Caldow, James
Sent: 24 April 2014 11:38
To: 'eprints-tech at ecs.soton.ac.uk'
Subject: [EP-tech] Re: Unable to upload files to repository


Hi John,



The progressid does exist in the upload_progress table, as below:



+----------------------------------+------------+---------+----------+
| progressid                       | expires    | size    | received |
+----------------------------------+------------+---------+----------+
| C58D8FC386EF49888DF11674E4E1E6AF | 1398934939 | 7378540 |  7378540 |
+----------------------------------+------------+---------+----------+



Permissions on the server are drwxrwsr-x for all folders in the archive and the owner is eprints:eprints. Apache is running as eprints:eprints too, so all should be in order there. SELinux permissions were set as per the wiki:



chcon -R -h -t httpd_sys_script_rw_t /usr/share/eprints/archives/eresearch/documents/



Firebug does have a POST entry, but the only information there is:



{"lib/submissionform:action_cancel":"Cancel"}





which does seem a bit odd, though I'd be hard pressed to understand why.



Tried the upload in Firefox, IE and Chrome with no difference in behaviour.



The only errors in the Apache logs are along the same lines as the one I posted in my original email. They all follow the same format, and are generated every time I try to upload a document.



I feel I might make some progress if I could actually understand what the error logs were telling me, but my lack of knowledge in that area is really letting me down on this one.





James

________________________________
From: eprints-tech-bounces at ecs.soton.ac.uk<mailto:eprints-tech-bounces at ecs.soton.ac.uk> <eprints-tech-bounces at ecs.soton.ac.uk<mailto:eprints-tech-bounces at ecs.soton.ac.uk>> on behalf of John Salter <J.Salter at leeds.ac.uk<mailto:J.Salter at leeds.ac.uk>>
Sent: 24 April 2014 11:01
To: 'eprints-tech at ecs.soton.ac.uk'
Subject: [EP-tech] Re: Unable to upload files to repository

Does that progressid exist in the upload_progress table?
I?m guessing it does ? so it seems like there?s something else at play here.

Have you double-double checked the permissions?
Is Apache running as the user you expect it to?

Does it work in a different browser?

In Firebug, look at the Console from the point that you get to the upload page.
When you select a file, there should also be an Ajax POST ? does this have any clues?

Normally there will be some trail through the error logs somewhere if something is failing like this?

Cheers,
John

From: eprints-tech-bounces at ecs.soton.ac.uk<mailto:eprints-tech-bounces at ecs.soton.ac.uk> [mailto:eprints-tech-bounces at ecs.soton.ac.uk] On Behalf Of Caldow, James
Sent: 24 April 2014 10:45
To: 'eprints-tech at ecs.soton.ac.uk'
Subject: [EP-tech] Re: Unable to upload files to repository


Hi John,



Many thanks for the pointers.



We upgraded from 3.1.3, which seemed to work fine. The database upgrades took some time to work through the various versions in between.



I've checked the database structure and we do have an "upload_progress" table and an "upload_progress__ordervalues_en" table. Hopefully that means all is well with the database?



I've checked Firebug when trying to upload a file, and the result of the GET is:



{

      "progressid": "C58D8FC386EF49888DF11674E4E1E6AF",

      "received": 4039,

      "uri": "http:\/\/eresearch.qmu.ac.uk\/id\/upload_progress\/C58D8FC386EF49888DF11674E4E1E6AF",

      "size": 7378540,

      "expires": 1398934939

    }

I'm still trying to track this one down but I am starting to feel pretty hopeless, (having been at it for weeks now!).

Any and all suggestions gratefully received at this point.


James



________________________________
From: eprints-tech-bounces at ecs.soton.ac.uk<mailto:eprints-tech-bounces at ecs.soton.ac.uk> <eprints-tech-bounces at ecs.soton.ac.uk<mailto:eprints-tech-bounces at ecs.soton.ac.uk>> on behalf of John Salter <J.Salter at leeds.ac.uk<mailto:J.Salter at leeds.ac.uk>>
Sent: 24 April 2014 09:44
To: 'eprints-tech at ecs.soton.ac.uk'
Subject: [EP-tech] Re: Unable to upload files to repository

James,
What have you upgraded from?
It might be worth checking you have an ?upload_progress? table in the db.
If you?ve got firebug (or a similar tool), use it to inspect the Ajax calls/response ? they might also give you a clue.

Cheers,
John

From: eprints-tech-bounces at ecs.soton.ac.uk<mailto:eprints-tech-bounces at ecs.soton.ac.uk> [mailto:eprints-tech-bounces at ecs.soton.ac.uk] On Behalf Of Caldow, James
Sent: 23 April 2014 16:28
To: eprints-tech at ecs.soton.ac.uk<mailto:eprints-tech at ecs.soton.ac.uk>
Subject: [EP-tech] Unable to upload files to repository


We have recently migrated our repository to a new server, combined with an upgrade to 3.3.12.



Most things appear to be working, (though there is a list of issues that remain unsolved).



The most pressing issue is that file uploads seem not to be working since the move/upgrade. From the "Upload" section of the edit item workflow, clicking on "Browse" from the "File" section of "Add a new document" brings up the correct browse window. Clicking on a file, followed by "Open" produces a very brief flash of a progress bar, followed by nothing at all.



Checking the Apache error log shows the following, (which I am unable to debug):



document.4640 failed to create subdataobj on document.files at /usr/share/eprints/perl_lib/EPrints/DataObj.pm line 313
    EPrints::DataObj::create_from_data('EPrints::DataObj::Document', 'EPrints::Repository=HASH(0x7f625f2fce98)', 'HASH(0x7f625f2d40d0)', 'EPrints::DataSet=HASH(0x7f625fb88700)') called at /usr/share/eprints/perl_lib/EPrints/DataObj/SubObject.pm line 78
    EPrints::DataObj::SubObject::create_from_data('EPrints::DataObj::Document', 'EPrints::Repository=HASH(0x7f625f2fce98)', 'HASH(0x7f625f2d40d0)', 'EPrints::DataSet=HASH(0x7f625fb88700)') called at /usr/share/eprints/perl_lib/EPrints/DataObj/Document.pm line 313
    EPrints::DataObj::Document::create_from_data('EPrints::DataObj::Document', 'EPrints::Repository=HASH(0x7f625f2fce98)', 'HASH(0x7f625f2d40d0)', 'EPrints::DataSet=HASH(0x7f625fb88700)') called at /usr/share/eprints/perl_lib/EPrints/DataSet.pm line 1012
    EPrints::DataSet::create_dataobj('EPrints::DataSet=HASH(0x7f625fb88700)', 'HASH(0x7f625f2d40d0)') called at /usr/share/eprints/perl_lib/EPrints/DataObj.pm line 395
    EPrints::DataObj::create_subdataobj('EPrints::DataObj::EPrint=HASH(0x7f625ff9f1d8)', 'documents', 'HASH(0x7f625f2d40d0)') called at /usr/share/eprints/perl_lib/EPrints/Plugin/Screen/EPrint/UploadMethod/File.pm line 109
    EPrints::Plugin::Screen::EPrint::UploadMethod::File::action_add_format('EPrints::Plugin::Screen::EPrint::UploadMethod::File=HASH(0x7f...') called at /usr/share/eprints/perl_lib/EPrints/Plugin/Screen.pm line 240
    EPrints::Plugin::Screen::from('EPrints::Plugin::Screen::EPrint::UploadMethod::File=HASH(0x7f...') called at /usr/share/eprints/perl_lib/EPrints/Plugin/InputForm/Component/Upload.pm line 84
    EPrints::Plugin::InputForm::Component::Upload::update_from_form('EPrints::Plugin::InputForm::Component::Upload=HASH(0x7f62600d...', 'EPrints::ScreenProcessor=HASH(0x7f62600a2bc0)') called at /usr/share/eprints/perl_lib/EPrints/Plugin/Screen/EPrint/Edit.pm line 74
    EPrints::Plugin::Screen::EPrint::Edit::from('EPrints::Plugin::Screen::EPrint::Edit=HASH(0x7f62600e7d70)') called at /usr/share/eprints/perl_lib/EPrints/ScreenProcessor.pm line 310
    EPrints::ScreenProcessor::process('EPrints::ScreenProcessor', 'session', 'EPrints::Repository=HASH(0x7f625f2fce98)', 'template', undef, 'url', '/cgi/users/home') called at /usr/share/eprints/cgi/users/home line 25
    ModPerl::ROOT::ModPerl::Registry::usr_share_eprints_cgi_users_home::handler('Apache2::RequestRec=SCALAR(0x7f625efeedb0)') called at /usr/lib64/perl5/vendor_perl/ModPerl/RegistryCooker.pm line 204
    eval {...} called at /usr/lib64/perl5/vendor_perl/ModPerl/RegistryCooker.pm line 204
    ModPerl::RegistryCooker::run('ModPerl::Registry=HASH(0x7f626009f818)') called at /usr/lib64/perl5/vendor_perl/ModPerl/RegistryCooker.pm line 170
    ModPerl::RegistryCooker::default_handler('ModPerl::Registry=HASH(0x7f626009f818)') called at /usr/lib64/perl5/vendor_perl/ModPerl/Registry.pm line 31
    ModPerl::Registry::handler('ModPerl::Registry', 'Apache2::RequestRec=SCALAR(0x7f625efeedb0)') called at -e line 0
    eval {...} called at -e line 0



I have checked for file permissions, SELinux permissions, etc. Everything seems to be correct, but file uploads still will not work.



Adding a new document from a URL does work, which I think would point to the problem not being permissions based, (though I could be completely wrong).



Does anyone have any pointers as to where I should be looking?



Many thanks,



James
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/eprints-tech/attachments/20140424/5905e5c0/attachment-0001.html