Here is my server modules list (modules.conf), its working without any problems, and lighttpd is running correctly while using this list:
server.modules = (
"mod_access",
# "mod_alias",
# "mod_auth",
# "mod_evasive",
# "mod_redirect",
# "mod_rewrite",
# "mod_setenv",
# "mod_usertrack",
)
The problem appears, when I want to uncomment the mod_rewrite module:
server.modules = (
"mod_access",
# "mod_alias",
# "mod_auth",
# "mod_evasive",
# "mod_redirect",
"mod_rewrite",
# "mod_setenv",
# "mod_usertrack",
)
Then I'm getting the following message, when I want to run my web server:
2012-05-01 15:01:18: (plugin.c.169) dlopen() failed for:
/usr/local/lib/lighttpd/mod_indexfile, mod_access.so Cannot open
"/usr/local/lib/lighttpd/mod_indexfile, mod_access.so"
2012-05-01 15:01:18: (server.c.656) loading plugins finally failed
/usr/local/etc/rc.d/lighttpd: WARNING: failed to start lighttpd
As you can see, it does have some problems with the mod_access module, but its strange a little bit, especially when I comment back the mod_rewrite module then its working.
Where is the problem?
I tried to reproduce this problem with the latest www/lighttpd port (version 1.4.32) and could not... The server starts with the modules.conf as you describe. Try updating to the latest, and if that works for you too, then just chalk it up as a bug of 1.4.30 and move on...
Related
Following Steve Copes "How to install the Mosquitto Broker on Windows", I created a password.txt file and encrypted it using the mosquiito_passwd utility.
Then I edited the mosquitto.conf file by uncommenting allow_anonymous and setting to false, and uncommenting password_file and setting the path of my password.txt file (In the same folder as mosquitto.conf)
Using MQTT Explorer I am able to log into the broker using the credentials in my password.txt file, but I am also able to still log in leaving user and password blank.
I've seen similar questions being asked here, but I can't find any solutions that have worked, please point me in the right direction. I'am using mosquitto 2.0.14 x64 on Windows 10
Edit:
Only edit done to mosquitto.conf is uncommenting the lines as follows:
# acl_file
allow_anonymous false
# allow_zero_length_clientid
# auto_id_prefix
password_file C:\Users\'MyName'\mosquitto\password.txt
# plugin
# plugin_opt_*
# psk_file
Solution Found:
Adding 'listener 1883' before allow_anonymous false has got it working although I am unsure why that makes a difference.
Config file as follows:
# acl_file
listener 1883
allow_anonymous false
# allow_zero_length_clientid
# auto_id_prefix
password_file C:\Users\'MyName'\mosquitto\password.txt
# plugin
# plugin_opt_*
# psk_file
I'm experiencing an unresponsive socket in with my Puma setup after random time. Up to this point I don't have a clue what's causing the issue. I was hoping somebody over here can help we with some answers or point me in the right direction. I'm having the following setup:
I'm using the official docker ruby-2.2.3-slim image together with the latest puma release 2.15.3, I've also installed Nginx as a reverse proxy. But I'm already sure Nginx isn't the problem over here because and I've tried to verify if the socket was working using this script. And the socket wasn't working, I got a timeout over there as well so I could ignore Nginx.
This is a testing environment so the server isn't experiencing any extreme load, I've also check memory consumption it has still several GB's of free space so that couldn't be the issue either.
What triggered me to look at the puma socket was the error message I got in my Nginx error logging:
upstream timed out (110: Connection timed out) while reading response header from upstream
Also I couldn't find anything in the logs of puma indicating what is going wrong, over here are my puma setup:
threads 0, 16
app_dir = ENV.fetch('APP_HOME')
environment ENV['RAILS_ENV']
daemonize
bind "unix://#{app_dir}/sockets/puma.sock"
stdout_redirect "#{app_dir}/log/puma.stdout.log", "#{app_dir}/log/puma.stderr.log", true
pidfile "#{app_dir}/pids/puma.pid"
state_path "#{app_dir}/pids/puma.state"
activate_control_app
on_worker_boot do
require 'active_record'
ActiveRecord::Base.connection.disconnect! rescue ActiveRecord::ConnectionNotEstablished
ActiveRecord::Base.establish_connection(YAML.load_file("#{app_dir}/config/database.yml")[ENV['RAILS_ENV']])
end
And this it the output in my puma state file:
---
pid: 43
config: !ruby/object:Puma::Configuration
cli_options:
conf:
options:
:min_threads: 0
:max_threads: 16
:quiet: false
:debug: false
:binds:
- unix:///APP/sockets/puma.sock
:workers: 1
:daemon: true
:mode: :http
:before_fork: []
:worker_timeout: 60
:worker_boot_timeout: 60
:worker_shutdown_timeout: 30
:environment: staging
:redirect_stdout: "/APP/log/puma.stdout.log"
:redirect_stderr: "/APP/log/puma.stderr.log"
:redirect_append: true
:pidfile: "/APP/pids/puma.pid"
:state: "/APP/pids/puma.state"
:control_url: unix:///tmp/puma-status-1449260516541-37
:config_file: config/puma.rb
:control_url_temp: "/tmp/puma-status-1449260516541-37"
:control_auth_token: cda8879717be7a645ea323d931b88d4b
:tag: APP
The application itself is a Rails app on the latest version 4.2.5, it's deployed on GCE (Google Container Engine).
If somebody could give me some pointer's on how to debug this any further would be very much appreciated. Because now I don't see any output anywhere which could help me any further.
EDIT
I replaced the unix socket with tcp connection to Puma with the same result, still hangs after x time
I'd start with:
How many requests get processed successfully per instance of puma?
Make sure you log the beginning and end of each request with the thread id of the thread executing it, what do you see?
Not knowing more about your application, I'd say it's likely the threads get stuck doing some long/blocking calls without timeouts or spinning on some computation until the whole thread pool gets depleted.
We'll see.
I finally found out why my application was behaving the way it was.
After trying to use a tcp connection and switching to Unicorn I start looking into other possible sources.
That's when I thought maybe my connection to Google Cloud SQL could be the problem. Once I read the faq of Cloud SQL, they mentioned that you have to tweak you Compute instances to ensure they keep open your DB connection. So I performed the next steps they recommend and that solved the problem for me, I added them just in case:
# Display the current tcp_keepalive_time value.
$ cat /proc/sys/net/ipv4/tcp_keepalive_time
# Set tcp_keepalive_time to 60 seconds and make it permanent across reboots.
$ echo 'net.ipv4.tcp_keepalive_time = 60' | sudo tee -a /etc/sysctl.conf
# Apply the change.
$ sudo /sbin/sysctl --load=/etc/sysctl.conf
# Display the tcp_keepalive_time value to verify the change was applied.
$ cat /proc/sys/net/ipv4/tcp_keepalive_time
I am having some problems trying to bootstrap a windows node for Chef. This node was initially able to be partially bootstrapped, it was getting through most of the process but however, failing near the end - on the windows client itself I can see a number of expected files under C:\Chef
However since upgrading my Ruby and Knife-Windows to remedy the original issue - I am now not able to bootstrap at all, I get the error below:
chefadmin#AUK-CHEFMGT1:~$ knife bootstrap windows winrm 10.28.154.61 -x chefadmin -P xxxxxx
/opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/chef-12.5.1/lib/chef/mixin/path_sanity.rb:25:
warning: Insecure world writable dir /usr/local/bin in PATH, mode 040777
Waiting for remote response before bootstrap.10.28.154.61 .
10.28.154.61 Response received.
Remote node responded after 0.01 minutes.
Bootstrapping Chef on 10.28.154.61
ERROR: RuntimeError: Knife-Windows < 1.0 does not support validatorless bootstraps
I've tried a few different versions of knife-windows, initially 1.1.1, and most recently the pre-release version of 1.0.0 rc1, however, they are all giving me this error.
I am not sure why this is a problem, as the validation.pem does exist on the windows client in C:\Chef\
In case it matters, here is my knife.rb config file:
chefadmin#AUK-CHEFMGT1:~$
GNU nano 2.2.6 File: /home/chefadmin/chef-repo/.chef/knife.rb
current_dir = File.dirname(__FILE__)
log_level :info
log_location STDOUT
node_name "chefadmin"
client_key "#{current_dir}/ChefRSA.pem"
validation_client_name "company"
validation_key "#{current_dir}/companyvalidator"
chef_server_url "https://10.28.253.101/organizations/company"
syntax_check_cache_path "#{ENV['HOME']}/.chef/syntaxcache"
cookbook_path ["#{current_dir}/../cookbooks"]
"#{current_dir}/companyvalidator" Does that file exist? Usually that would be something ending in .pem. If that path isn't a thing, it would fall back to new-style bootstrapping which I don't think works on Windows yet.
Following the tutorial, linked below, i've tried to install TurboGears on Heroku using gevent.
http://turbogears.readthedocs.org/en/latest/cookbook/deploy/heroku.html
Can't figure out why, but I get there errors:
ERROR [gearbox] Failed to load application or server: Entry point 'main' not found in egg 'gevent' (dir: /app/.heroku/python/lib/python2.7/site-packages; protocols: paste.server_factory, paste.server_runner; entry_points: ) (--debug to see traceback)
LookupError: Entry point 'main' not found in egg 'gevent' (dir: /app/.heroku/python/lib/python2.7/site-packages; protocols: paste.server_factory, paste.server_runner; entry_points: )
Any idea on how to solve them?
Let me suggest you try this line in your production.ini file and tell us if it works:
[server:main]
use = egg:gearbox#gevent
I am using the ruby daemons gem to create a custom daemon for my rails project. The only problem is that when I try to start the daemons ruby lib/daemons/test_ctl start that it fails and will not start. The log file has this output.
# Logfile created on Wed Oct 22 16:14:23 +0000 2008 by /
*** below you find the most recent exception thrown, this will be likely (but not certainly) the exception that made the application exit abnormally \*\*\*
# MissingSourceFile: no such file to load -- utf8proc_native
*** below you find all exception objects found in memory, some of them may have been thrown in your application, others may just be in memory because they are standard exceptions ***
# NoMemoryError: failed to allocate memory>
# SystemStackError: stack level too deep>
# fatal: exception reentered>
# LoadError: no such file to load -- daemons>
# LoadError: no such file to load -- active_support>
# MissingSourceFile: no such file to load -- lib/string>
# MissingSourceFile: no such file to load -- utf8proc_native>
It even happens when I generate a daemon (from the rails plugin) and try to run it. Does anybody know how to fix this problem?
OK, I actually found the answer to this problem. I require two custom files in the config/environment.rb. I used relative path names and because the daemons are executed in the rails main directory it could not find these two files. after making them absolute path it fixed the problem.
I just spent 30 minutes trying to solve a similar error when trying to get daemons plugin working:
LoadError: no such file to load -- active_support
For some reason, it wasn't finding active_support lib, even though it was installed. (Perhaps due to me having frozen rails).
In my case, the solution to this was to use the absolute path for active_support in my
ctl file (eg lib/daemons/mailer_ctl).
I needed to change line 5 from:
require 'active_support'
to
require './vendor/rails/activesupport/lib/active_support.rb'