Railway•12mo ago

System sending SIGTERM after foreman executes procfile

So I'm running background jobs with Resque in my rails app (specifically for ActionMailer - but maybe more in the future). I tried using a custom start.sh script.. but that wasn't quite working (the services would shut down after they started). So I bit the bullet and decided to use the foreman gem - as that's what a few StackOverflow posts suggested. I already had a fairly robust nixpacks.toml file (thanks to a friendly user here), so I decided to install the foreman gem using the nixpacks.toml. (It can't be installed in my gemfile, as per the foreman docs) (nixpacks.toml is attached). The foreman gem uses a Procfile (also attached) - so I'm using that to: 1. Spin up a production rails server in daemon mode 2. Start my resque worker in the background This all goes to plan... but then I get logs saying System has terminated the processes. Would there be a reason for this? If so... does anyone have advice on running a rake task after the rails server spins up? I'd also like it to keep the rails server logging to Railway (I tried running tails -f as a final task in the procfile - but it kept telling me the ./log/production.log file doesn't exist?) Thanks for all the help I'm receiving here, by the way, I really appreciate it! ProjectID: 1e4b0651-0174-42a1-aac8-4081f16bb807

build_logs_rails_170...

deployment_logs_rail...

nixpacks.toml

Procfile

14 Replies

Percy•12mo ago

Project ID: 1e4b0651-0174-42a1-aac8-4081f16bb807

Brody•12mo ago

are you pro?

yrnsmthOP•12mo ago

Nope - I'm still on the evaluation hobby plan... mildpanic

This is just a portfolio/scratch-my-own-itch project. Is pro required for this kind of thing? (Sorry, too for the timezone differences, btw — your reply came through at 1am my time 🙃)

Brody•12mo ago

im more so asking so that i know what plan youre running this on, you said "evaluation hobby plan" but theres no such thing so ill assume you mean trial and the trial plan only has 512mb of ram per service so its possible you are running into that limit, check your service metrics

yrnsmthOP•12mo ago

sorry, yea, you're right, it is the trial.

the trial plan only has 512mb of ram per service so its possible you are running into that limit, check your service metrics

oooh, I didn't even think about the ram limit there. Will do when I'm on lunch, then I'll report back 🙂

Brody•12mo ago

sounds good 🫡

yrnsmthOP•12mo ago

Here are some screenshots of the metrics tab for my Rails service... Note that my timezone is UTC+10... so it's midway through December 13. 🙂 My CPU and Memory have stayed very much under the limits. However, I did redeploy prior to grabbing these, and I didn't see it move much - so perhaps it's maxing out before Railway can chart these metrics (don't know if that's a thing)? Or maybe there's an issue in my config? On local, I would open a new terminal instance (in the same repo) and run the worker there. However, that's not exactly an option in Railway, as far as I can see (but as you might have guessed, I'm very new to the infra / CI/CD world - I'm front-end with some rails & node/express experience).

Brody•12mo ago

perhaps it's maxing out before Railway can chart these metrics (don't know if that's a thing)?

that is very much a thing and has happened before, i forget the frequency of the metrics collection, but it is very much possible for an app to try to allocate more than 512mb and crash in between railway taking a metrics.

Or maybe there's an issue in my config?

also possible i cant say for certain its either option, but upgrading to hobby is a very easy way to rule out the first option

yrnsmthOP•12mo ago

👍 Looks like I'll be spending some dollars before I planned. Ah well. 🤣 I'll upgrade tonight and see what happens. Thanks for the info 🙂

Brody•12mo ago

only 5$ and youd need to upgrade eventually anyway, you are only on a limited trial after all

yrnsmthOP•12mo ago

I was naughty and upgraded early. Still happening 😦

Brody•12mo ago

well was worth a try well next option, config / code issue, but i dont know ruby or rails so im not gonna be any help there

yrnsmthOP•12mo ago

To be precise, it's not actaully crashing - it's just shutting down the processes. I was concerned it was my nixpacks.toml I kind of just shoehorned installing the package after building out the dependencies:

# ... #
[phases.install]
dependsOn = [
    'setup',
    'postgres',
]
cmds = [
    'bundle install',
    'bundle exec bootsnap precompile --gemfile',
    'gem install foreman'
]
onlyIncludeFiles = [
    'Gemfile',
    'Gemfile.lock',
]
cacheDirectories = ['/root/.bundle/cache']
paths = [
    '/usr/local/rvm/rubies/ruby-3.1.4/bin',
    '/usr/local/rvm/gems/ruby-3.1.4/bin',
    '/usr/local/rvm/gems/ruby-3.1.4@global/bin',
]
# ... #

# ... #
[phases.install]
dependsOn = [
    'setup',
    'postgres',
]
cmds = [
    'bundle install',
    'bundle exec bootsnap precompile --gemfile',
    'gem install foreman'
]
onlyIncludeFiles = [
    'Gemfile',
    'Gemfile.lock',
]
cacheDirectories = ['/root/.bundle/cache']
paths = [
    '/usr/local/rvm/rubies/ruby-3.1.4/bin',
    '/usr/local/rvm/gems/ruby-3.1.4/bin',
    '/usr/local/rvm/gems/ruby-3.1.4@global/bin',
]
# ... #

This is roughly the equivalent of doing the following in a node project:

~ yarn install
~ npm install foreman

~ yarn install
~ npm install foreman

Am I right in assuming the array of cmds array will be executed in ascending order?

Brody•12mo ago

that would be correct

Gaming

Programming

System sending SIGTERM after foreman executes procfile