I've been attempting to get a Docker image running on Heroku for some testing purposes based on the Dockerfile written by a friend of mine:
https://github.com/johncoder/simc-web
I can test and run this locally just fine, but once I get it uploaded to Heroku, a POST to the running container yields the following error from CURL:
curl -x POST --data "armory=us,drenden,cataia" https://hdingo-bot-
simc.herokuapp.com/simc
curl: (5) Could not resolve proxy: POST
Which is not overly helpful, and also doesn't print anything to the logs in the container either.
So a little more indepth analysis, and from a bash command inside of the running container, I can attempt to call the simc binary manually... but this results in an Illegal Instruction error:
/usr/bin $ simc
Illegal instruction
The only thing I can find so far, is that perhaps the underlying chipset doesn't support what I'm attempting to run? But it also doesn't seem to be extremely common.
Thanks!
Related
If you deploy using the command below,
twilio flex:plugins:deploy --changelog='first deploy'
The following error will occur.
I don't understand the meaning of the path pointed to by resource.
Error code 20404 from Twilio: The requested resource /Services/ZSXXXXXXXXXXXXXXXXXXXXXXX/Environments was not found. See https://www.twilio.com/docs/errors/20404 for more info.
This is the first deployment that has not been deployed yet.
What should i do?
twilio serverless:deploy
Using the above command, functions and assets are deployed on a serverless basis.
At that time, I have deleted the Services of functions and assets that existed by default.
Is this default Services relevant for plugins?
Also, if it is related, where is the part to reset in the plug-in?
When I contacted support, they told me to run the reset command.
curl https://flex-api.twilio.com/v1/Configuration \
-H "Content-Type: application/json" \
-d '{"account_sid":"ACCOUNT_SID", "serverless_service_sids": []}' \
-u ACCOUNT_SID:AUTH_TOKEN
If you deploy again after executing the above command
I was able to deploy without problems.
I'm trying the NodeMCU Docker build in Ubuntu 16.04.4 LTS for the first time.
I have read the tagged articles here for Docker and NodeMCU, but don't see this particular error.
"docker run hello-world" has no problems.
I have tried the NodeMCU build command in both forms:
$ docker run --rm -ti -v `pwd`:/opt/nodemcu-firmware marcelstoer/nodemcu-build
and the explicit path variation:
$ docker run --rm -it -v /home/tim/nodemcu-firmware:/opt/nodemcu-firmware marcelstoer/nodemcu-build
In both cases, I get this error:
standard_init_linux.go:187: exec user process caused "exec format error"
I have searched on this error, and most solutions are related to a missing shebang.
However, I'm not sure what script would need the shebang, or why it would be not working in my case but correct for others.
Has anyone else run across this error?
Speaking without deep technical details, this error means that the kernel can not recognize the format of the executable file, thus, it can not run this file. In your case this error is about the executable file which is started when the container is launched. According to the Cmd entry in the output of docker inspect marcelstoer/nodemcu-build, it is a file /bin/sh, which is an ELF executable.
When Linux can not execute ELF binary and returns such an error (about the file format), it usually is related to the system architecture. More specifically, the image marcelstoer/nodemcu-build contains ELF64 executables (i.e. for amd64 architecture), and your system does not support it (is it i386 or even some flavor of arm?). Running docker run hello-world, however, works fine for you, because hello-world image exists for all architectures supported by Docker.
According to the Dockerfile of marcelstoer/nodemcu-build image, it is built from ubuntu, which exists for different architectures, thus, you may try building the marcelstoer/nodemcu-build image on your system rather than pulling it from the dockerhub.
P.S.: regarding the solution you have linked to your question. This is not about your case (ELF binary), rather it is about a script. In case of script, the executable format is recognized by the shebang (#!) at the very beginning of the file, thus, the script must start with #!, not with the newline. That's why the author got the same error: the kernel could not detect that this is a script and failed to start it. Different (but similar) reasons, same error.
I am trying to setup TensorFlow Serving using Docker on a Windows machine by following the instructions from https://tensorflow.github.io/serving/docker.html
I have successfully built and run the container and cloned the TensorFlow servings sub-modules. However, while running the command
"bazel test tensorflow_serving/..." the error
Linking of rule: '//tensorflow_serving/batching/test_util:puppet_batch_scheduler_test' failed:gcc failed: error executing command /usr/bin/gcc .... is displayed
The complete stack trace is shown in the below image.
Any help is appreciated.
I don't know how to solve the problem directly, but a workaround could be pulling a docker image where the TF Serving is already compiled such as this one.
I'm using Icinga to monitor some servers and services. Most of them run fine. But now I like to monitor a JBoss-AS on one server via NRPE. Therefore I'm using the check_jboss-Plugin from MonitoringExchange. Although each time I try running a test-command from my Icinga-Server via NRPE I'm getting a NRPE: unable to read output error. When I try executing the command directly on the monitored server it runs fine. It's strange that the execution on the monitored server takes around 5 seconds to return a acceptable result but the NRPE-Exceution returns immediately the error. Trying to set up the NRPE-timeout didn't solve the problem. I also checked the permissions of the check_jboss-plugin and set them to "777" so that there should be no error.
I don't think that there's a common issue with NRPE, because there are also some other checks (e.g. check_load, check_disk, ...) via NRPE and they are all running fine. The permissions of these plugins are analog to my check_jboss-Plugin.
Following one sample exceuction on the monitored server which runs fine:
/usr/lib64/nagios/plugins/check_jboss.pl -T ServerInfo -J jboss.system -a MaxMemory -w 3000: -c 2000: -f
JBOSS OK - MaxMemory is 4049076224 | MaxMemory=4049076224
Here are two command-executions via NRPE from my Icinga-Server. Both commands are correctly
./check_nrpe -H xxx.xxx.xxx.xxx -c check_hda1
DISK OK - free space: / 47452 MB (76% inode=97%);| /=14505MB;52218;58745;0;65273
./check_nrpe -H xxx.xxx.xxx.xxx -c jboss_MaxMemory
NRPE: Unable to read output
Does anyone have a hint for me? If further config-information needed please ask :)
Try to rule out SELinux either by disabling it globally or by changing the SELinux type to nagios_unconfined_plugin_exec_t.
I get the error below when trying to start my rails app on the localhost:
PGError (could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
From what I have read it sounds like this is most likely a problem in connecting to the Postgres server, and may indicate that it is not started?
It all started when I was attempting my first (yay noobs!) merge using git. There was a conflict (having to do with the Rubymine workspace.xml file), and I started to open up a conflict resolution program. It then seemed that there was really no need to track workspace.xml at all and so I quit from the resolution program, intending to run "git rm --cached" on the file. I think in quitting the program something went foul, and I ended up restarting, before untracking the file, and then completing the merge. Further evidence that something was gummed up is that my terminal shell didn't open up correctly until I restarted the machine.
Now, as far as I can tell, everything in the merge went fine (there were trivial differences in the two branches anyway), but for the life of me I can't seem to get rid of this PGError. If it is as simple as starting the server, then I'd love help on how to do that.
(other context: OSx, rails 3, posgresql83 installed via macports, pg gem).
EDIT - I have been trying to start up the server, but am not succeeding. e.g., I tried:
pg_ctl start -D /opt/local/var/db/postgresql83/defaultdb
This seems to be the right path for the data (it finds the postgresql.conf file) but the response I get is "cannot execute binary file."
Try sudo port load postgresql83-server - this should work with the latest 8.3 port from macports.
If this doesn't work, try sudo port selfupdate; sudo port upgrade outdated and then try again.
Note - this may take absolutely ages.
and may indicate that it is not started?
Yes, sounds like the server is not running on your local machine.
See the description of this error in the PostgreSQL manual:
http://www.postgresql.org/docs/8.3/static/server-start.html#CLIENT-CONNECTION-PROBLEMS
To start the server, try something along the following lines (adjust for pgsql version # and logfile):
sudo su postgres -c '/opt/local/lib/postgresql84/bin/pg_ctl -D /opt/local/var/db/postgresql8/defaultdb -l /opt/local/var/log/postgresql84/postgres.log start'
To stop the server,
sudo su postgres -c '/opt/local/lib/postgresql84/bin/pg_ctl -D /opt/local/var/db/postgresql84/defaultdb stop'