Recently upgraded PHP and ran into the following error message while updating:
php_msgpack_serialize in Unknown on line 0
So first of all, never heard of this package. All searches for this package leads to a single PECL repo (which really doesn't mean anything either) - which has about zero mentions from the community.
A few more searches and I tracked the origin down to a repo for php-memcached-dev - a repository I've never seen or heard of.
Of course, I have heard of the actual memcached library repo: libmemcached
I tried looking for this module everywhere for a sign of it being a legit part of centos but i can't seem to get any good/reliable results.
Places I searched for any sign of this package and/or repository:
http://pkgs.org/
http://stackoverflow.com
http://php.net
http://centos.org
Just searched https://bugs.php.net too...
I don't want to seem paranoid here, but I'm not even sure if this is legit at this stage.
Shrug - I dunno. I'm keeping my server turned off though until I see something else. Anyone have some advice/input ?
For the paranoid (and yes, I found it from being a little bit myself), here is an ugly google search : php_msgpack backdoor (note: only has 2 3 search results. Check out the date in the 2nd 3rd. i haven't clicked it myself and would not recommend anyone else click it either) This seems to be a rkhunter search looking for the same file being reported above. Probably just a coincidence but who knows. Thought I'd push it out there anyways.
UPDATE: Well, long story short this turned out to be an issue with a version of PHP that was installed with Cent. It has been fixed with the latest version.
On Ubunu 16.04 with PHP 5.5 from the Ondrej-PPA (https://launchpad.net/~ondrej/+archive/ubuntu/php) I could solve the problem by installing the package php-msgpack:
sudo apt-get install php-msgpack
And than enabling the php-msgpack with
sudo phpenmod msgpack
Perhaps you ave to restart apache2 after that if you use it with PHP.
Than this error is gone:
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/20121212/memcached.so' - /usr/lib/php/20121212/memcached.so: undefined symbol: php_msgpack_serialize in Unknown on line 0
One last thing to check:
msgpack extension must be loaded before memcached.
In my scenario extensions were loaded alphabetically and therefore memcached was loaded before msgpack. Php cli didn't work until I loaded msgpack before memcached.
Following commands solved my issue.
sudo apt-get install php-igbinary
sudo apt-get install php-msgpack
sudo service php7.3-fpm reload #Change to your version
Reference:
https://laracasts.com/discuss/channels/forge/php-71-update-broken-memcached
If you land here in Oct 2020 because you're getting an error after upgrading and you're using the repository ppa:ondrej/php you need to install the specific version of msgpack because all-of-a-sudden memcached is looking for this shared object.
We're running php 7.3 from this repo and although php-msgpack was installed, we needed to install php7.3-msgpack (which wasn't needed until this upgrade). No need to "enable" it as mentioned in the accepted answer. Just restart php.
Two steps:
sudo apt install php7.3-msgpack
sudo systemctl restart php7.3-fpm.service
http://msgpack.org/
http://pecl.php.net/package/msgpack
https://code.google.com/p/php-msgpack/
If your codebase doesn't use MsgPack, you can remove it from the php.ini and/or smaller files that mention it in the php.d/* subdirectories.
Well, long story short this turned out to be an issue with a version of PHP that was installed with Cent. It has been fixed with the latest version.
Related
My php version is PHP 7.4.7 and my distro is lsb_release -a gives me
No LSB modules are avaliable
Distributor ID: TurnKey
Description: TurnKey GNU/Linux 9.12 (stretch)
Release: 9.12
Codename: stretch
and if I try to run the command sudo pecl install sqlsrv This is the output that I get
[root#360 ~]# sudo pecl install sqlsrv
downloading sqlsrv-5.8.1.tgz ...
Starting to download sqlsrv-5.8.1.tgz (186,879 bytes)
........................................done: 186,879 bytes
PHP Parse error: syntax error, unexpected end of file,
expecting function (T_FUNCTION) or const (T_CONST) in /usr/share/php/Archive/Tar.php
on line 2383
what do I need to do in order to install this module?
I'm totally unfamiliar with MS SQLserver, and PHP is not a language I have a lot to do with. But I'm intimately familiar with TurnKey, so let me have a crack at getting you going in the right direction! :)
Firstly TBH, I'm not sure whether your support question is a good fit for a Q&A site like this (at least not without much more info about the customisations that you've made and the steps previous to the issue where you find yourself). Regardless, I'll have a crack.
It's probably also worth noting that just in case it's nor clear, your current server is TurnKey v15.x - based on Debian 9/Stretch.
A quick google bought me to the MS docs which note there are some prerequisites. I'm not sure if these are related to your issue, but to ensure we're on the same page, please ensure that you have followed the relevant steps for Debian. I.e. as noted in these links:
https://learn.microsoft.com/en-au/sql/connect/php/installation-tutorial-linux-mac?view=sql-server-2017#installing-the-drivers-on-debian-8-9-and-10
https://learn.microsoft.com/en-au/sql/connect/odbc/linux-mac/installing-the-microsoft-odbc-driver-for-sql-server?view=sql-server-2017#debian17
You also didn't note how/where you installed PHP 7.4 from? I'm assuming that you installed via https://deb.sury.org/ i.e. followed the Debian steps here: https://packages.sury.org/php/README.txt
Assuming so, then I also suggest making sure that you have the latest version of PEAR installed (i.e. the one from Ondřej Surý's repo and not the one from Debian). If you want to check, try this:
apt policy php-pear
The Debian Streth version is currently 1.10.1 (full string: "1:1.10.1+submodules+notgz-9+deb9u1"). From what I can gather, the version from sury.org should be 1.10.9 (full string: "1:1.10.9+submodules+notgz-1+0~20191119.13+debian9~1.gbp296d25").
And/or installing like this should do the trick (if you have everything else already set up - probably worth double checking afterwards):
apt update
apt install php-pear
A bit more googling suggests that once you have all that sorted and if you still get that same issue, then try reinstalling Archive_Tar before retrying again:
pear install Archive_Tar
If you still have issues after that, unfortunately, I'm out of ideas. Although it's probably worth reporting the issue to MS? The issue tracker for the msphpsql code is here: https://github.com/microsoft/msphpsql/issues
I am trying to set up a web server to host Moodle on and I've been running into problems when trying to install PHP7.
I am currently using VirtualBox to host CentOS 7.4. By default, CentOS comes packaged with PHP 5.4.16. Now, from what I have read, the options for upgrading and installing from scratch are different. I have tried to follow multiple sites that guide towards getting PHP7 but have had no luck. The majority of guides tell you to install two repositories, Remi and EPEL. The main problem I have is that every time I install epel, yum either breaks or prevents me from installing another package.
[root#localhost ~]# yum update
Loaded plugins: fastestmirror, langpacks
Could not retrieve mirrorlist http://mirrorlist.centos.org/?
release=7&arch=x86_64&repo=os&infra=stock error was
14: curl#6 - "Could not resolve host: mirrorlist.centos.org; Unknown error"
One of the configured repositories failed (Unknown),
and yum doesn't have enough cached data to continue. At this point the only
safe thing yum can do is fail. There are a few ways to work "fix" this:
1. Contact the upstream for the repository and get them to fix the problem.
2. Reconfigure the baseurl/etc. for the repository, to point to a working
upstream. This is most often useful if you are using a newer
distribution release than is supported by the repository (and the
packages for the previous distribution release still work).
3. Run the command with the repository temporarily disabled
yum --disablerepo=<repoid> ...
4. Disable the repository permanently, so yum won't use it by default. Yum
will then just ignore the repository until you permanently enable it
again or use --enablerepo for temporary usage:
yum-config-manager --disable <repoid>
or
subscription-manager repos --disable=<repoid>
5. Configure the failing repository to be skipped, if it is unavailable.
Note that yum will try to contact the repo. when it runs most commands,
so will have to try and fail each time (and thus. yum will be be much
slower). If it is a very temporary problem though, this is often a nice
compromise:
yum-config-manager --save --setopt=<repoid>.skip_if_unavailable=true
Cannot find a valid baseurl for repo: base/7/x86_64
I have tried many ways of fixing this. Some of the main ways are:
yum clean all
yum --enablerepo=base clean metadata
rm -rf /var/cache/yum
I did get around this once or twice by using
yum --enablerepo=epel clean metadata
and also
sed -i "s/mirrorlist=https/mirrorlist=http/" /etc/yum.repos.d/epel.repo
I know there are more ways that I have tried, but I cannot remember all of them. Moral of the story is that they don't usually help. Sometimes yum works fine and I will run yum clean all, and it stops functioning again.
Method 2:
Another method I tried was installing the rpm packages from their respective websites. I used WinSCP to transfer the files to my VM and then used yum to install them. Everything works well and I got epel and remi to install. But then yum doesn't work properly.
Sometimes it will install packages, but some will not install. I've set the yum timeout value higher and other packages get through, but some still do not. Then I clean up the yum cache and once again I see the message with five options.
Method 3:
I found documentation on installing PHP 7 from https://wiki.centos.org/HowTos/php7 and I thought it must work because this is the supported way.
I followed along right up until the first part.
root # centos7-vm: ~ # yum -y install centos-release-scl.noarch
I will either get the error message stating the package could not be downloaded from a mirror or if yum is already giving me issues, it will show the five options to clean yum.
Method 4:
Building PHP from source was another option I attempted. I navigated to http://php.net/downloads.php and downloaded the tarball and used WinSCP to get it on my machine.
I extracted the files and then navigated into the php directory.
I attempted to get things going by using ./configure, but it stated I needed gcc.
I tried to install gcc with yum install gcc, but could not install all of the packages.
I made a new VM and instantly tried installing gcc, but still not luck.
Summary
Sometimes I understand why yum does not work, other times I'm slamming my head on my desk.
Is there a standardized method of getting PHP 7 on CentOS? Can anyone link an accurate guide?
What is the reason that CentOS comes packaged with PHP 5.4 and not 7?
I feel like I have tried almost everything, but I know there is some webpage that I just haven't found yet. I think I did about all the research I possibly could for today.
I'm sure my question is probably not structured the best and might be a little confusing, but I've been working on this for about 6-7 hours now.
This is my first post, so I apologize if it is not perfect.
in my vps, I just added remi repo,
$ wget http://rpms.famillecollet.com/enterprise/remi-release-7.rpm
$ rpm -Uvh remi-release-7.rpm
or
$ rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-7.rpm
then you enable on /etc/yum.repos.d/ on remi.repo, and remi-php72.repo files.
later you update, and install php and its libraries.
epel is not necesary, but is in the official repo. you just got to do a
$ yum install epel-release
and enable the file in /etc/yum.repos.d/
have you check some logs files? to see if there's any errors
All,
I have compiled and installed Apache 2.2.32 successfully on Debian 8.7, following the directions at http://www.tecmint.com/install-and-compile-php-7-on-centos-7-and-debian-8/ but have received an error when compiling that it can't find a2enmod. Error below:
[preparing module 'php7' in /etc/apache2/mods-available/php7.load]
Can't exec "a2enmod": No such file or directory at /usr/bin/apxs line 578.
'a2enmod php7' failed Makefile:164: recipe for target 'install-sapi'
failed make: *** [install-sapi] Error 2
I have researched this error but most of my a2enmod searches result in finds for enabling ModRewrite for some reason (perhaps there's a link here?!). Anyway, I found the following question asked several months back, but there was no answer posted so I'm trying again:
https://stackoverflow.com/questions/38542193/a2enmod-doesnt-exist-when-compiling-apache-but-php7-compile-install-requires-i/42559640#42559640
The compile options are listed in the first link I gave, so I won't repeat them here, but I have followed the document to the letter, and it is using the same major versions of PHP, Apache and Debian as me. I don't know enough about the details of each of these or my platform to understand why this is, but I can't find how to install a2enmod anywhere, and aptitude searches give me nothing.
Can anyone help with this? I am trying to install the most recent version (9) of OwnCloud but I cannot get PHP 7 to compile!
Any help is much appreciated.
All,
After much of a headache, the answer appears to be in this article:
https://www.cyberciti.biz/faq/installing-php-7-on-debian-linux-8-jessie-wheezy-using-apt-get/
This tells us how to get the official debian repositories that include PHP 7 added to the apt repositories, then install them from there. This solves my problem by giving me php7, as for why it wasn't compiling itself remains a mystery.
You need install a2enmod binary, which for your Debian version is not in apache2.2-commonpackage, but in apache2.
So, simply, you have to do:
Debian 8+
apt-get install apache2
Debian wheezy
apt-get install apache2.2-common
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/20131226/memcached.so' - /usr/lib/php/20131226/memcached.so: undefined symbol: php_msgpack_serialize in Unknown on line 0
Earlier today, I enabled forwarding of messages to root#localhost on my server to beam back to my personal email.
I have been receiving the above error message at 30 minutes intervals since. Of course, I checked and there's a PHP session cleaning script attached to cron to run at 30 minutes interval.
I have been searching around but couldn't find any specific solution.
My setup:
memcached 1.4.25
PHP 7.0
nginx/1.10.0
mysql Ver 14.14 Distrib 5.7.13
Ubuntu Server LTS 16.04
The closest I found to my issue above was this: http://community.rtcamp.com/t/php-warning-error-php-msgpack-serialize/6262 but there's no answer on that thread.
First you need to work out which PHP ini files are being loaded. From command line you can run php --ini. Technically apache/nginx can be running a different version, and you can look up using phpinfo(); exit(); test script if you want to view that one instead. As you're using cron, you're using the command line version anyway.
In one of these files you will find a line similar to:
extension="memcache.so"
If you don't need this extension at all, then just comment it out by prepending it with a ;:
;extension="memcache.so"
If you DO need the extension then it sounds like you need to rebuild this module. The easiest way is using PECL.
pecl install memcache
You might need to follow some instructions whilst running the install. Once it's done, you should be able to run php -v and it shouldn't output the same warning. If this has worked and you just see the php versions, you should restart nginx (if you need it on the website, the command line one should work instantly). :
sudo service nginx restart
I guess you can get a help from a similar topic on the site here.
But briefly, one of your extensions is loading memcache and the path in that is not correct.
You should find it in your php.ini and fix the path manually.
It means there is an extension=... or zend_extension=... line in one of your php configuration files (php.ini, or another close to it) that is trying to load that extension : ixed.5.2.lin
Unfortunately that file or path doesn't exist or the permissions are incorrect.
Try to search in the .ini files that are loaded by PHP (phpinfo() can indicate which ones are) - one of them should try to load that extension.
Either correct the path to the file or comment out the corresponding line.
Check if msgpack extension is installed and enabled (php -i | grep msgpack).
It seems that PHP in Ubuntu is compiled with it by default.
If it's installed and enabled, then check you memcached extension. Maybe you are using it from a previous installation or something similar.
tl;dr: I eventually had to clear everything PHP that is less than php7.0 from my server manually, along with their related cron jobs.
Long story:
Going through my running process (ps -aux | grep 'php'), I realized php5 is still in there running. Everything on my server uses PHP7, so that lingering process was redundant, plus there was a cron job that runs a session cleaning job on the php5 somewhere, using a script which goes looking for the so-called missing Memcached file.
After removing all phps that are less than php7 from system via apt, I also went in to delete all the existing folders that are less than php7 in /usr/lib/php5 and or /usr/lib/php/ along with their cron related jobs found in /etc/cron.d/php5 and or /etc/cron.d/php/
No more whining warnings from PHP session cleaning about memcache
I was getting a similar error with memcache.so and I noticed there was a new version of memcache that was installed the moment the system ran 'pecl install memcache' (automatically that updated to the latest version). The new version caused that error so I had to change the version 1 version lower to pecl install memcache-4.0.5.2 and it worked. Thanks #Farkie for that insight, that's when I realized that there was a new version that just came out a few days ago and that was it!
Just install msgpack extension and the error message should disappear:
apt install php-msgpack
You might also be missing igbinary extension:
apt install php-igbinary
This is my server configuration:
CentOS release 6.5 (Final)
PHP 5.5.7
pecl_http 2.0.4 stable
Server version: Apache/2.2.15 (Unix)
I have everything up and running except when I tried to load the pecl_http module it gives me the following warning and it won't load:
PHP Warning: PHP Startup: Unable to load dynamic library '/path/to/php/modules/http.so' - /path/to/php/modules/http.so: undefined symbol: php_persistent_handle_abandon in Unknown on line 0
I tried to look everywhere but without a luck. The install seems fine but I don't know what's wrong with it.
I came here with the same problem - I couldn't get 2.0.4 to work - in hopes of helping you or others that stumble here, I invite you to check out my answer on serverfault here.
For your convenience I've also copied it below:
I didn't have a setup problem - at least not to my knowledge. I am running nginx + php5-fpm. My php.ini file was correctly configured and all my other extensions were working properly - test it with phpinfo() or php --ini.
My problem with pecl_http (HttpRequest) was the extension's version (2.0.4). Check your version by running in the command line
pecl list
I was unable to get pecl_http-2.0.4 to work, but I was able to run
pecl uninstall pecl_http
then
pecl install pecl_http-1.7.6. Make sure you have libcurl installed as well or you might experience install failures.
After restarting php5-fpm and my webserver (nginx) everything was working prefectly!
EXTRA HELP:
Before you install - and pear is installed - you may want to run these two commands assuming you are using the php.ini in fpm - or you can write the path according to your configuration:
pear config-set php_ini /etc/php5/fpm/php.ini
pecl config-set php_ini /etc/php5/fpm/php.ini
This makes it so that pecl knows which php.ini file you are using with your web-server and will add the extension=http.so in the correct spot. This helped me so maybe it'll help you too!
Since version 2 PECL HTTP requires modules raphf and propro to be loaded before http. So edit your php.ini or php.d/pecl_http.ini or whereever you load modules, so it looks like:
extension=raphf.so
extension=propro.so
extension=http.so
Source:
http://www.php.net/manual/en/http.install.php#113769
When it comes to installing from PECL or PEAR, I too always seem to run in to "something" that prevents a module from working as it should. The above error is actually pretty common on Ubuntu & Debian.
The packages provided by Ubuntu & Debian do not automatically install all dependencies required for every module, so I had to hunt down a solution between StackExchange, Google and the developers website.
What fixed this for me (note: on Debian, not CentOS), was installing the following packages:
php5-phpdbg php5-dev php-http zlib1g-dev libcurl4-openssl-dev libevent-dev imagemagick libmagick++-dev imagemagick-common libmagic-dev libghc-iconv-dev libpcre3-dev
The package marked as just php-http is intentional. This specific package doesn't carry a 5, thus unless you knew you needed it, you'd most likely overlook it. So for those on Ubuntu and/or Debian systems, search on both php5 and php (using --names-only helps narrow down the packages).
I'm mentioning this in hopes that it'll help others that may have the same issue on a similar system. I'm not 100% on the package names for the CentOS repository, though having the names of the packages needed in general may help you and others to narrow down the list.
Once the packages are installed, simply uninstall & reinstall the pecl_http package, restart php5-fpm and the error should go away; confirmed by creating a phpinfo file.
I'd like to expand on Jack Miller's answer. I'm using OpenSUSE, and it puts extension=******.so loaders into /etc/php5/conf.d dir, split into multiple files. For example:
ctype.ini debug.ini exif.ini http.ini imagick.ini mbstring.ini mysqli.ini opcache.ini pdo.ini pdo_sqlite.ini raphf.ini tokenizer.ini xmlreader.ini xsl.ini curl.ini dom.ini gd.ini iconv.ini json.ini memcache.ini mysql.ini openssl.ini pdo_mysql.ini propro.ini sqlite3.ini xdebug.ini xmlwriter.ini zlib.ini
Naturally, it loads them one by one using glob, which means they get loaded in an alphabetical order, and you guessed it - raphf.ini loads after http.ini.
Renaming raphpf.ini something like a_raphf.ini does the trick.