Hi @adamcooke

First of all, thank you for Procodile.
I have a question: can I somehow use my own logger instead of just storing logs in procodile.log? Without monkeypatching or forking the repository.

I've been researching quite a bit on running Rails/Sinatra in production and seen the recommended approach is to start the app servers as services (under systemd or runit) and go from there.

Then I stumbled upon the post on "Running Ruby Apps in Production" and this. So I was wondering, is it recommended to run procodile vs. systemd in production?

The only downside I see here is the inability to use it as an init process, meaning make it so it starts the programs at startup (in case the server restarts).

Following is some describe.

when i first use procodile, i try to get help message like this

 ╰─ $ procodile -h
Usage: procodile -h [options]
    -r, --root PATH                  The path to the root of your application
        --procfile PATH              The path to the Procfile (defaults to: Procfile)

Okay, because i use procodile only on development laptop, so, i use one separated
file, Procfile.dev, so, i try like this.

 ╰─ $ 1  procodile --procfile Procfile.dev start
Error: Invalid command '--procfile'

I know it working when reverse order.

 ╰─ $ procodile start --procfile Procfile.dev
No processes to start.

But, the first help message, make me belive --procodile Procfile.dev should be a global
option, so, i can wrap procodile into a bash script like this:

#!/bin/bash

procodile --procfile Procfile.dev "$@"

But, it never working.

So, i think it should be a issue, thank you.

Another issue, when we have a Procfile with no content, when run procodile start,
get a not so friendly message.

 ╰─ $ procodile start
Traceback (most recent call last):
        2: from /home/zw963/Dropbox/common/ruby/procodile/bin/procodile:85:in `<main>'
        1: from /home/zw963/Dropbox/common/ruby/procodile/bin/procodile:85:in `new'
/home/public/Dropbox/common/ruby/procodile/lib/procodile/config.rb:29:in `initialize': undefined method `each_with_index' for false:FalseClass (NoMethodError)

Running procodile start --dev -p web results in everything being redirected to production.log instead of the custom log_file_name options that I've set. The production.log file does respect the log_root option however.

Maybe this is intentional behaviour but from reading the wiki (which is excellent btw!) I don't think it is. If I'm wrong then maybe it could be called dev.log rather than production.log?

Hi,
I read about procodile and it looks very promising and easy to use, thank you.
Is it possible to have different Procfiles for different environments?

E.g: on development I often use mailcatcher but not on production/staging.
I think it would be nice if we could have one Procfile for each environment like Procfile.development, Procfile.staging

Thank you very much.
Cheers
Flo

procodile looks great @adamcooke, thank you! One thing that has always been an issue with these kind of process managers is handling breakpoints in local development. I guess because the code you're adding the breakpoint to is being managed by another process.

Can you think of a way this could be solved in procodile. The use case is to be able to put something like binding.pry in my code and be able to debug as I would if I was running it manually without it being swallowed.

Hi there,

First, thanks for Procodile! 🙌

In the docs it's mentioned:

It isn't recommended that you add procodile to an application's Gemfile if you have one. It is better practice to run Procodile as a system gem on your local machine and/or server.

Is there a specific reason behind this recommendation, or would it be fine as well to include it as part of the production section of a gemfile for example?

Thanks!

Hi, this is great alternative to godrb, exactly what I was looking for. Thanks for the effort implementing it.

Have you thought about a way to manage multiple procodile instances for apps running at the same server simultaneously? Some kind of 'manager' process that could be started by system's init scripts and would make sure that app-specific procodiles are also started?

Hello!

I have a running instance of application int a kubernetes cluster (with debian10 os). I set up logs path in Procfile.options file but I couldn't see this files on running instance.

$# procodile status
Procodile Version   1.0.25
Application Root    /sample-app
Supervisor PID      8
Started             2019-11-14 13:17:06 +0000

|| web
|| Quantity            1
|| Command             bundle exec passenger start -e production
|| Respawning          5 every 3600 seconds
|| Restart mode        term-start
|| Log path            /sample-app/log/web.log
|| Address/Port        none
|| => web.1            Running      13:17        pid:11       respawns:0      port:-        tag:-

