Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tntsearch-index scheduler failure #81

Open
ragoon82 opened this issue Jan 28, 2020 · 20 comments
Open

tntsearch-index scheduler failure #81

ragoon82 opened this issue Jan 28, 2020 · 20 comments
Labels

Comments

@ragoon82
Copy link

Hi,
I am trying run tnsearch plugin via scheduler job but receive an error.
Error description not showing and job status is failure.
Manually tnsearch plugin is working correct.
How can I solve this problem?

This is scheduler run from console:

# bin/grav scheduler -vv
Running Scheduled Jobs
======================
[2020-01-28T14:58:00+00:00] Error:   Grav\Plugin\TNTSearchPlugin::indexJob →
@rhukster
Copy link
Member

have you tried running it manually with:

bin/plugin tntsearch index

@ragoon82
Copy link
Author

Yes, It's working

# bin/plugin tntsearch index
Re-indexing

Language: lt

@rhukster
Copy link
Member

If you are running on Grav 1.7RC there's an unreleased fix in the develop branch. If you are running PHP 7.4, there might still be some issues.

@ragoon82
Copy link
Author

I am running on Grav 1.6.14,
PHP Version 7.3.8

But found problem
image

And can't solve this.

@rhukster
Copy link
Member

This is a classic case where your webserver is running under another user (perhaps www or public_html), and you have to setup the crontab entry for that user.. Not your user are logging in to the terminal with.

@ragoon82
Copy link
Author

So, I solved one problem - crontab Installed and ready, but job status is failure:

image

Something else?

@torohill
Copy link

I came across this problem as well. It looks like it is because $grav['pages']->init() is never called when running the scheduler job, so there is no data to index. When using bin/plugin tntsearch index the pages get initialised through the $this->initializePages() call in IndexerCommand::serve().

I'm not sure if the Grav core should be initialising pages when the scheduler is run, or whether it should be done in the plugin. And I don't know enough about how Grav works to know what call needs to be made to initialise the pages. It looks like events need to be fired etc, so it's not just a matter of calling $grav['pages']->init().

My temporary solution is to run bin/plugin tntsearch index via it's own cronjob and disable the index scheduled job.

@torohill
Copy link

Actually, after closer review it looks like the issue ragoon82 was having it different than mine. The job status is success for me but no pages were indexed when the scheduler ran. Pages were only indexed when I ran bin/plugin tntsearch index. Perhaps I should file this as a separate issue.

@torohill
Copy link

I went ahead and filed issue #95 for the problem I'm seeing, as I'm pretty sure it's not that same as this issue.

rhukster pushed a commit that referenced this issue Nov 4, 2020
Arguments need to be passed as an array since passing shell commands as a string to the Process component is deprecated since Symfony 4.2. Related Grav fix which is also needed for this patch to work properly: getgrav/grav@1661dc9

This also finally fixes issue #81.
@ViliusS
Copy link
Contributor

ViliusS commented Nov 4, 2020

This should be fixed now.

@Ribero
Copy link

Ribero commented Jan 28, 2021

Grav v1.7.3 - Admin v1.10.2

sorry to resurrect this issue, I'm facing an error with the plugin scheduled re-index 👍

bin/grav scheduler -d
Job Details
===========
┌──────────────────┬──────────────────┬──────────────────┬────────────────────────────────────────────────┐
│ Job ID           │ Last Run         │ Next Run         │ Errors                                         │
├──────────────────┼──────────────────┼──────────────────┼────────────────────────────────────────────────┤
│ tntsearch-index  │ 2021-01-28 07:59 │ 2021-01-28 08:00 │ /usr/bin/env: 'php': No such file or directory │
│ automated-backup │ 2021-01-28 07:58 │ 2021-01-29 02:00 │ None                                           │
│ cache-purge      │ 2021-01-27 04:00 │ 2021-01-29 04:00 │ None                                           │
│ cache-clear      │ 2021-01-27 03:00 │ 2021-01-29 03:00 │ None                                           │
└──────────────────┴──────────────────┴──────────────────┴────────────────────────────────────────────────┘```

error is : /usr/bin/env: 'php': No such file or directory

@ViliusS
Copy link
Contributor

ViliusS commented Jan 28, 2021

@Ribero that is not an issue with TNTSearch plugin. The plugin uses a CLI from Grav so you should first try to find out why "/usr/bin/env php" doesn't return anything in your environment. Keep in mind that scheduled tasks under Grav could be run under different user.

@Ribero
Copy link

Ribero commented Jan 28, 2021

@ViliusS,

Thanks for the input.

I can run the index command in CLI with success :

runuser -u www-data php bin/plugin tntsearch index
Re-indexing
Added   1 /
Added   2 /...
[...]
Added   16 /test
Added   17 /operations/configuration-grav
Added   18 /operations/test
Total rows 18
Indexed in 0.2s

All other task scheduled works correctly
What is this /usr/bin/env ?

@ViliusS
Copy link
Contributor

ViliusS commented Jan 28, 2021

env is a part of coreutils on Linux systems. Grav CLI uses it to detect correct PHP version so you should try "runuser -u www-data bin/plugin tntsearch index"

If you specify PHP binary in this command yourself you do not repeat what Grav does.

@Ribero
Copy link

Ribero commented Jan 28, 2021 via email

@ViliusS
Copy link
Contributor

ViliusS commented Jan 28, 2021

I'm not familiar with Grav's docker image, you should check with them. The image is probably missing coreutils.

@Ribero
Copy link

Ribero commented Jan 28, 2021

Sorry but I don't get it:

  • re-indexing using the command line works but not when scheduled using the standard plugin configuration options
  • /usr/bin/env is obviously present and working on the host:
file /usr/bin/env
/usr/bin/env: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=
deb36ddbfdfb87b97ddfa05d2ad4b17efc6bf850, stripped

So sorry to reiterate but how to enable the plugin scheduler feature ?
Where is defined the configuration used to setup the scheduler ?

I feel it should work flawlessly with a vanilla grav instance. I did not made any fancy customization and that is one of the benefits of the container approach: stable and reproducible.

@ViliusS
Copy link
Contributor

ViliusS commented Jan 28, 2021

Does running scheduler with "runuser -u www-data bin/plugin tntsearch index" work? (notice a difference from your command earlier)

What does "runuser -u www-data /usr/bin/env php -v" return?

@Ribero
Copy link

Ribero commented Jan 29, 2021

I use runuser when I test the command line only because I cannot directly login with www-data user on the linux container (disabled by default).
But the grav scheduler and the contrab are run by the webserver user (www-data) and does not requires using runuser command.

runuser -u www-data bin/plugin tntsearch index from command line run as expected

runuser -u www-data /usr/bin/env php -v 
runuser: invalid option -- 'v'
Try 'runuser --help' for more information.

I think we should not focus on runuser command

@ViliusS
Copy link
Contributor

ViliusS commented Jan 29, 2021

try runuser -u www-data "/usr/bin/env php -v"

If runuser -u www-data bin/plugin tntsearch index works as expected I have no idea why it doesn't work for you because this is exactly how grav sheduler for this plugin is executed. See here

$job = $scheduler->addCommand('bin/plugin', ['tntsearch', 'index'], 'tntsearch-index');

Maybe your crontab is running under different user than www-data without env or php in the path?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants