on a CentOS Linux release 6.0 (Final), I've this problem with passenger 3.0.9:
[ pid=3332 thr=16838960 file=abstract_request_handler.rb:466 time=2011-11-16 23:54:10.795 ]: Accepting new request on main socket
[ pid=2894 thr=139811053770496 file=ext/nginx/HelperAgent.cpp:933 time=2011-11-16 23:54:10.958 ]: Uncaught exception in PassengerServer client thread:
exception: write() failed: Connection reset by peer (104)
backtrace:
in 'void Client::forwardResponse(Passenger::SessionPtr&, Passenger::FileDescriptor&, const Passenger::AnalyticsLogPtr&)' (HelperAgent.cpp:705)
in 'void Client::handleRequest(Passenger::FileDescriptor&)' (HelperAgent.cpp:859)
in 'void Client::threadMain()' (HelperAgent.cpp:952)
[ pid=4135 thr=16838960 file=abstract_request_handler.rb:466 time=2011-11-16 23:54:12.710 ]: Accepting new request on main socket
What can be? Im sure my app works well because on others machines haven't problems, I tried also passenger edge and latest nginx. The app is a 2.3.11 rails application.
Found myself, we need to remove proxy_temp files, this probably because upgrading from a version of nginx to another break somethings. So my solution (for now):
rm -rf /etc/nginx/proxy_temp/*
What is the maximum number of open files allowed on your system? You can check that using ulimit -n. Could you please check if increasing that value in /etc/sysctl.conf helps you?
Related
I am trying to deploy my application built in ASP.Net 4.6.1. So I am using HWC Buildpack.
Below is my manifest.yml
---
applications:
- name: DRSN
random-route: true
memory: 128M
buildpack:
https://github.com/cloudfoundry/hwc-buildpack.git
env:
DOTNET_CLI_TELEMETRY_OPTOUT: 1
DOTNET_SKIP_FIRST_TIME_EXPERIENCE: true
The error that I am receiving is below.
Waiting for API to complete processing files...
Staging app and tracing logs...
Cell 0f7012eb-9e32-4fdf-ba92-85aee4639139 creating container for instance 34107c3c-1acb-4aa5-b435-b06516abcfcb
Cell 0f7012eb-9e32-4fdf-ba92-85aee4639139 successfully created container for instance 34107c3c-1acb-4aa5-b435-b06516abcfcb
Downloading app package...
Downloading build artifacts cache...
Downloaded build artifacts cache (231B)
Downloaded app package (19.5M)
Failed to compile droplet: Failed to compile droplet: fork/exec /tmp/buildpackdownloads/6c6dca8d638ac0d145d6581f9eb9a96a/bin/compile: permission denied
Exit status 223
Cell 0f7012eb-9e32-4fdf-ba92-85aee4639139 stopping instance 34107c3c-1acb-4aa5-b435-b06516abcfcb
Cell 0f7012eb-9e32-4fdf-ba92-85aee4639139 destroying container for instance 34107c3c-1acb-4aa5-b435-b06516abcfcb
Error staging application: App staging failed in the buildpack compile phase
Can anyone help me resolve this issue? Am I not correct in my manifest.yml? Or is it something else?
I believe that the problem is that you're telling the system to use the HWC buildpack, but at the same time you're not setting the Windows stack (at least based on what info I can see). That means it's going to default to the Linux stack, which I believe is why you're seeing the fork/exec /tmp/buildpackdownloads/... error.
Try adding stack: windows to your manifest.yml or -s windows to your cf push command (for future reference, when you need help always include the full cf push command you're running).
PS: you shouldn't use https://github.com/cloudfoundry/hwc-buildpack.git that is telling the system to grab the master branch in whatever state it's currently in. That's a.) not reproducible and b.) not guaranteed to be in a working state. You should either use the platform provided buildpack names (from cf buildpacks) or append #<branch_or_tag> to the end of the URL so it picks a specific branch. All CF Buildpacks have tags for each release. It's strongly recommended you use a tagged release.
I installed cloudify3.4 according to the cloudify DOCS. When I install the manager, and executed like this:
# cfy bootstrap --install-plugins -p openstack-manager-blueprint.yaml -i openstack-manager-blueprint-inputs.yaml
an error occurred:
[ERROR] Bootstrap failed! (Workflow failed: Task failed 'neutron_plugin.floatingip.create' -> Expected exactly one object of type network with match {'name': u'178d7438-ca18-4df6-a5d0-dd11a53155a5'} but there are 0)
I have already installed
"cloudify_openstack_plugin-1.4-py27-none-linux_x86_64-centos-Core.wgn"
"cloudify_openstack_plugin-1.4-py27-none-linux_x86_64-redhat-Maipo.wgn"
So, how to solve this error?
Thank you to everyone who helped me!
In Cloudify version 3.4, the Cloudify manager can only be installed (bootstrapped) on either CentOS 7.x or RHEL 7.x.
See more details :
http://docs.getcloudify.org/3.4.0/manager/prerequisites/
FYI: There are no limitations in host agents.
That means that once the Cloudify manager is alive, it will enable you to deploy anything on every operating system.
When I try to run a command on a sub-process created by ProcessBuilder, i get segmentation violation.
[Symfony\Component\Process\Exception\RuntimeException]
The process has been signaled with signal "11".
But this doesn't happen upto v2.5.12 only from v2.6.0
finally the issue is found. Thanks to Rackspace support staff Cristian Banciu and Mike Bostic
Cause:
Latest newrelic php agent 4.23.1.107 causes seg fault when used with symfony 2.6.0 or above with process component.
newrelic.browser_monitoring.auto_instrument = 0 didn't help
Solution:
finally i downgraded newrelic php agent to 4.21.0.97-1 and all work fine
Anojan
I'm trying to start a new mean stack application. However i only get this error when I'm running grunt to start the server:
[nodemon] v1.2.1
Running "watch" task
[nodemon] to restart at any time, enter `rs`
[nodemon] watching: *.*
[nodemon] starting `node --debug server.js`
Waiting...
Debugger listening on port 5858
Mean app started on port 3000 (development) cluster.worker.id: 0
/Users/olehenrik/Sites/learn/mean_test2/node_modules/mongoose/node_modules/mongodb/lib/mongodb/connection/base.js:246
throw message;
^
TypeError: Cannot read property 'length' of undefined
at processResults (/Users/olehenrik/Sites/learn/mean_test2/node_modules/mongoose/node_modules/mongodb/lib/mongodb/db.js:1581:31)
at /Users/olehenrik/Sites/learn/mean_test2/node_modules/mongoose/node_modules/mongodb/lib/mongodb/db.js:1619:20
at /Users/olehenrik/Sites/learn/mean_test2/node_modules/mongoose/node_modules/mongodb/lib/mongodb/db.js:1157:7
at /Users/olehenrik/Sites/learn/mean_test2/node_modules/mongoose/node_modules/mongodb/lib/mongodb/db.js:1890:9
at Server.Base._callHandler (/Users/olehenrik/Sites/learn/mean_test2/node_modules/mongoose/node_modules/mongodb/lib/mongodb/connection/base.js:448:41)
at /Users/olehenrik/Sites/learn/mean_test2/node_modules/mongoose/node_modules/mongodb/lib/mongodb/connection/server.js:481:18
at MongoReply.parseBody (/Users/olehenrik/Sites/learn/mean_test2/node_modules/mongoose/node_modules/mongodb/lib/mongodb/responses/mongo_reply.js:68:5)
at null.<anonymous> (/Users/olehenrik/Sites/learn/mean_test2/node_modules/mongoose/node_modules/mongodb/lib/mongodb/connection/server.js:439:20)
at emit (events.js:107:17)
at null.<anonymous> (/Users/olehenrik/Sites/learn/mean_test2/node_modules/mongoose/node_modules/mongodb/lib/mongodb/connection/connection_pool.js:201:13)
[nodemon] app crashed - waiting for file changes before starting...
Have any one encountered this before? Can't find too many other people who have encountered this before.
I was also facing the same error and this info solves it.
"Upgrade to 3.8.23. 3.8.22 introduced better compatibility with mongodb server 3.0 by upgrading to latest version of the driver." credit to vkarpov15 from mongoose Github thread.
What I did was I edit my package.json to upgrade mongoose to "3.8.23". After I edited the package.json I ran npm install and bower install(just to make sure) again and that solved the problem.
I've installed Netbeans 7.2. with GlassFish Server 3.1.2 but when I run web application the default jsp page or any other jsp pages I got the error:
GlassFish Server 3.1.2 Start Failed
C:\Users****\Documents\NetBeansProjects\WebApplication3\nbproject\build-impl.xml:1022:
Deployment error: GlassFish Server 3.1.2 Start Failed See the server
log for details. BUILD FAILED (total time: 47 seconds)
build-impl.xml
< target depends="init,-init-cos,compile,
compile-jsps,-do-compile-single-jsp,-pre-dist,-do-tmp-dist-with-manifest,-do-tmp-dist-without-manifest,-pre-run-deploy,
-pre-nbmodule-run-deploy,-run-deploy-nb,-init-deploy-ant,-deploy-ant,-run-deploy-am,-post-nbmodule-run-deploy,-post-run-deploy,
-do-update-breakpoints" name="run-deploy"/>
< target if="netbeans.home" name="-run-deploy-nb">
< nbdeploy clientUrlPart="${client.urlPart}" debugmode="false"
forceRedeploy="${forceRedeploy}"/>
////////////////////////
glassFish Server 3.1.2
SEVERE: Shutting down v3 due to startup exception : No free port
within range:
8080=com.sun.enterprise.v3.services.impl.monitor.MonitorableSelectorHandler#788a7b
I've found the solution. My 8080 port was reserved by Oracle. So I edited the domain.xml file inside glassfish\domains\domain1\ config\domain.xml file.
I replaced the port 8080 with 9999 and replaced the file. After that I added the glassfish server to netbeans, and now it is working.
Thank You everyone.
The error message states it clearly:
No free port within range: 8080
Probably there is another instance of Glassfish (or any other server) running on your system. Try to find it out by calling http://localhost:8080 in your browser.
**Another option to solve this probs
**Enter the following on the command line:
netstat -ao
The active TCP addresses and ports will be listed — locate the line with local address “0.0.0.0:80″ and note the PID value.
Now right-click the task bar and select Start Task Manager. Navigate to the Processes tab and, if necessary, click View > Select Columns… to ensure “PID (Process Identifier)” is checked. You can now locate the PID you noted above. The description and properties should help you determine which application is using the port.
The Task Manager allows you to kill the process, but be a little wary about doing that — especially if it’s “NT Kernel & System”.**
i had the same problem.
i solved it by configuring the glassfish with jdk7 instead of jdk8.
i dont know why it wasnt working with jdk8 but now the glassfish is running.