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

Index updates via scheduler fail (wrong PHP version) #112

Open
kees-closed opened this issue Jan 6, 2021 · 11 comments
Open

Index updates via scheduler fail (wrong PHP version) #112

kees-closed opened this issue Jan 6, 2021 · 11 comments

Comments

@kees-closed
Copy link

Hi,

Thanks for the amazing work on Grav! It really empowers my website design and experience. I ran into a problem with the TNT Search scheduler. I'm running Grav on Plesk. Which so far works excellent. In Plesk I can select different versions of software for each website, such as PHP 7.4 by selecting it in the menu for my Grav website. This then points it to /opt/plesk/php/7.4/. This path is respected by Grav. Except for scheduling TNT Search re-indexes.

I'm using Grav v1.6.31 and TNT Search v3.3.0.

Manual indexes work fine. Other schedulers work fine too (mail queue, auto cache purges, auto backup, etc.). But the scheduled re-index fails because it seems to use the system installed PHP version, which is PHP 5.4.6.

I've taken a look, but at first glance I don't see much difference with other scheduled plugins.

==> logs/tntsearch-index.out <==
Composer detected issues in your platform:

Your Composer dependencies require a PHP version ">= 7.1.3". You are running 5.4.16.

PHP Fatal error:  Composer detected issues in your platform: Your Composer dependencies require a PHP version ">= 7.1.3". You are running 5.4.16. in /var/www/vhosts/website.net/vendor/composer/platform_check.php on line 25

When I run it via the CLI with the right PHP version, it works fine:

$ /opt/plesk/php/7.4/bin/php bin/plugin tntsearch index

Re-indexing

Added   1 /
Skipped 2 /de-zeitgeistbeweging - redirect only...
Added   3 /de-zeitgeistbeweging/over-tzm
Added   4 /de-zeitgeistbeweging/raak-betrokken
Added   5 /de-zeitgeistbeweging/blog
Added   6 /de-zeitgeistbeweging/blog/20201216-chapter-report
Added   7 /de-zeitgeistbeweging/blog/20210105-chapter-meeting
Added   8 /de-zeitgeistbeweging/blog/co-initiative-method
Added   9 /de-zeitgeistbeweging/blog/nieuwe-website
Added   10 /de-zeitgeistbeweging/blog/tzm-nl-reboot
Added   11 /de-zeitgeistbeweging/blog/zday-2010
Added   12 /de-zeitgeistbeweging/blog/zday-2014
Added   13 /de-zeitgeistbeweging/blog/zday-2016
Added   14 /de-zeitgeistbeweging/blog/zday-2017
Added   15 /de-zeitgeistbeweging/faq
Skipped 16 /teams - redirect only...
Added   17 /teams/educatie-team
Added   18 /teams/media-team
Added   19 /teams/it-team
Added   20 /teams/it-team/boinc
Added   21 /teams/hydroponics-team
Added   22 /teams/vertaal-team
Added   23 /teams/vertaal-team/videos-dotsub
Added   24 /teams/vertaal-team/teksten-poodle-google-docs
Skipped 25 /events - redirect only...
Added   26 /events/chapter-meetings
Added   27 /events/orientatie-meetings
Added   28 /events/zday
Skipped 29 /media - redirect only...
Added   30 /media/videos
Added   31 /media/presentaties
Added   32 /media/zeit-talks
Skipped 33 /media/zdays - redirect only...
Added   34 /media/boeken
Added   35 /contact
Added   36 /privacy-verklaring
Total rows 31


Indexed in 0.4s
@toddeTV
Copy link

toddeTV commented Jan 26, 2021

Same here. .bashrc and .bash_profile are set so that php -v brings the PHP version 7.4. But the bin/grav scheduler -r with a following bin/grav scheduler -d shows, that it tries to use PHP version 5.4.
But it seems less a plugin problem but more of a server configuration issue.

@ViliusS
Copy link
Contributor

ViliusS commented Jan 28, 2021

Grav CLI tries to determine correct PHP version automatically. What does "/usr/bin/env php" return?

@kees-closed
Copy link
Author

kees-closed commented Jan 28, 2021

Grav CLI tries to determine correct PHP version automatically. What does "/usr/bin/env php" return?

That seems to be the difference in behavior of this plugin. The other plugins don't depend on this. Maybe it's best to keep things consistent? I now see the error /usr/bin/env: php: No such file or directory in the scheduler overview. This wasn't the case before. I guess Grav 1.7 changed this? Because the error used to be as I described it in the first post.

I asked the admin of the system to install coreutils, because env is missing. Hopefully that fixes it. But I personally think it would be best to stick to a certain standard that doesn't require extra system packages. And since the other plugins run fine in the scheduler, there seems to be better ways to do this.

I'll report back once I know more.

@ViliusS
Copy link
Contributor

ViliusS commented Jan 28, 2021

It's just coincidence because this plugin specifically uses Grav CLI, nothing wrong with that. Other plugins probably execute direct Grav APIs.

If /usr/bin/env fails then you should see failing main "bin/grav" too.

As to why it worked before for you, plugin was fixed to run again couple of months ago, because it was completely broken in 1.6 and 1.7 and you probably never saw that in the GUI.

@kees-closed
Copy link
Author

kees-closed commented Jan 28, 2021

