==> /etc/openresty/nginx/logs/error.log <==
2016/08/07 02:31:26 [error] 194#0: [lua] start_sockproc.lua:9: auto-ssl: failed to start sockproc, context: init_worker_by_lua*
I get the aforementioned error after my Nginx instance starts.. Don't know what could be causing it..
It appears I may be missing a dependency is that CORRECT.
Here is the Docker image repo, with more information on how I have set things up.
Also, I noticed that sockproc is actually running.. See the images below.
That error appears to come from here which looks to mean that auto-ssl/shell/start_sockproc failed to start.
start_sockproc ends by running sockproc.
So presumably that failed. Given that that doesn't ship with lua-resty-auto-ssl my guess would be that you need to get that (or install it at least).
Related
I downloaded urbit and am attempting to boot my ship for the first time. In following the instructions online, I ran the following command:
./urbit -w sampel-palnet -k path/to/my-planet.key
The script progressed until this line:
boot: downloading pill https://bootstrap.urbit.org/urbit-v0.10.4.pill
After some time, I received the error in the title of this question.
Does anyone know what the error means and what I can do to resolve it?
Have you tried checking this issue on Github. It's not exactly the same error as yours, but it's similar, so maybe it could be related.
Did you also check the Urbit Docs.
If none of this works I would recommend you create an issue in Urbit's Github page.
I am trying to generate a new genesis-block in Hyperledger Iroha as it is suggested in
https://iroha.readthedocs.io/en/latest/getting_started/index.html#starting-iroha-node
and
https://hyperledger.github.io/iroha-api/#create-genesis-block
but unfortunately I can't do it because I am always getting the same error message.
$ cat peer.list
localhost:10001
$ ./iroha-cli --genesis_block --peers_address peer.list
terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::out_of_range> >'
what(): bimap<>: invalid key
Aborted (core dumped)
I am receiving this error both on my local machine where I had compiled Iroha from scratch using the source code, as well as within an Iroha container.
I think I have the correct dependencies, otherwise I would have not been able to build Iroha from scratch. Also, note that I can start irohad correctly by using the configuration example from https://iroha.readthedocs.io/en/latest/getting_started/index.html#launching-iroha-daemon.
Any help or suggestion is greatly appreciated.
There was, indeed, a bug affecting the permissions needed to generate a block. It is fixed now and should not occur: https://github.com/hyperledger/iroha/pull/1351
This is a known issue in the development of hyperledger iroha, see here: https://github.com/hyperledger/iroha/issues/1362.
It arises when iroha is compiled with Ansible Playbook.
Try to uninstall Ansible from your system and re-compile iroha and you shouldn't encounter the same error.
Obviously this is just a work around, and you won't be able to take advantage of the ansible capabilities.
I have a unit test that calls LSOF to get the number of open file handles. It runs fine on my machine, but on Travis builds (such as this one) I get this warning:
lsof: WARNING: can't stat() vmhgfs file system /Volumes/VMware Shared Folders
Output information may be incomplete.
assuming "dev=2d000003" from mount table
I did some searching, and it looks like the fix is to add this line to the advanced settings (or vmx file) for the machine's image:
isolation.tools.hgfs.disable=TRUE
Could someone please take a look at adding this?
Just ran into similar issue - https://superuser.com/questions/1082701/osx-on-vmplayer-running-on-windows-10-smb-shared-files-keep-getting-resource
Tried isolation.tools.hgfs.disable=TRUE. Sharing seems to be still enabled, but the problem persists.
I'm installing Dspace in Windows 7 and I got it working fine with me until I got this error message:
I tried doing what the link :build failed .. creation was not successful for an unknown reason has said, but still nothing's change. Does anyone know how to fix it?
Check dspace.install.dir at build.properties, it seems to have a bad value.
Change the value to the location you want to install and use "/" character to the directory. For example C:/Program Files/Dspace.
I have restarted Jenkins using the following:
service jenkins stop
service jenkins start
Followed to that I can see some jobs are missing from the GUI.
I have also tried to go the job URL using http://<jenkins_url>/job/<JOBNAME>/
Unfortunately it is also giving:
HTTP ERROR 404
Problem accessing /job/<JOBNAME>/. Reason:
Not Found
Powered by Jetty://
Also performed Doing a Reload Configuration from Disk with no luck.
I checked the config.xml file and I can see it is corrupted. The size of config.xml file is around 110 MB. Why this file got corrupted? How to trace it.
Can anyone give me any pointer how to troubleshoot this problem?
I had the same symptoms, but I'm using a homebrew installation of Jenkins.
The Jenkins machine was shut down improperly, likely from a power outage, so when it came back up it was basically a clean instance. No jobs and no system configurations.
The following solution isn't for your exact use case, but it does solve the problem for some users who return to Jenkins to find it without any jobs.
The solution basically involves you checking to see if you have started the Jenkins service incorrectly or from the wrong place.
...
On to the specific homebrew issue:
For whatever reason, the homebrew.mxcl.jenkins.plist file was found in ~/Library/LaunchDaemons/
It belongs in ~/Library/LaunchAgents/ only.
If this happens, it can be solved as follows
Stop the service:
sudo launchctl unload ~/Library/LaunchDaemons/homebrew.mxcl.jenkins.plist
Reload the correct file, located in ~/Library/LaunchAgents/ by trying the following line in case it's running:
launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.jenkins.plist
Note: the above line may yell at you if it's not running, which is ok.
Start it up again:
launchctl load ~/Library/LaunchAgents/homebrew.mxcl.jenkins.plist
If all looks good when Jenkins loads again, you can and should
delete homebrew.mxcl.jenkins.plist in ~/Library/LaunchDaemons/:
sudo rm ~/Library/LaunchDaemons/homebrew.mxcl.jenkins.plist