Every repository with this icon (
Every repository with this icon (
| Description: | simple process monitoring tool edit |
-
/usr/local/bin/bluepill start
/usr/local/packages/ruby-1.8.6-p114+gc+sec/lib/ruby/gems/1.8/gems/bluepill-0.0.25/lib/bluepill/controller.rb:69:in `load': marshal data too short (ArgumentError)
from /usr/local/packages/ruby-1.8.6-p114+gc+sec/lib/ruby/gems/1.8/gems/bluepill-0.0.25/lib/bluepill/controller.rb:69:in `send_to_daemon' from /usr/local/packages/ruby-1.8.6-p114+gc+sec/lib/ruby/1.8/timeout.rb:56:in `timeout' from /usr/local/packages/ruby-1.8.6-p114+gc+sec/lib/ruby/gems/1.8/gems/bluepill-0.0.25/lib/bluepill/controller.rb:62:in `send_to_daemon' from /usr/local/packages/ruby-1.8.6-p114+gc+sec/lib/ruby/gems/1.8/gems/bluepill-0.0.25/lib/bluepill/controller.rb:25:in `handle_command' from /usr/local/packages/ruby-1.8.6-p114+gc+sec/lib/ruby/gems/1.8/gems/bluepill-0.0.25/bin/bluepill:99 from /usr/local/bin/bluepill:19:in `load' from /usr/local/bin/bluepill:19Comments
-
5 comments Created 26 days ago by amcabluepill stop reports OK even though nothing happensaryaxIn some cases (still couldn't pin point exactly in which situations this happens) when I do "sudo bluepill appname stop groupname" it reports "ok" but the processes' status doesn't change from up and nothing is logged in bluepill's log.
Comments
entombedvirus
Wed Nov 25 23:08:06 -0800 2009
| link
If there are no messages in the log about the stop_command returning a non-zero exit code, then that means Bluepill executed the stop command (and that was successful) but the stop command failed to actually stop the daemon.
Could you verify that when you run the stop command manually (after sudo -s to the appropriate user) the process dies?
When I run the stop command manually the process dies. Bluepill detects it and restarts it.
entombedvirus
Thu Nov 26 10:15:55 -0800 2009
| link
interesting. Would you mind posting up your bluepill config?
Here you go: http://gist.github.com/244197
This is a pill I generate I runtime. I use an erb template which is replaced by that yaml.
entombedvirus
Fri Nov 27 13:09:09 -0800 2009
| link
Awesome. Found the issue. The problem was that bluepill was getting confused by group for the monitored processes being set to a symbol instead of a string. This will be fixed in v0.0.25. You can workaround the bug in the meantime by simply setting the group to "shiro" instead of ":shiro"
On a related note, since you correctly set the "working_dir" for the processes, you do not need to have "cd /Users/tonio/workspace/esper/" in the start_command. In fact, you should remove that so that bluepill will monitor the jruby process instead of the shell that spawned it. (we're going to have a blog entry detailing the best practices for specifying start command soon)
-
2 comments Created 26 days ago by amcaaryaxbluepill stop <group>:<proc> times out and server stops respondingbugxUsing the bluepill conf in , if you do "sudo bluepill testapp stop group:proc1" it responds after a few seconds with a socket exception.
After that, any command, even a simple "sudo bluepill testapp status", responds with a socket timeout.
Comments
Ah yes, you can't currently target like that (group:proc). But both are things we should fix: it's a bug that it hangs when it doesn't find the target, and we should add the ability to target by group:proc. As a workaround for now, use the proc name only
-
When I load bluepill with the pill shown in http://gist.github.com/242643 it creates the application log (log1.txt) and logs bluepill messages to it and also creates the process log (log2.txt) but nothing is written to it.
Comments
-
2 comments Created 27 days ago by blakewattersSocket Timeout Message - Long Grace Time?bugxI have Bluepill monitoring a Rails app in production. The app is fairly large and extremely heavy -- healthy processes run at around 225-250MB each. There are a large number of models and the app takes quite awhile to start up. The start and restart grace time is set to 2 minutes currently. I am noticing the restart commands are often throwing "Socket Timeout: Server may not be responding". I have upped the Grace time recently but also updated to Bluepill 0.0.24 over the same interval.
Maybe these items are related? Or there is an internal timeout that needs more padding for apps like mine? Is there a config option I should be tweaking?
Comments
Hi Blakewatters, what is your start command? I think the issue is caused by the fact that the start command is blocking. The grace time should not be perceived as the time it takes for the start command to execute, but the time before the process is ready to be monitored after the start command is executed.
Is your start command taking 2 minutes to run before it returns (i.e. daemonizes?) If so, that could be the problem. Some more details on your config will shed some light on the cause.
The reason the restart command times out is because the restart command waits until the command you asked for returns, which should be fast and different from the grace time.
blakewatters
Mon Dec 07 12:13:02 -0800 2009
| link
Hey there. Thanks for the pointers -- I found a bug in the process that was preventing it from daemonizing under some conditions. I have just deployed without issue.
-
1 comment Created 27 days ago by blakewattersBluepill can't handle empty PID filesbugxIt treats the file as having a PID of zero and attempts to monitor the process. Any attempt to restart the process causes the bluepill daemon to quit abruptly. It should really by treating the empty file as a dead process and attempting to start it at launch.
Comments
-
1 comment Created 27 days ago by jsierles'bluepill log' always looks for /var/log/bluepill.logbugxWhether or not a logfile is specified for an application, 'bluepill log' always looks there. It would be useful to be able to specify the logfile for an application (log_file option) or a process (stdout/stderr file).
Comments
-
$ uname -a Linux Dev001.vibeagent.com 2.6.9-67.0.7.ELsmp #1 SMP Sat Mar 15 06:54:55 EDT 2008 i686 i686 i386 GNU/Linux
After sudo bluepill load, bp fires up its watches... and then dies, leaving them alone in the cold dark of userspace. Bluepill goes quietly into that good night, issuing nary a "bye"...
Comments
oops - not quite right -- here's what it logs: Nov 24 02:12:42 Dev001 bluepilld[12805]: [mcp] Got exception: StateMachine::InvalidTransition
Cannot transition state via :restart from :unmonitoredHey, can you send over your config? We're using it on CentOS so I don't think it's a centos issue. If you gist your config, it'll help track down the issue.
Here it is: http://gist.github.com/241920
FIXED :)
There may in fact be a bug floating around there (unhandled state transition?) but I managed to modify my config so that things start and bluepill stays up.
-
default mem_usage value display in process log to MB rather than KB
1 comment Created 28 days ago by jsierles -
2 comments Created 28 days ago by jsierlesProcess stderr/stdout file truncated on restartfeaturexA process log file should be appended to rather than truncated
Comments
-
2 comments Created 28 days ago by jsierlesaryaxMore accurate memory measurements on linux via /procfeaturexThis technique is used by Phusion Passenger to determine the actual private, dirty RSS usage of a process (sometimes rather different from the RSS in ps output)
Example here: http://gist.github.com/208619
A drawback is that is requires running as root.
Comments
The additional drawback is that we'd have to probe multiple files (one for each pid) on each tick. The current implementation caches the output of ps per tick so that we only run ps once and have the memory and cpu usage for all processes for that tick. But even at that, if you wanted to use the proc, all you would have to do is add this to your config file: http://gist.github.com/242053 (I didn't actually test this, but it gives you the general idea) and use process.checks :proc_mem_usage to use that version.
Added wiki page for creating your own watch: http://wiki.github.com/arya/bluepill/creating-your-own-process-condition
-
display usage when run with no arguments, not just with --help
1 comment Created 28 days ago by jsierles -
2 comments Created 29 days ago by jsierles--help or simply typing 'bluepill' should display CLI usagefeaturexThis would be helpful for learning which commands and options are available on the command line.
Comments
You're absolutely right, we should have done this from the beginning. I'll do it right now.
-
2 comments Created about 1 month ago by supairishAlways seeing a pid of 0, and script never starts, though bluepill says its runningbugxCan't seem to get working... I'm using gem version 0.0.19
I've followed the readme and created a bluepill.pill config file containing:
Bluepill.application("max") do |app|
app.process("alis_scraper") do |process|process.start_command = "RAILS_ENV=production /home/deploy/apps/max/current/script/runner lib/alis_scraper.rb" process.pid_file = "/tmp/bluepill.pid" process.daemonize = true process.start_grace_time = 5.seconds process.stop_grace_time = 5.seconds process.restart_grace_time = 5.seconds process.checks :mem_usage, :every => 10.seconds, :below => 100.megabytes, :times => [3,5]end end
After loading the config, if I use the status command I always see this:
alis_scraper(pid:0): uppid: 0 doesn't seem right
And I don't see the script running, am I making a dumb mistake here somewhere?
Is the script suppose to start when the config is loaded? Or do you always have to call sudo bluepill start <process_or_group_name>?
I've tried both ways.
Any insight would be greatly appreciated, thanks! :-)
Comments
-
3 comments Created about 1 month ago by blakewattersUsing bluepill load while already running results in no daemonbugxIf I ask bluepill to load an existing configuration file, it tells me that it is killing the old bluepill daemon but fails to fork a new one.
Comments
This is caused by the second config failing to load and exiting. Can you add your config file to the ticket so we can track it down?
blakewatters
Thu Nov 12 20:01:57 -0800 2009
| link
Negatory on the cause. Asking bluepill to quit and then loading the same config works fine. Will attach send the config over.
-
4 comments Created about 1 month ago by blakewattersException when System.execute_blocking doesn't return an exit codebugxSeeing this when Bluepill tries to work with Backgroundrb:
Nov 12 20:40:28 localhost bluepilld[10253]: [strategy_nets] /usr/lib64/ruby/gems/1.8/gems/bluepill-0.0.18/bin/../lib/bluepill/process.rb:256:in
stop_process'<br/> Nov 12 20:40:28 localhost bluepilld[10253]: [strategy_nets] /usr/lib64/ruby/gems/1.8/gems/bluepill-0.0.18/bin/../lib/bluepill/process.rb:286:inrestart_process'The affected line of code: unless result[:exit_code].zero?
Comments
Can you be more descriptive on how you reproduce this? What is the start/stop/restart command you set for backgroundrb? Is the command failing?
Any updates on this? Was it just that backgroundrb was returning a non-zero exit code?
twotoasters
Fri Nov 27 06:59:18 -0800 2009
| link
Sorry, I had missed your original reply. From looking through the code, the stop doesn't have an explicit exit status. The start and restart code paths have explicit calls to exit(0) and exit(-1)
If it doesn't have an explicit exit code, then it should be 0. Either way, non-zero exit codes are only logged in order to let you know why a command may have failed.
If backgroundrb is returning a non-zero exit code in a non-error state, that might be a bug.
-
1 comment Created about 1 month ago by blakewattersBluepill should exit with non-zero status appropriatelybugxWhen the app logs the message "There are no running bluepill daemons", it should result in a non-zero exit status. I am using Bluepill as part of my Rails application deployment and noticed that the daemon not running wasn't resulting in error conditions.
Comments
-
1 comment Created about 1 month ago by aryafeaturexAdd support for not specifying a pid filerohithxIf the config does not specify a pid file and the process is daemonized by bluepill, bluepill can store the PID file itself based on group and name.
Comments
entombedvirus
Wed Nov 25 22:37:52 -0800 2009
| link
This is done. Look for it in 0.0.25
-
Encountered the error here: http://gist.github.com/228334
Committed fix here: http://github.com/krobertson/bluepill/commit/ef93feef89f9b9463f2157014942032c413da596
Comments
krobertson
Fri Nov 06 14:13:59 -0800 2009
| link
Sorry for shortness. Coffee has me moving fast, but looking forward to moving to bluepill from monit. :)
-
4 comments Created about 1 month ago by shanesveller[Bug] Bluepill command fails to load a configuration filebugxWhen using bluepill gem version 0.0.15 on Debian 5.0 amd64 with Ruby Enterprise Edition 2009.10, the bluepill command fails to load a configuration file and start a daemon. Please see the gist below for more information.
Comments
krobertson
Fri Nov 06 13:35:37 -0800 2009
| link
I just had the same thing. The issue is here: http://github.com/arya/bluepill/commit/3d833ed80ddb32a750270c969f60bcfcb1af0132#bin/bluepill-P17
I removed that block and was able to have it load the configuration then, but then ran into another issue.
i also have this problem. get some test coverage in there cowboy!
-
I'm getting a lot of these errors when trying the CLI commands.
Some examples: http://pastie.org/686388
I get the same errors with both Ruby 1.8.6 and Ruby 1.9.1
Comments
The problem was that there are multiple socket files (for different applications) for bluepill in the sock directory. Typically it will pick the app for you if there is only one, but if there are multiple, it errored out instead of giving you a meaningful error message. It's fixed in the just recently released 0.0.15.
lucashungaro
Fri Nov 06 12:40:43 -0800 2009
| link
Nice! I'll try the new version!
krobertson
Fri Nov 06 13:32:17 -0800 2009
| link
I just got this message on 0.0.15: http://gist.github.com/228303
krobertson
Fri Nov 06 13:53:02 -0800 2009
| link
I found this is because I was having bluepill daemonize the process for me and didn't specify a pid file. Since the examples in the readme for daemonizing show it not setting a pid file, I assumed it handled that. If I set a pidfile for the process, then it worked. Perhaps when daemonizing and no pidfile is set, it chooses one... or throws an error.
lucashungaro
Fri Nov 06 13:59:01 -0800 2009
| link
Good call!
I'm not using pid files 'cause I thought that bluepill would handle the pid files automatically.
Also, I'm setting up a group of processes. The example on the README looks like the following:
Bluepill.application("app_name") do |app| 5.times do |i| app.process("process_name_#{i}") do |process| process.group = "mongrels" process.start_command = "/usr/bin/some_start_command" process.pid_file = "/tmp/some_pid_file.pid" end end endIs it right or I'm better off setting different pid files too, like the following:
Bluepill.application("app_name") do |app| 5.times do |i| app.process("process_name_#{i}") do |process| process.group = "mongrels" process.start_command = "/usr/bin/some_start_command" process.pid_file = "/tmp/some_pid_file_#{i}.pid" end end endAh yes, bluepill doesn't actually pick a PID file for you yet. The readme is erroneous. I think we'll probably add choosing a PID file for you in a later version.
@lucashungaro You'll want to do the second way for now, until we add support for picking the PID file for you.
lucashungaro
Fri Nov 06 15:18:00 -0800 2009
| link
Ok, thanks! I'll try this later and update here.
-
0 comments Created about 1 month ago by aryaapp-wide options for uid/gid/working_dirfeaturexallow config file to specify uid/gid/working_dir as an app-wide setting that gets used as defaults for every process under that application.
Comments
-
1 comment Created about 1 month ago by aryaallow user to specify log file instead of using syslogfeaturex -
add validations to the DSL so that it throws an error for some of the easy error states:
two processes with the same PID file two processes with same name * missing configuration optionsComments
-
0 comments Created about 1 month ago by aryaaryaxCLI can cause main process to hangbugxIf there is an error in handling of a CLI command, the listener thread will exit and the CLI will be unresponsive. Need to make the CLI loop more robust.
Comments












This could happen if your daemon is older than the CLI version. We should add a check to make sure the daemon version and CLI version are the same, or at least compatible. We changed the way the CLI and daemon communicate in 0.0.25 so a daemon of < 0.0.24 is incompatible with a CLI of version >= 0.0.25. Let me know if restarting your daemon with the new version of bluepill fixes it.
This still happens with only 0.0.25 installed, and only when i type a command without an app name argument like:
bluepill stop
Has the running bluepill daemon been restarted? Try:
Yes i restarted many times and made sure it was the right one.
I just pushed 0.0.26 to gemcutter. Try installing that, I added an error message when you don't specify a target.
I added support for running target-less commands that affects all processes. I also added support for checking daemon vs CLI versions. This is available in version 0.0.27. Please let me know if this fixes the issues you were encountering so I can close the ticket.
This version looks good!