CSV Import Jobs never starts


I would appreciate your help finding a solution for an CVS Import issue I am having.

Every time I try to import a cvs file into Omeka S using CSV Import Module, the job starts, but its status keeps saying “Starting”, and never change that state, without actually importing anything. The csv file works perfectly on another instance of Omeka Classic.

This is the first time I use this module in this Omeka S instance. Other modules seems to work fine.

I am using Omeka S version 1.0.0, and CSV Import version 1.1.0. In case it is relevant, my PHP version is 7.0.10 and MySQL is 5.5.47-MariaDB.

Best regards,

I am having the same issue. I worked with my registrar to check all the settings and they all look to be what is needed. There is no error log at all. Just looks like it is hung up somewhere.

Mcfarms, thank you for remind me of that! Yes, I have that same issue. When I select the csv file, in the beginning of the importing procedure, it allows me to view the fields in the csv, and everything looks promising. But then nothing happens.

1 Like

First thing will likely be to double check that the logging is as informative as possible.

In the .htaccess file, make sure the application environment is set to “development”:

SetEnv APPLICATION_ENV "development"

And, in config/local.config.php make sure the logger info looks like this:

    'logger' => [
        'log' => true,
        'priority' => \Zend\Log\Logger::INFO,

Then try running it again, and look for information in the job’s log via the admin interface. Hopefully more info will be there.

It still does the same thing. This is what the job page shows:




November 27, 2017 at 3:41:16 PM EST


[not ended]






“csvpath”: “/tmp/omeka6X18Om”,
“resource_type”: “items”,
“csrf”: “2576724df6effb4becf191a88be7bd68-189450954339ca637e6341635d804a16”,
“comment”: “”,
“o:resource_template”: {
“o:id”: “”
“o:resource_class”: {
“o:id”: “”
“o:owner”: “1”,
“multivalue-separator”: “,”,
“global-language”: “”,
“column-property”: [


[no log]

There is also no option to terminate the job.

Many thanks, @mcfarms. That helps, though I don’t yet have a good idea about where things might be breaking. It’s quite early in the process, but I’m not sure yet what might be happening. We’ll keep exploring.

@athanor There’s no certainty that the problem you’re having is the same, so trying the same steps I described above might still be worth the effort.

My best guess right now is that there’s some kind of MySQL error. If you could talk to your sysadmin/hosting provider about looking into the PHP or Apache or SQL logs for errors, that might help.

I worked with them this afternoon and they told me everything was working properly on their end.

@patrickmj, thank you so much for the reply! I already altered the files you have mentioned, but unfortunately I’m still having the same issue as @mcfarms. Tomorow (in Portugal it is quite late…) I will check with the systems admin to look for errors.

Meanwhile, thank you! :slight_smile:

Unfortunately, today I’ve tried to make the cvs import to work, but it all keeps the same, even in a new Omeka S instance. Thank you so much for you effort in helping. In the meantime, if someone has any clue for it not work, please post.

Best regards,

In general, when a job hangs at “Starting” it means that it failed to start, more or less immediately, before it was able to update its status. Getting logging or anything out of this kind of failure is tough, since it’s usually failing so early that none of our logging is set up. A common type of problem is having the wrong PHP-CLI path (Omeka S will try to guess it for you, but if there are multiple php binaries or the correct one isn’t called php, then we can’t guess correctly).

You can try to run the job manually on the command line to see if you get some more useful output. All you need is the Job ID from the leftmost column of the Jobs page. Running from the root of your S install:

php application/data/scripts/perform-job.php --job-id [insert job ID here] --base-path /

I think as jflatnes it is a CLI configuration/installation issue.
Look at « How to undo or stop a Job? » to find a way to solve this issue.

Check if LDAP is installed.