|| worker
|| Quantity            2
|| Command             bundle exec rake run_worker RAILS_ENV=production
|| Respawning          5 every 3600 seconds
|| Restart mode        term-start
|| Log path            /sample-app/log/worker.log
|| Address/Port        none
|| => worker.1         Running      13:17        pid:13       respawns:0      port:-        tag:-
|| => worker.2         Running      13:17        pid:15       respawns:0      port:-        tag:-

root@:/sample-app# ls
Gemfile       Passengerfile.json  Rakefile  config     kubernetes  passenger.3000.pid	    public     test
Gemfile.lock  Procfile		  app	    config.ru  lib	   passenger.3000.pid.lock  resources  vendor
Guardfile     Procfile.options	  bin	    db	       log	   pids			    spec
root@:/sample-app# cd log
root@:/sample-app/log# ls
passenger.3000.log  production.log

Did I set up something wrong? Thanks in advance for any help! :)

Hi, I get the following error when using procodile run on the command line.

procodile run -- bundle exec rake db:migrate
/home/brimir/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/procodile-1.0.19/lib/procodile/cli.rb:366:in `exec': no implicit conversion of Fixnum into String (TypeError)
        from /home/brimir/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/procodile-1.0.19/lib/procodile/cli.rb:366:in `run'
        from /home/brimir/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/procodile-1.0.19/lib/procodile/cli.rb:39:in `public_send'
        from /home/brimir/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/procodile-1.0.19/lib/procodile/cli.rb:39:in `dispatch'
        from /home/brimir/.rbenv/versions/2.3.1/lib/ruby/gems/2.3.0/gems/procodile-1.0.19/bin/procodile:93:in `<top (required)>'
        from /home/brimir/.rbenv/versions/2.3.1/bin/procodile:23:in `load'
        from /home/brimir/.rbenv/versions/2.3.1/bin/procodile:23:in `<main>'

I'm not sure how to stop the supervisor.

➜ procodile start --dev --procfile Procfile.dev
Error: Cannot be started in the foreground because supervisor already running
➜ procodile stop
Error: Procodile supervisor isn't running

Hi,

how to use env like $HOSTNAME to be used into other parameter like a name of a log file :
in the Pocfile:
web: passenger start current --log-file /log/$HOSTNAME_passenger.log ?

Regards
Eric

When it's running in the foreground, it might be useful to have the log output redirected to the console that's running the supervisor.

Perhaps a CLI option or something?

start -f --show-logs

Do you have any idea if is correct to use the procodile on kubernetes containers? I implemented this in one of my projects because I need two running processes (web, worker) but I'm not sure if this is working correctly with auto-scaling provided by Google Cloud Platform.

Foreman loads .env files. While trying to move to Procodile (which doesn't), this was a blocker for me.

Would this be an interesting feature for this project? Or is there any workarounds you guys know of without installing the dotenv gem in the project (which in my case I have no control over)? Thanks.

Firstly, cool tool, I really like it! 🎉

This issue could be/almost definitely is due to my setup, but while start/stop is working successfully, I get errors thrown when running the console/run commands.

The setup is such that I have a directory of commits and a directory of clients, with the contents of commit directories symlinked into the appropriate client directories. Each client directory has its own Procfile/Procfile.local with the appropriate values for that client. This arrangement comes from some clients running different versions than others, and not wanting to have to duplicate each checkout of that version of the app. It looks a little like the below.

.
├── clients
│   ├── sandwich (unique Procfile/Procfile.local and contents of 32d02gg symlinked)
│   ├── gorilla (unique Procfile/Procfile.local and contents of 32d02gg symlinked)
│   └── monkey (unique Procfile/Procfile.local and contents of ce801b1 symlinked)
├── commits
│   ├── 32d02gg
│   ├── ce801b1

Say I cd into monkey and run procodile start --root /srv/clients/monkey; everything is fine. However if I run console (with an appropriately supplied console_command in the Procfile.local), I see the below.

/srv/clients/monkey$ procodile console --root /srv/clients/monkey
/srv/clients/monkey/vendor/bundle/ruby/2.4.0/gems/logging-2.1.0/lib/logging/appender.rb:141: warning: constant ::Fixnum is deprecated
/srv/commits/ce801b1/config/boot.rb:5: warning: already initialized constant RUBY_VERSION_PARTS
/srv/clients/monkey/config/boot.rb:5: warning: previous definition of RUBY_VERSION_PARTS was here
/srv/clients/monkey/vendor/bundle/ruby/2.4.0/gems/logging-2.1.0/lib/logging/appenders/syslog.rb:99:in `open': syslog already open (RuntimeError)
...