I specifically provide the PHP version for /bin/grav, otherwise an error indeed returns about a wrong PHP version. Now it indeed also returns the env error. So this has become more clear with Grav 1.7. Hopefully env will be able to point to the PHP version set as default by Plesk.

I use this, then it works fine for all plugins, except the tntsearch.
/opt/plesk/php/7.4/bin/php ~/www.zeitgeistbeweging.nl/bin/grav scheduler -d

Let's see if the coreutils package fixes everything :)

@kees-closed
Copy link
Author

kees-closed commented Jan 28, 2021

It's just coincidence because this plugin specifically uses Grav CLI, nothing wrong with that. Other plugins probably execute direct Grav APIs.

If /usr/bin/env fails then you should see failing main "bin/grav" too.

As to why it worked before for you, plugin was fixed to run again couple of months ago, because it was completely broken in 1.6 and 1.7 and you probably never saw that in the GUI.

On a Plesk system this is not convenient. I just talked to the admin. He removed the /usr/bin/php binary because Plesk uses /opt/plesk/php/7.4/bin/php. With Plesk you can select a different PHP version per vhost. So I can also on the fly switch to PHP 8. This is then picked up by Grav without issues. This also works fine for all plugins, but tntsearch does not work in such a setup when using the scheduler. When running the tntsearch index from the GUI, it works fine.

Would it be possible to use the Grav APIs? Because a good fix is not possible. If a symlink was created for /usr/bin/php to /opt/plesk/php/7.4/bin/php, then that has to be manually maintained. It also should be a sensible default for all the other users on the system. Plesk doesn't work like that.

@ViliusS
Copy link
Contributor

ViliusS commented Jan 28, 2021

It's just coincidence because this plugin specifically uses Grav CLI, nothing wrong with that. Other plugins probably execute direct Grav APIs.
If /usr/bin/env fails then you should see failing main "bin/grav" too.
As to why it worked before for you, plugin was fixed to run again couple of months ago, because it was completely broken in 1.6 and 1.7 and you probably never saw that in the GUI.

On a Plesk system this is not convenient. I just talked to the admin. He removed the /usr/bin/php binary because Plesk uses /opt/plesk/php/7.4/bin/php. With Plesk you can select a different PHP version per vhost. So I can also on the fly switch to PHP 8.

This is EXACTLY what env was designed for and why it should be used. You don't need to create a symlink to the correct PHP version, env should find it according to your PATH environment. As far as I remember Plesk uses different users for different vhosts. If env cannot find correct PHP version then your PATH for that particular user is misconfigured.

I'm running Grav with TNTSearch under Virtualmin with similar setup. It works correctly.

This is then picked up by Grav without issues. This also works fine for all plugins, but tntsearch does not work in such a setup when using the scheduler. When running the tntsearch index from the GUI, it works fine.

Would it be possible to use the Grav APIs? Because a good fix is not possible. If a symlink was created for /usr/bin/php to /opt/plesk/php/7.4/bin/php, then that has to be manually maintained. It also should be a sensible default for all the other users on the system. Plesk doesn't work like that.

There is no point of changing how plugin works because as I said, other plugins and Grav itself uses the same CLI functionality. If you think Grav is not compatible with Plesk you should rise the ticket on main Grav repository, but again, your issue should be easy fixable by an admin.

@kees-closed
Copy link
Author

The only plugin that has issues is tntsearch. Everything else works fine. So the issue I'm having is not really with Plex. Because Grav works fine. It's only tntsearch that runs into this problem. So I'll repeat my kind and respectful request to make use of the Grav API instead of what is used now. In my opinion that would be the most easy and productive way forward. But I'll leave that up to you. I hope you change your mind.

@ViliusS
Copy link
Contributor

ViliusS commented Jan 28, 2021

I'm not the plugin author, so it's not up to me. I just wanted to help.

All I can do is just repeat myself, that if you see this issue, there will be other issues, like for example "bin/grav backup" failing. Every code which depends on the Grav CLI and is executed automatically WILL fail.

The issue is in the environment, and should be fixed there.

@kees-closed
Copy link
Author

kees-closed commented Jan 29, 2021

Backups work fine as well via the scheduler. It's only tntsearch that causes this issue.

$ /opt/plesk/php/7.4/bin/php ~/www.zeitgeistbeweging.nl/bin/grav scheduler -d

Job Details
===========

┌─────────────────────┬──────────────────┬──────────────────┬───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Job ID              │ Last Run         │ Next Run         │ Errors                                                                                                                                                        │
├─────────────────────┼──────────────────┼──────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│ tntsearch-index     │ 2021-01-29 05:01 │ 2021-01-30 05:01 │ /usr/bin/env: php: No such file or directory                                                                                                                  │
│ email-flushqueue    │ 2021-01-29 06:37 │ 2021-01-29 06:38 │ None                                                                                                                                                          │
│ git-sync            │ 2021-01-28 23:00 │ 2021-01-29 12:00 │ None                                                                                                                                                          │
│ default-site-backup │ 2021-01-29 01:00 │ 2021-01-30 01:00 │ None                                                                                                                                                          │
│ cache-clear         │ 2021-01-29 03:00 │ 2021-01-30 03:00 │ None                                                                                                                                                          │
└─────────────────────┴──────────────────┴──────────────────┴───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘

@kees-closed
Copy link
Author

Will someone please have a look at this? On a Plesk instance this is broken, only for the TNT Search plugin.

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

No branches or pull requests

3 participants