How to undo or stop a Job?

Omeka S
1

Hello there,
My recent CSV imports do not work, the associated jobs are marked as “Starting” and nothing is listed under “Past imports” but I think they are blocked by the Batch Delete (Job 1). The Batch Delete was unsuccessful because I had mistakenly made a change in AbstractEntityAdapter.php (my bad), but is there a way now to undo or stop this job, other than re-installing the whole Omeka?

This actually reminds me very much of the problem detailed here for Omeka 2, is the procedure to follow the same?

Or is there a way to undo imports as was detailed here for Omeka 2? CSV Import - Omeka Classic User Manual

Thank you in advance!

2

I have a few job which have been exited without returning. Their status is still “In Progress”, but I can start new jobs.

When you click on a Job Id, you get the job page and there, in the top-right corner there is an “Attempt Stop” button. You can press it but I am pretty sure that it will just turn the status on “Stopping”, nothing else.

The only case getting “Starting” status I have met, this have been with a server configuration issue. Is the package PHP-CLI correctly installed on your server? Do you run PHP in safe mode?

3

Thank you for your quick answer!
The button “Attempt stop” unfortunately does not appear for my processes in status “Starting”. I will clarify the other questions with my server.

4

I tried to delete the tables of the website and build it anew but I get the same status “Starting” for my jobs (CSV imports).

Pardon my ignorance but searching for Safe mode for PHP, one finds it has been DEPRECATED as of PHP 5.3.0 and REMOVED as of PHP 5.4.0.
Also it seems that PHP-CLI is not correctly installed on the server, we are looking at this possibility.

Why it is important? Can you explain a bit what is behind this?

5

The php cli is used to process all background jobs, so you can’t csv-import anything without it. Normally, it is autodetected by Omeka/Omeka S, but if it fails, you have to set it in the config of Omeka.

6

Omeka uses exec() PHP function to find PHP-CLI path. Then it uses exec() to execute PHP-CLI with the job as parameter.

I have asked here if an alternative to PHP-CLI was possible, but I have not received any answer, so I suppose there is no one.

7

The php cli (command line interface for php) can be same than the program (php) used by the web server (apache or nginx). You just have to set its path in the config.You can install multiple php on the same machine, but it is not required.

8

CLI and CGI are different SAPI.

Are you sure that scripts launched by Omeka-S are runnable by the CGI SAPI?

9

Of course they are different, but the configuration of the servers are very numerous and various, so just try it!

10

I think it can’t work because /application/data/scripts/perform-job.php calls getopt().

But maybe @hajoki can try?

In a shell, check that SAPI which is written after version number is CGI when typing

php -v

Then, get PHP path with this command:

which php

Finally, configure /config/local.config.php

[
...
    'cli' => [
        'phpcli_path' => '/path/to/php',
...
11

Thank you for your explanations, we configured /config/local.config.php with the help of the server, and I think we are close now but with the command php -v, I get:

PHP 7.0.20 (cli) (built: Jun 30 2017 23:25:14) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies

But with phpinfo() in the Omeka project I get

PHP Version 7.0.20
Server API 	CGI/FastCGI

And in System Information in Omeka I get

PHP
Version 	7.0.20
SAPI 	cgi-fcgi

How to switch from cgi to cli? Shall I make a complete new installation of Omeka S?

12

Omeka-S require to send data using HTTP. So it is executed with a CGI SAPI, you can’t use CLI because CLI don’t communicate with Apache. So it is normal to see “CGI” with phpinfo(). :wink:

Since php command launch CLI, it means that PHP-CLI is installed on your system, you don’t need anything else. If you have set php path (obtained with which php) in local.config.php, it should work.

If jobs still do not work, I don’t know where is the issue. Probably a security configuration. You should try to write a simple PHP script using exec() function.

13

Thank you all for your help and clarification! My jobs with “Starting” status stay as they are but new jobs get complete like a charm now.
For records, in my case what fixed the problem was my server:

  • changing the PHP version from 5.6 to 7 for the website
  • adding the place of the correct PHP version to the PATH variable of my account
  • configuring /config/local.config.php with the correct path to PHP.
14

Thanks for the help. Setting the php_cgi path fixed part of my problem. When the error went away I was stuck with the Starting job status with nothing more. Running from command line caused a Fatal error with LDAP. A bit more about that here.

15

I take the liberty to hijacked this thread because the title refers exactly to an issue I have. I could open another thread if needed but I believe it is more useful for the future searches this way.

I have a solr indexing job which failed. Solr core was restarting during the indexing I guess. This job was in statut “en cours” in Omeka S job management page. I stopped it and it is now in status
“Arrêt en cours”.

Since this, each time I launch a solr indexing process, even when I force the job, I have the following message:

2019-03-14T07:37:04+00:00 INFO (6): Search index #1 ("solr"): start of indexing
2019-03-14T07:37:04+00:00 ERR (3): Search index #1 ("solr"): end of indexing: there are already 1 other jobs "Search Index" and the current one is not forced.

How can I definitively get rid of this stucked job which blocks future jobs?