It goes on a bit more but you get the idea. As a workaround, I've found that the following works.

cd /srv/commits/ce801b1
procodile console --root /srv/clients/monkey

So I'm basically guessing that console/run isn't handling --root properly when compared to other commands?

tl:dr I see there is procodile restart, is that what I should be using?

Just wondering, why does the procodile start command both attempt to start non-running processes, AND the supervisor every time?

I just started all my "workers" using procodile start, which also started the supervisor for the first time (I had never run it on this new server before)

Then I stopped the workers (for whatever reason, using procodile stop), but then the next time I want to start them back up using procodile start, I get this error:

Error: Cannot be started in the foreground because supervisor already running

(ruby_abc:9.0.1)root@f1fa113d1f2e:~# procodile start
Started Procodile supervisor with PID 6379

(ruby_abc:9.0.1)root@f1fa113d1f2e:~# procodile stop
Stopped sqs_to_abc_worker.1 (PID: 6385)
Stopped abc_to_sqs_worker.1 (PID: 6387)

(ruby_abc:9.0.1)root@f1fa113d1f2e:~# procodile start --dev
Error: Cannot be started in the foreground because supervisor already running

Am I just doing this wrong, or is there another command to start just the workers and not attempt to start the supervisor again?

Based on the help, it does suggest that procodile start is an and/or on the supervisor?

  start              Starts processes and/or the supervisor
  stop               Stops processes and/or the supervisor

I found a problematic typo in https://github.com/adamcooke/procodile/wiki/Configuration

# Per-process configuration options
processes:
  web:
    # The number of this type of process that should be started (default is 1)
    quantity: 2
    # The path to store STDOUT/STDERR output for this process (default is to
    # store in the procodile log or in the log_root if specified)
    log_path: log/processs/web.log
    # Set the name of the log file to use if log_path isn't provided and a 
    # log_root has been set.
    log_file_name: webserver.log
    # The mode that should be used when restart this process (default
    # is term-start)
    restart_mode: usr2
    # The maximum number of respawns that are permitted in the re-spawn
    # window (default is 5)
-   max_repawns: 10
+   max_respawns: 10

I'd like you to fix it, please 🙏

Ref:

Hi,

I have a Rails application that serves as API server and I have another application that is based on Vue in a different repository.

I have not been able to use Procfile as it supports only one root directory. Since I have 2 applications, How can I run it with procodile?

I have also tried Procodile with the following options;

processes:
  web:
    quantity: 1
    env:
      APP_ROOT: /Users/admin/projects/app
  vue:
    quantity: 1
    env:
      APP_ROOT: /Users/admin/projects/app-ui

It doesn't work either. Any help would be appreciated.

Hi!
Here is a simple sinatra app with puma as a server: https://github.com/vfreefly/simple_app
Procfile from app: web: bundle exec puma -t 5:5 -p ${PORT:-3000} -e ${RACK_ENV:-development}

Environment: ubuntu 16.04
Steps to reproduce:

git clone https://github.com/vfreefly/simple_app.git
cd simple_app

rbenv local 2.5.1
gem install procodile

bundle install
procodile start
procodile stop

After these steps app still works on localhost:3000 and puma process is still alive:

Btw, in case of foreman or heroku local all is fine and app with puma stops correctly. Looks like procofile incorrectly determines puma's real process pid.

Let's say I have some common processes I want to run in production (in my server) & development stages (when I'm developing it in my laptop). also there are separate & different processes for each one.

Question:

