Unable to run feed update daemon


#1

When I try to start the feed update daemon, i receive the following error message:

Tiny Tiny RSS was unable to start properly. This usually means a misconfiguration or an incomplete upgrade.
Please fix errors indicated by the following messages:

  • PHP function mime_content_type() is missing, try enabling fileinfo module.

This only started occurring after the sanity check was updated to include checking for this module. However, I have checked on my site and the fileinfo module is enabled:

Checked update from git today and I’m up-to-date. Running on Dreamhost VPS, PHP version 7.1.10. Any thoughts would be much appreciated!


#2

There have been sporadic issues here and there when using PHP 7.1, but I’m not sure if this is one of them.

Is the function mime_content_type listed under disabled functions, by chance?

What operating system are you running? I wonder if maybe some dependency didn’t get installed properly when the file info module was installed.


#3

As far as I can tell, there are no disabled functions (checked using the code snippet at https://www.nutt.net/list-functions-disabled-in-php/ and got a “No functions disabled” result). If there’s a better way to check, please let me know.

Same issue occurs when I run the site under PHP 5.6.

OS is Ubuntu 12.04.5 LTS.

Thanks for the response, much appreciated!


#4

Side note: The sanity check and your phpinfo() file are run through the web interface, which usually has a separate config from CLI. So while you need to fix this, make sure you fix it for both. Running php -m (I think) from a terminal will tell you what modules are loaded for the CLI instance.

Also, you don’t need all that crazy code to check for disabled functions. It’s listed in phpinfo() as well.

To be honest, I’m not sure why it wouldn’t be there if the module is installed. Do you actually get an undefined function error if you put just mime_content_type(); in its own PHP file and access it?


#5

that function is technically deprecated, maybe your hosting / distro decided that they might as well build php without it

it sure sounds like something fedora devs would do


#6

modules loaded per command line:

/usr/local/php71/bin/php -m
Cannot load Zend OPcache - it was already loaded
[PHP Modules]
bcmath
bz2
calendar
Core
ctype
curl
date
dom
exif
fileinfo
filter
ftp
gd
gettext
hash
iconv
imagick
imap
json
libxml
mbstring
mcrypt
memcached
mysqli
mysqlnd
openssl
pcntl
pcre
PDO
pdo_mysql
pdo_sqlite
pgsql
posix
pspell
Reflection
session
SimpleXML
soap
sockets
SPL
sqlite3
standard
tokenizer
xml
xmlreader
xmlrpc
xmlwriter
xsl
Zend OPcache
zip
zlib

[Zend Modules]
Zend OPcache

…so it looks like fileinfo is installed. My list of modules is different if I just run php -m from the terminal though:

[PHP Modules]
apc
bcmath
bz2
calendar
Core
ctype
curl
date
dom
ereg
exif
filter
ftp
gd
gettext
hash
iconv
imagick
imap
json
libxml
mbstring
mcrypt
memcached
mhash
mysql
mysqli
mysqlnd
openssl
pcntl
pcre
PDO
pdo_mysql
pdo_sqlite
pgsql
posix
pspell
Reflection
session
SimpleXML
soap
sockets
SPL
sqlite3
standard
tokenizer
xml
xmlreader
xmlrpc
xmlwriter
xsl
zip
zlib

[Zend Modules]

mime_content_type(); in its own file gives the following:

Warning: mime_content_type() expects exactly 1 parameter, 0 given in /path/to/file/mimecheck.php on line 2

Any thoughts? I acknowledge that this might just be a broken install from the VPS hosts but I appreciate the assistance.


#7

How is the command line different than the terminal? They’re different words that describe the same thing. Could you clarify how/where these are different?

So PHP says the function doesn’t exist, but when you run it it’s there and does exist? Did you load that test file from a web browser or the terminal?


#8

Sorry, that wasn’t clear. In the terminal if I run

/usr/local/php71/bin/php -m

I get the first list of modules (including fileinfo). If i run the command

php -m

I get the second list of modules (no fileinfo)

Two commands from the terminal, different results. My normal process when I start the daemon is to use

/usr/local/php71/bin php ./path/to/file/ttrss/update_daemon2.php

… and that had been working for me before the sanity check was updated.

The test file was loaded from a web browser.

In the terminal if I run

php ./path/to/file/ttrss/mimecheck.php

I get:

Fatal error: Call to undefined function mime_content_type() in /path/to/file/ttrss/mimecheck.php on line 2

But if I run

/usr/local/php71/bin/php ./path/to/file/ttrss/mimecheck.php

I get:

Cannot load Zend OPcache - it was already loaded
Warning: mime_content_type() expects exactly 1 parameter, 0 given in /path/to/file/ttrss/mimecheck.php on line 2

Thanks again for following up.


#9

So what’s happening is that you have multiple versions of php installed with different modules for each. Probably somewhere in some config there’s no clear definition of which version to use so the default is used, which does not have the fileinfo module installed.

Your setup is a bit messed, obviously, and this is further confirmed by the fact that it’s loaded the OpCache module more than once under at least one of the configurations.

At this point I, personally, would just remove/purge all PHP installs and set that part up anew. You, however, will have to decide on your own based on your knowledge of this stuff. Worst case, contact DreamHost support and explain the multiple PHP versions thing, I’m sure they could help. This particular issue is beyond the scope of this forum, but you’re welcome to post the end result so others can benefit from it.

e: Also check the path defined in config.php for PHP_EXECUTABLE.


#10

Checking and changing the path to PHP_EXECUTABLE in config.php worked! Thank you for the help.


#11

Had this problem as well.

FYI for others with shared hosting on dreamhost:

If your PHP install(s) are missing fileinfo, you can add it yourself through the phprc file:


#12

Did doing that alone make your feed update cron job work? I think it didn’t for me so I also added -d extension=fileinfo.so as a parameter to the cron job (it’s also possible that I was too impatient and didn’t wait long enough for the job to run again).


#13

I’m not using a cron job for my feed updates - I run the daemon in screen in the shell - so I’m not sure if you’re seeing the same problem I was. For me, the complete setup was:

  • Enable fileinfo via phprc file eit as per the support article linked by @larrypoppins
  • Specify the exact path to the php executable I wanted to use in config.php
  • Restart the daemon

#14

I also use a cron job to run the updater.

And this is what my PHP path looks like in my config.php:

define(‘PHP_EXECUTABLE’, ‘/usr/local/php70/bin/php’);

My ttrss install has been working fine and feeds have been updating for a few days now.