/usr/local/bin/bluepill start

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.

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.

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)

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

This is fixed and will be out with the next release.

If you add a STDOUT.flush; after the puts, it works. So it's not a matter of the redirection not working, but the fact that ruby isn't getting a chance to flush it the output.

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.

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.

fixed, will be out with the release of 0.0.24 later today

It now will use the log file location you specify if you're not using syslog, will be out with release of 0.0.25

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 :unmonitored

Hey, 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.

Found the issue you were encountering and fixed it. It'll be out with the release of 0.0.24

I changed it to do KB or MB based on the scale of the value. This will be out with the release of 0.0.24 later today

This ticket is to add a config option to be able to specify whether you want stdout/stderr opened with the File::APPEND.

Changed to always be in append mode.

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

Fixed, will go out with the release of 0.0.24

You're absolutely right, we should have done this from the beginning. I'll do it right now.

It's done, but I haven't published a new version of the gem yet. I'll close some more tickets and push the next version later today.

Can you try it again with version 0.0.20 and let me know what happens?

Resolved via github-messaging, closing ticket.

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?

Negatory on the cause. Asking bluepill to quit and then loading the same config works fine. Will attach send the config over.

I changed the code that waits for the previous process to die, it will wait a bit longer and tell you if it failed to die and exit with a non-zero exit code if the previous process didn't die in time.

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?

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.

Thank you for reporting this. It's fixed in 0.0.19

This is done. Look for it in 0.0.25

Sorry for shortness. Coffee has me moving fast, but looking forward to moving to bluepill from monit. :)

Thanks for reporting it, it's fixed in version 0.0.17

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.

Failing for me too. :(

i also have this problem. get some test coverage in there cowboy!

It's fixed in 0.0.16, thanks for reporting it.

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.

Nice! I'll try the new version!

I just got this message on 0.0.15: http://gist.github.com/228303

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.

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
end

Is 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
end

Ah 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.

Ok, thanks! I'll try this later and update here.

Also be able to configure where pids are being written.