I deploy my django project with uwsgi、supervisor and nginx.
but I have added my program like above in the /etc/supervisord.conf.
[program:JZAssist]
command=-E uwsgi --ini /home/work/xxxx/uwsgi.ini
directory=/home/work/xxxx
startsecs=0
stopwaitsecs=0
autostart=true
autorestart=true
and my uwsgi.ini content is:
[uwsgi]
socket = :8000
chdir = /home/work/xxxx
module = xxxx.wsgi
master = true
processes = 4
vacuum = true
xxxx is my project name.
I run supervisorctl -c /etc/supervisord.conf restart all in the cmd.
And it shows
xxxx: ERROR (no such file)
/tmp/supervisord.log part of content:
2017-02-24 23:31:41,433 INFO gave up: JZAssist entered FATAL state, too many start retries too quickly
2017-02-24 23:52:29,940 WARN Failed to clean up '/tmp/JZAssist-stderr---supervisor-goPZyS.log'
2017-02-24 23:52:29,940 WARN Failed to clean up '/tmp/JZAssist-stdout---supervisor-WtfJcp.log'
2017-02-24 23:52:57,535 WARN Failed to clean up '/tmp/JZAssist-stderr---supervisor-goPZyS.log'
2017-02-24 23:52:57,535 WARN Failed to clean up '/tmp/JZAssist-stdout---supervisor-WtfJcp.log'
2017-02-24 23:52:57,541 INFO RPC interface 'supervisor' initialized
2017-02-24 23:52:57,541 CRIT Server 'unix_http_server' running without any HTTP authentication checking
2017-02-24 23:52:57,542 INFO daemonizing the supervisord process
2017-02-24 23:52:57,543 CRIT could not write pidfile /tmp/supervisord.pid
2017-02-24 23:52:58,544 INFO spawnerr: can't find command '-E'
2017-02-24 23:52:59,546 INFO spawnerr: can't find command '-E'
2017-02-25 00:46:59,234 WARN Failed to clean up '/tmp/JZAssist-stderr---supervisor-goPZyS.log'
2017-02-25 00:46:59,234 WARN Failed to clean up '/tmp/JZAssist-stdout---supervisor-WtfJcp.log'
I don't know why it will report error like that.I can run my django project with runserver.so what the file is missing?
On your command= line, you've specified the program to run as -E, which supervisor can't find to execute.
When creating a file for the job, the command line should be executable as a shell command, and should not rely on internal commands for a given shell. For example, I had trouble with one that started with:
source /path/to/python/virtual/environment/bin/activate && ...
but source is a bash builtin. I needed to change it to read:
bash -c 'source /path/to/python/virtual/environment/bin/activate && ...
This way, the executable file that supervisor can find and run is bash.
In your case, it appears uwsgi should be the first thing after command=.
You mentioned that you're using the -E flag to preserve environment variables when you run sudo, but supervisor won't need sudo
I ran into this error message, but in my case it turned out I'd specified a user in my job definition that hadn't been created on the server.
[program:my-task]
user=this-user-didnt-exist
In my case, the problem was that I had command="/bin/python3.8 main.py" in my conf.d/mysite.conf file.
When i removed the "", it worked.
Related
After pruning with the command "docker system prune -a" nodejs wont build anymore beacuse trix.css is missing. I am assuming this was probably deleted while pruning. How can I resolve this error (see the error below)? Why is it not created again while building the container again since the file is in the docker file.
Required path doesn't exist: /code/bower_components/trix/dist/trix.css trix
[13:57:39] 'vendorcss' errored after 1.63 ms
[13:57:39] Error: Promise rejected without Error
at Domain.onError (/usr/local/lib/node_modules/gulp/node_modules/async-done/index.js:49:15)
at Object.onceWrapper (events.js:315:30)
at emitOne (events.js:116:13)
at Domain.emit (events.js:211:7)
at Domain._errorHandler (domain.js:134:21)
at process._fatalException (bootstrap_node.js:375:33)
[13:57:39] 'staging' errored after 41 ms
ERROR: Service 'nodejs' failed to build: The command '/bin/sh -c gulp staging' returned a non-
zero code: 1
Usually I use this command : "sudo docker-compose -f docker-compose-staging.yml build nodejs" when I want to build the container again. I am very new to this and would be greatfull for some help.
For me, this was the case:
The issue exists because trix.css was removed in the latest version. It has nothing to do with docker system prune as far as I understand.
You can compare the two versions here: https://github.com/basecamp/trix/compare/1.3.1...v2.0.0
Basically, in order to fix this issue, you need to do
yarn install
yarn build
inside bower_components. This is suggested in the official updated README of the trix repository: https://github.com/basecamp/trix.
Once done with that, you will have trix.css and trix.umd.min.js files for your perusal.
On running command solana-test-validator on windows system, getting an error
[2022-01-06T06:54:41.602352800Z INFO solana_test_validator] solana-validator 1.9.0 (src:7782d34b; feat:378846963)
[2022-01-06T06:54:41.602479300Z INFO solana_test_validator] Starting validator with: ArgsOs {
inner: [
"solana-test-validator",
],
}
[2022-01-06T06:54:41.602617400Z WARN solana_perf] CUDA is disabled
[2022-01-06T06:54:41.602720300Z INFO solana_perf] AVX detected
[2022-01-06T06:54:41.602823600Z INFO solana_perf] AVX2 detected
[2022-01-06T06:54:41.606436300Z INFO solana_faucet::faucet] Faucet started. Listening on: 0.0.0.0:9900
[2022-01-06T06:54:41.606635600Z INFO solana_faucet::faucet] Faucet account address: 2P4mpwfirxqrL3naJD7C5UHYynPgVugaRu9sBT6m73EZ
Ledger location: test-ledger
Log: test-ledger\validator.log
⠁
⠉ Initializing...
[2022-01-06T06:54:44.975790700Z INFO solana_ledger::blockstore] "test-ledger\\rocksdb" open took 3.3s
[2022-01-06T06:54:44.981740300Z INFO solana_metrics::metrics] metrics disabled: SOLANA_METRICS_CONFIG: environment variable not found
[2022-01-06T06:54:44.982273700Z INFO solana_metrics::metrics] datapoint: shred_insert_is_full total_time_ms=0i slot=0i ⠒ Initializing...
[2022-01-06T06:54:45.595853800Z ERROR solana_ledger::blockstore] tar stdout:
[2022-01-06T06:54:45.596099200Z ERROR solana_ledger::blockstore] tar stderr: tar: Can't launch external program: bzip2
Error: failed to start validator: Failed to create ledger at test-ledger: blockstore error```
This is a current annoyance with natively using Windows with solana-test-validator. It shells out to tar with bzip2, which isn't available in the default Windows shell.
As a workaround, try installing Git BASH and then running solana-test-validator from a Git BASH shell.
Source code for the issue can be found at: https://github.com/solana-labs/solana/blob/f1e2598baa80a0ad4e8450c8b5e3c5ab164f501c/ledger/src/blockstore.rs#L3789-L3814 -- the j flag indicates to use bzip2
I am building tensorflow-server from source code, refer to doc, but it was failed.
My environment:
Linux 3.10.0-1062.12.1.el7.x86_64
Docker 19.03.8
Build command:
docker build --pull -t $USER/tensorflow-serving-devel -f tensorflow_serving/tools/docker/Dockerfile.devel
Error output:
ERROR: /root/.cache/bazel/_bazel_root/e53bbb0b0da4e26d24b415310219b953/external/upb/BUILD:57:1: C++ compilation of rule '#upb//:upb' failed (Exit 1)
external/upb/upb/table.c: In function 'upb_inttable_pop':
external/upb/upb/table.c:588:10: error: 'val.val' may be used uninitialized in this function [-Werror=maybe-uninitialized]
return val;
^~~
cc1: all warnings being treated as errors
Target //tensorflow_serving/model_servers:tensorflow_model_server failed to build
INFO: Elapsed time: 592.958s, Critical Path: 122.61s
INFO: 3550 processes: 3550 local.
FAILED: Build did NOT complete successfully
I've also faced this error when building latest version of Tensorflow Serving container. Looks like particular bazel version causes the error. I have found discussion under one of recent tensorflow serving updates - https://github.com/tensorflow/serving/commit/162f72949c6ecbe9e610182c923dec0aa5924cf2. I tried workaround suggested there, changing Tensorflow Serving branch from master to r2.1 by passing argument to docker build in such a way --build-arg TF_SERVING_VERSION_GIT_BRANCH=r2.1, it helped.
I have a problem running the standard C++ API example:
https://www.tensorflow.org/api_guides/cc/guide
I created all the files and directories. Bazel then throws an error after being started.
INFO: From Compiling external/snappy/snappy-sinksource.cc [for host]:
cc1plus: warning: command line option '-Wno-implicit-function-declaration' is valid for C/ObjC but not for C++
ERROR: /home/[...]/tensorflow/tensorflow/core/BUILD:1796:1: Executing genrule //tensorflow/core:version_info_gen failed (Exit 127): bash failed: error executing command
(cd /home/[...]/.cache/bazel/_bazel_[...]/[...]/org_tensorflow && \
exec env - \
LD_LIBRARY_PATH=/opt/ros/lunar/lib \
PATH=/opt/ros/lunar/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games \
/bin/bash -c 'source external/bazel_tools/tools/genrule/genrule-setup.sh; tensorflow/tools/git/gen_git_source.py --generate external/local_config_git/gen/spec.json external/local_config_git/gen/head external/local_config_git/gen/branch_ref "bazel-out/host/genfiles/tensorflow/core/util/version_info.cc"')
/usr/bin/env: 'python\r': No such file or directory
Target //tensorflow/cc/example:example failed to build
INFO: Elapsed time: 2.329s, Critical Path: 0.57s
FAILED: Build did NOT complete successfully
ERROR: Build failed. Not running target
My system is running Debian. It looks like there is an issue with the line ending, but I could not really find anything. Shouldn't work the examples under Linux systems by default?
Or did I misconfigure bazel somehow?
After running dos2unix on all files in the tensorflow directory, compilation works. I think this is really weird. Shouldn't tf be supposed to run out of the box in a Unix system? Anyway, refer
How can I run dos2unix on an entire directory?
to run dos2unix recursively.
I got the same error Build failed. Not running target when trying to follow their guide. For me the problem was solved by explicitly compiling Tensorflow with bazel before compiling and running the example.cc file. I.e. :
./configure
bazel build //tensorflow:libtensorflow_cc.so
bazel run -c opt //tensorflow/cc/example:example
I'm getting some very unusual behaviour.
I followed these instructions for installing jetty but used the latest version instead (9.1.1v20140108)
I had reason to restart Jetty and found I was getting these errors (logged in as root)
Starting Jetty: FAILED Wed Feb 5 12:35:59 EST 2014
So I spent 30 mins looking for an answer, then for reasons I can't recall, I did service jetty check and it was running (had a pid).
So I tried again with service Jetty stop:
root#erp:/var/log# service jetty stop
/etc/init.d/jetty: line 13: chkconfig:: command not found
/etc/init.d/jetty: line 14: description:: command not found
/etc/init.d/jetty: line 15: processname:: command not found
Stopping Jetty: start-stop-daemon: warning: failed to kill 7817: No such process
1 pids were not killed
No process in pidfile '/var/run/jetty.pid' found running; none killed.
OK
None killed? Ok. Let's check that:
root#erp:/var/log# service jetty check
/etc/init.d/jetty: line 13: chkconfig:: command not found
/etc/init.d/jetty: line 14: description:: command not found
/etc/init.d/jetty: line 15: processname:: command not found
Checking arguments to Jetty:
START_INI = /srv/jetty/start.ini
JETTY_HOME = /srv/jetty
JETTY_BASE = /srv/jetty
JETTY_CONF = /srv/jetty/etc/jetty.conf
JETTY_PID = /var/run/jetty.pid
JETTY_START = /srv/jetty/start.jar
JETTY_LOGS = /srv/jetty/logs
CLASSPATH =
JAVA = /usr/bin/java
JAVA_OPTIONS = -Dsolr.solr.home=/srv/solr -Djetty.state=/srv/jetty/jetty.state -Djetty.logs=/srv/jetty/logs -Djetty.home=/srv/jetty -Djetty.base=/srv/jetty -Djava.io.tmpdir=/tmp
JETTY_ARGS = jetty.port=8085 jetty-logging.xml jetty-started.xml
RUN_CMD = /usr/bin/java -Dsolr.solr.home=/srv/solr -Djetty.state=/srv/jetty/jetty.state -Djetty.logs=/srv/jetty/logs -Djetty.home=/srv/jetty -Djetty.base=/srv/jetty -Djava.io.tmpdir=/tmp -jar /srv/jetty/start.jar jetty.port=8085 jetty-logging.xml jetty-started.xml
No PID? Let's check that:
root#erp:/var/log# service jetty start
/etc/init.d/jetty: line 13: chkconfig:: command not found
/etc/init.d/jetty: line 14: description:: command not found
/etc/init.d/jetty: line 15: processname:: command not found
Starting Jetty: FAILED Wed Feb 5 12:39:43 EST 2014
Ok, is there a PID?
root#erp:/var/log# service jetty check
/etc/init.d/jetty: line 13: chkconfig:: command not found
/etc/init.d/jetty: line 14: description:: command not found
/etc/init.d/jetty: line 15: processname:: command not found
Checking arguments to Jetty:
[edit]
Jetty running pid=7993
Weird. Sure enough, a stop and check will give the same results.
What's going on with the jetty startup script? And why am I getting FAILED errors on start which are incorrect, and fail to remove pid errors on stop which are also incorrect?
I have got a fix for all those who have been using that tutorial to install jetty
nano /etc/init.d/jetty
And change this syntax :
start-log-file="$JETTY_LOGS/start.log"
to
start-log-file="start.log"
It will fix everything in the latest jetty build and make it run like a charm.
Hope I could be of help
Ok, so this was a tricky one that was the result of a recent Java update.
I jumped into the jetty.sh at /etc/init.d/jetty and grabbed out the actually executed line:
$ /usr/bin/java -Dsolr.solr.home=/srv/solr -Djetty.state=/srv/jetty/jetty.state \
-Djetty.logs=/srv/jetty/logs -Djetty.home=/srv/jetty -Djetty.base=/srv/jetty \
-Djava.io.tmpdir=/tmp -jar /srv/jetty/start.jar jetty.port=8085 \
jetty-logging.xml jetty-started.xml
and I got this:
java.io.IOException: Cannot read file: modules/npn/npn-1.7.0_51.mod
at org.eclipse.jetty.start.Modules.registerModule(Modules.java:405)
at org.eclipse.jetty.start.Modules.registerAll(Modules.java:395)
at org.eclipse.jetty.start.Main.processCommandLine(Main.java:561)
at org.eclipse.jetty.start.Main.main(Main.java:102)
Which in turn lead me to this solution on the eclipse dev list:
$ cp /srv/jetty/modules/npn/npn-1.7.0_45.mod /srv/jetty/modules/npn/npn-1.7.0_51.mod
$ chown jetty:jetty /srv/jetty/modules/npn/npn-1.7.0_51.mod
Sure enough, Jetty restarted without hassle.
Try running below command in terminal.
sudo service jetty9 stop
I run Jetty 9.2.10.v201503 on pcDuino v3, Ubuntu 14.04. According to my experience with this relatively slow platform, this message may be reported when Jetty server itself starts longer than internal waiting loop in /etc/init.d/jetty script expects.
After adding “set –x” at the beginning of /etc/init.d/jetty file and running that script I noticed that internal waiting loop is implemented as “for” making 15 steps and periodically checking content of the $JETTY_BASE/jetty.state file.
After waiting additional couple of seconds, Jetty server is up and running ok, no errors/warrnings in log files.