We are inundated with the entry:
Deprecated: Directive 'safe_mode' is deprecated in PHP 5.3 and greater in Unknown on line 0
Deprecated: Directive 'safe_mode' is deprecated in PHP 5.3 and greater in Unknown on line 0
Deprecated: Directive 'safe_mode' is deprecated in PHP 5.3 and greater in Unknown on line 0
in the apache2 error logs. But the bug doesn't seem to have any notable effect on our systems. It makes it very hard for us to diagnose actual problems and errors by overfilling our error logs.
None of the sysadmins I work with are aware of when the error started appearing or what software might be causing it.
We are using Apache/2.2.16 on Debian.
Edit: I have tracked the problem down to Froxlor adding per-user ini files, some of which have safe_mode enabled. There seems to be no way to disable safe_mode either globally in froxlor or per user and the froxlor manual has nothing. Any help?
Safe_mode is a PHP feature that has been depreciated in 5.3 and ultimately removed in 5.4. It is pointless and potentially dangerous and should not be used.
To turn it off go to your php.ini file and change
safe_mode = on
to
safe_mode = off
Restart apache and you should be good to go.
Related
The following command used to work flawlessly:
C:\tools\apache-cxf-3.3.1\bin\wsdl2java -client -d generated foo.wsdl
It no longer works with the latest version of JDK - 12. I have downloaded the latest version of Apache CXF, and still get the same error:
-Djava.endorsed.dirs=C:\tools\apache-cxf-3.3.1\bin\..\lib\endorsed is not supported. Endorsed standards and standalone APIs
in modular form will be supported via the concept of upgradeable modules.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Could anyone offer a tip on how to remedy this?
I got the Apache CXF 3.3.1 wsdl2java utility to work with the latest OpenJDK 11 by doing 4 things:
Pull down this jar and place it into the {CXF_HOME}/lib directory: https://mvnrepository.com/artifact/javax.jws/jsr181-api/1.0-MR1
Pull down this jar and also place it in the {CXF_HOME}/lib directory: https://mvnrepository.com/artifact/javax.xml.ws/jaxws-api/2.3.1
In my case, since I'm running on a Mac, I vi'd the wsdl2java script and made sure these two jars are explicitly being set on the CXF classpath, by doing the following declaration within the script right before the execution of the java command:cxf_classpath=${cxf_classpath}:../lib/jaxws-api-2.3.1.jar:../lib/jsr181-api-1.0-MR1.jar
Lastly, I removed the '-Djava.endorsed.dirs="${cxf_home}/lib/endorsed"' parameter from the java command at the end of the script, since newer JDKs no longer support this argument, so my command now looks like this:$JAVA_HOME/bin/java -Xmx${JAVA_MAX_MEM} -cp "${cxf_classpath}" -Djava.util.logging.config.file=$log_config org.apache.cxf.tools.wsdlto.WSDLToJava "$#"
Now, using OpenJDK11, I'm able to point to an external WSDL file and successfully generate the client code I need to consume this SOAP service with the following command:
./wsdl2java -client -d src https://somewhere.com/service\?wsdl
Whether or not this all works yet is TBD in terms of being able to call and consume the SOAP service I'm coding against, but I've at least now overcome the Java9+ support issue with this tool specific to generating client code from a WSDL.
If your needs are different, I would at least remove the '-Djava.endorsed.dirs="${cxf_home}/lib/endorsed"' JVM parameter and start calling the wsd2java command with the parameters you need set and just start iteratively adding back in the missing libs it starts throwing java.lang.NoClassDefFoundError errors for.
Their FAQ specifically says starting in 3.3.x, Java 9+ will be supported but something clearly dropped the ball between the no-longer-supported hardcoded JVM arguments still being passed in the utility and the missing libraries to support the newer JDKs where these legacy libs have been removed.
Hope this helps someone out there unfortunate enough to ALSO still be programming against SOAP endpoints but trying to at least keep the client-side code you're writing up to date and taking advantage of the newer features of the modern JDK.
With xdebug enabled I can reproduce an error:
composer create-project laravel/laravel
cd laravel
composer require proengsoft/laravel-jsvalidation
php artisan vendor:publish --provider="Proengsoft\JsValidation\JsValidationServiceProvider" --tag=public
Error:
PHP Warning: Uncaught League\Flysystem\Plugin\PluginNotFoundException: Plugin not found for method: read in /tmp/laravel/vendor/league/flysystem/src/Plugin/PluggableTrait.php:49
Stack trace:
But without xdebug enabled, everything runs fine.
I am wondering if this is happening only for me or also for others, before reporting it to xdebug.
php -v
PHP 7.1.15-1+ubuntu16.04.1+deb.sury.org+2
Package: php-xdebug
Version: 2.6.0+2.5.5-1+ubuntu16.04.1+deb.sury.org+1
Composer.lock for reference
https://gist.github.com/amenk/9d63975cf4aabf86288b79fb95e8156c
I tracked it down to the following function in Flysystem:
public function invokePluginOnFilesystem($method, $arguments, $prefix)
{
$filesystem = $this->getFilesystem($prefix);
try {
return $this->invokePlugin($method, $arguments, $filesystem);
} catch (PluginNotFoundException $e) {
// Let it pass, it's ok, don't panic.
}
$callback = [$filesystem, $method];
return call_user_func_array($callback, $arguments);
}
The exception is thrown in invokePlugin() but caught afterwars (if xdebug is off). It Xdebug is on, that does not work anymore.
I have a 1G memory limit for PHP-CLI in place.
Bug Reported: https://bugs.xdebug.org/view.php?id=1535
This is not really a question, but a bug report. I can easily reproduce all kinds of wonkyness due to exceptions. Please file a bug report at https://bugs.xdebug.org — preferably with a lot smaller test case
Some more info / quick fix:
I was using
xdebug.collect_params=4
with
xdebug.collect_params=1
the bug does not appear.
Also the bug only appears after updating to PHP 7.1.15 - and it does not appear for PHP 7.2
There is also a warning about huge scripts in the docs:
https://xdebug.org/docs/all_settings
The setting defaults to 0 because for very large scripts it may use
huge amounts of memory and therefore make it impossible for the huge
script to run. You can most safely turn this setting on, but you can
expect some problems in scripts with a lot of function calls and/or
huge data structures as parameters. Xdebug 2 will not have this
problem with increased memory usage, as it will never store this
information in memory. Instead it will only be written to disk. This
means that you need to have a look at the disk usage though.
I have installed the solr service on a LINUX environment. Now trying to start the service using the below command
service solr start
After executing this command, am getting below error from the server
Waiting to see Solr listening on port 8080 [-] Still not seeing Solr listening on 8080 after 30 seconds!
tail: cannot open `/var/solr/logs/solr.log' for reading: No such file or directory
I created the solr.log file manually and placed it under the above mentioned path, But as soon, i issue the command "service solr start" . The solr.log file will be renamed and there won't be any new file created with the solr.log. hence the service fails to start. Could anyone let me know how to tackle this issue.
Thanks in advance.
I had a similar issue, and was able to find a hint in the /var/solr/logs/solr-8983-console.log
Originally I had been using Java 8, and Solr was working just fine for me.
When I switched to Java 11, Solr would have the issue you reported.
The log file contained the following:
Java HotSpot(TM) 64-Bit Server VM warning: Option UseConcMarkSweepGC was deprecated in version 9.0 and will likely be removed in a future release.
Unrecognized VM option 'UseParNewGC'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
I switched back to Java 8 and Solr started just fine.
First, did you use the procedure provided to install the Solr service page 461
Second, did you set the proper overrides to the environment defaults in a solr.in.sh script (p. 462 of the ref manual). You also need to make sure that the LOG4J_PROPS in the solr.in.sh file points to your log4j.properties file. Also make sure that SOLR_LOGS_DIR is pointing to the correct place.
If all that is correct, then check that the values in your log4j.properties file are set correctly (p. 468 of the ref manual).
You can get the reference manual here: https://www.apache.org/dyn/closer.lua/lucene/solr/ref-guide/ if you don't have it already.
I had a tough time getting Solr to run as a service, but in the end I simply wasn't reading carefully enough.
I'm attempting to use appcfg.py migrate_traffic, but I get a 500 error when using this with a module. The documentation states that a module can be specified:
The 'migrate_traffic' command gradually gradually sends an increasing fraction
of traffic your app's traffic from the current default version to another
version. Once all traffic has been migrated, the new version is set as the
default version.
app.yaml specifies the target application, version, and (optionally) module; use
the --application, --version and --module flags to override these values.
Can be thought of as an enhanced version of the 'set_default_version'
command.
If I try this with a module, I get the following error
Error 500: --- begin server output ---
Server Error (500)
A server error has occurred.
--- end server output ---
The source at https://code.google.com/p/googleappengine/source/browse/trunk/python/google/appengine/tools/appcfg.py?r=396 (MigrateTraffic) doesn't seem to use the module at all. Is this a bug in appcfg.py or a missing feature of app engine?
I filed a ticket with google support. The answer is that modules are not supported with migrate_traffic yet. No ETA on when they might be supported. I think the current version of appcfg.py doesn't mention modules as prominently in the help for migrate_traffic as well.
I'm a newbie in cakephp, I'm trying to upgrade cakephp to the latest version.
I install the fresh cakephp 1.3 on my computer and the upgrade it to cakephp 2.1.
I use shell to upgrade, but after I run 'upgrade all' command, I saw two error:
Warning Error: chmod(): Operation not permitted in [/var/www/cakephp-1.3/lib/Cake/Utility/Folder.php, line 639]
Warning Error: touch(): Utime failed: Operation not permitted in [/var/www/cakephp-1.3/lib/Cake/Utility/Folder.php, line 640]
I think it has upgraded complete. Because I see the message from terminal like this:
Done updating /var/www/cakephp-1.3/app/Console/cake.php
Done updating /var/www/cakephp-1.3/app/Console/Command/AppShell.php
Running components
Running exceptions
Then I refresh my app and I got some errors:
http://flic.kr/p/bwUpwY
Then I delete 'cake' directory, and the error message has changed:
http://flic.kr/p/bKP7Te
So now I don't know what to do next, because I did many ways but still not make it work.
So anybody please tell me what I did wrong and how can I upgrade cakephp successful.
Thanks in advance.
This looks like you have permissions issues on some of the directories that the CakePHP migration script expects to be writable.
This could lead to the migration failing on some parts and leaving a partially broken install after it completes.