Closed skunkworker closed 7 years ago
Current config
guard 'rails', port: 3000, host: '0.0.0.0', force_run: true, pid_file: 'tmp/pids/server.pid' do
watch('Gemfile.lock')
watch(%r{^(config|lib)/.*})
watch('tmp/caching-dev.txt') # for Rails 5.1 testing of caching.
end
After some tests, I believe this is a Rails bug. Created the Rails issue here.
The issue exists regardless guard-rails. Even simple rails s -P tmp/pids/dev.pid
would reproduce the issue.
BTW, watch('tmp/caching-dev.txt')
is not necessary. Rails would trigger the restarting by itself. My config:
guard 'rails', pid_file: 'tmp/pids/server.pid' do
watch('Gemfile.lock')
watch(%r{^(config|lib)/.*})
end
@ranmocy that's one of the conclusions I came to as well, it seems as though they hardcode the PID file in multiple places and don't respect other locations.
And thanks for the input about not having to watch the caching-dev.txt
file, just the pid going is enough it seems to trigger the restarting. 👍
With Rails 5.1 adding the
rake dev:cache
command. Code here the default strategy ofwatch('tmp/caching-dev.txt')
would fail when runningrake dev:cache
in another terminal window. As it would complain that the pid already exists. I looked into the implementation in the rails master branch and it turns out that by default it is removing the pid file ontmp/pids/server.pid
. Adding this config to the guardfile fixed the issue. Is this a rails issue not respecting other pid files?