Is there any options such as below to be able to split the processes list:

common_job1: [...]
common_job2: [...]

[development]
   dev_job1: [..]
   dev_job2: [..]

[production]
   prod_job1: [..]
   prod_job2: [..]

Note: The procodile should pick up the section based on the rails env if nothing has given

Thank you! @adamcooke procodile really cool!

How to use Procfile.dev (or another name) with procodile?

Example(gem foreman): foreman start -f Procfile.dev

Thank you! @adamcooke procodile looks really good.

Is there a way to combine this tool with a monitoring tool like monit?

Again thank you.

Hi!
I'm using procodile along with staytus and want it to be run on localhost only.
So, I made change like

...
  web:
    restart_mode: usr2
    proxy_port: 8787
    proxy_address: 127.0.0.1
...

According to

# procodile status
...
|| Address/Port        127.0.0.1:8787
...

But

netstat -ant | grep LIST
...
tcp        0      0 0.0.0.0:8787            0.0.0.0:*               LISTEN
...

it slill listening on 0.0.0.0
Is it procodial issue or staytus?

If the Procodile PIDs directory isn't empty, try and empty it by checking the status of the processes before just failing to start anything.

My procfile is running a webpack dev server via a package script command.

With foreman that process is terminated correctly:

11:49:54 system       | sending SIGTERM to all processes
11:49:54 hot-assets.1 | terminated by SIGINT

However with procodile that process is not terminated correctly, I've tried setting the option to both SIGTERM and SIGINT in my options file for procodile:

processes:
  hot-assets:
    term_signal: SIGTERM

11:52:54 system          | Stopping all Procodile processes
11:52:54 hot-assets.1    | Sending SIGTERM to 15827
11:52:55 hot-assets.1    | Removed PID file
11:52:58 system          | All processes have stopped
11:52:58 system          | Stopping Procodile supervisor

But after procodile has finished the node processes are still running:

ps aux | grep hot.js
15834   0.0  1.8  3378700 299052 s000  S    11:52am   0:11.67 /usr/local/Cellar/node/6.3.1/bin/node /client/node_modules/babel-cli/lib/_babel-node server-rails-hot.js
15833   0.0  0.1  3096660  19256 s000  S    11:52am   0:00.07 node client/node_modules/.bin/babel-node server-rails-hot.js

This does not happen when using Foreman, I'm currently resorting to manually killing the processes with procodile.

I'd like to put them in a hidden dot folder (./.procodile/pids/ and ./.procodile/procodile.log so it doesn't pollute the project root with these files.

I have installed procodile on my server (gem install procodile) and can verify it's installation by running procodile on the command line.

However, when I deploy via Capistrano 3 (using the most recent version of procodile-capistrano, 1.0.2), I get the following error:

cap aborted!
SSHKit::Runner::ExecuteError: Exception while executing on host MYIP: Exception while executing on host MYIP: procodile restart -r /home/deployer/apps/myapp/current exit status: 127
procodile restart -r /home/deployer/apps/myapp/current stdout: bash: procodile: command not found
procodile restart -r /home/deployer/apps/myapp/current stderr: Nothing written

I get this error from a basic deploy (bundle exec cap production deploy) when I invoke|execute Procodile from an after hook (after :publishing, 'procodile:restart').

Since submitting the ticket, I have managed to get Procodile to fire up the correct processes with a bundle exec cap production procofile:start (or stop or restart).

Long and short, trying to understand why I cannot successfully invoke the 'procodile:restart' from a Capistrano deploy hook.

Hi @adamcooke,

Any ideas why running Procodile within a Docker container would result in the entire container not shutting down on the exit command when running a bash session?

Even after killing the Procodile supervisor process in an effort to shut down the container, I'm left with Zombies 💀 💀 💀 💀 💀 💀 💀

I'm not saying it's Procodile's fault, and I'm sure a lot more is happening in Docker that might cause it (Ubuntu 16.04, running passenger-docker image), but any ideas as to how to diagnose a little more what could be going on after the exit command and why Procodile isn't letting a clean SIG TERM go through?

Cheers,

Nick