I have GitHub action to deploy the app to the server. I'm deploying the app and running a few commands to restart the app using ssh. Then, I'm starting the process using pm2. The problem is, It streams the log to the console stdout, and the Github action hags up with a timeout error. What I want to do is spawn the application instance without streaming the log to the console. Here is the command I'm using to start the app.
NODE_ENV=production && pm2 start ecosystem.config.json
and, here is the ecosystem configuration file.
{
"apps": [
{
"name": "apitoid",
"script": "src/index.js",
"instances": 1,
"autorestart": true,
"watch": false,
"time": true,
"env": {
"NODE_ENV": "production"
}
}
]
}
Is there any way I can prevent logging stream to stdout or no stdout in GitHub action workflow?
Related
I have Laravel application, i use vue3 and inertia with SSR fore client side. It is typical laravel/jetstream app based Inertia - fully follows the documentation. I need deploy this app to VPS/VDS server. In the Inertia documentation they write how to build a client application https://inertiajs.com/server-side-rendering#building-your-app. It is just run node public/js/ssr.js, how i may do this on VPS/VDS hosting with SSH ?
you can use pm2, to run your ssr server in background,
install pm2, npm install pm2 -g.
go to your laravel app directory.
make new file ecosystem.config.json to root folder of laravel project with this command
nano ecosystem.config.json.
copy this code for ecosystem file.
Note: this code for Inertia.js v1.0
{
"apps": [{
"name": "laravel",
"script": "artisan",
"args": ["inertia:start-ssr"],
"instances": "1",
"wait_ready": true,
"autorestart": false,
"max_restarts": 1,
"interpreter" : "php",
"watch": true,
"error_file": "log/err.log",
"out_file": "log/out.log",
"log_file": "log/combined.log",
"time": true
}]
}
Run pm2 with this command pm2 start ecosystem.config.json
you can see all processes status with this command pm2 list and check <div> tags on your source site.
Good luck!
I am trying to get the PM2 logs in my backend server using PM2 API. I tried going through the docs but almost nothing related to logs.
I tried generating a pm2.launchBus but that only gets me current logs and not the old logs.
Usually for checking the pm2 logs:
run pm2 logs (process Id)
run pm2 show (process Id) and it would tell you the log location
May be not using PM2 API but a workable method would be read the logfile using fs and return to your client app
There isn't an API method to get the log data. You can only read it from disk. If you'd like to get more structured information about the log data you can configure the ecosystem (or process) JSON to either:
Add a timestamp
{
"apps" : [
{
"name": "app",
"script": "main.js",
"log_date_format": "YYYY-MM-DD hh:mm:ss"
}
]
}
Which results in:
2021-07-30 06:34:22: Hello World!
Write log entries as JSON
{
"apps" : [
{
"name": "app",
"script": "main.js",
"log_type": "json"
}
]
}
Which will get you:
{
"message": "Hello World!\n",
"timestamp": "2017-02-06T14:51:38.896Z",
"type": "out",
"process_id": 0,
"app_name": "app"
}
See Log Management docs
I am currently having trouble to debug my Azure Functions Core Tools in VS Code.
I am using the npm package azure-functions-core-tools#2.
As i read on many resources func host start / func start should always start the node process in with --inspect=9229. As you can see this is not the case in my setup:
[4/30/19 4:51:25 AM] Starting language worker process:node "/usr/lib/node_modules/azure-functions-core-tools/bin/workers/node/dist/src/nodejsWorker.js" --host 127.0.0.1 --port 50426 --workerId 3e909143-72a3-4779-99c7-376ab3aba92b --requestId 656a9413-e705-4db8-b09f-da44fb1f991d --grpcMaxMessageLength 134217728
[4/30/19 4:51:25 AM] node process with Id=92 started
[4/30/19 4:51:25 AM] Generating 1 job function(s)
[...]
[4/30/19 4:51:25 AM] Job host started
Hosting environment: Production
Also all attempts of changing the hosting environment failed. I tried to add FUNCTIONS_CORETOOLS_ENVIRONMENT to my local configuration, resulting in an error:
An item with the same key has already been added. Key: FUNCTIONS_CORETOOLS_ENVIRONMENT
I tried to add several environment variables in my launch and task settings, using --debug, changing project settings. Nothing works.
I am currently running this on the Windows Subsystem for Linux (WSL) and except this it works really well.
Anyone has a clue on what i am doing wrong here?
I don't think debug is enabled by default. You will have to set the language worker arguments for this to work as documented.
In local.settings.json
To debug locally, add "languageWorkers:node:arguments": "--inspect=5858" under Values in your local.settings.json file and attach a debugger to port 5858.
With func CLI
You could set this by using the --language-worker argument
func host start --language-worker -- --inspect=5858
In VS Code
If you are developing using VS Code and the Azure Functions extension, the --inspect is added automatically as the corresponding environment variable is set in .vscode/tasks.json
{
"version": "2.0.0",
"tasks": [
{
"label": "runFunctionsHost",
"type": "shell",
"command": "func host start",
"isBackground": true,
"presentation": {
"reveal": "always"
},
"problemMatcher": "$func-watch",
"options": {
"env": {
"languageWorkers__node__arguments": "--inspect=5858"
}
},
"dependsOn": "installExtensions"
},
{
"label": "installExtensions",
"command": "func extensions install",
"type": "shell",
"presentation": {
"reveal": "always"
}
}
]
}
You could also set this environment variable directly if you'd like instead of adding it in local.settings.json too.
In a PM2 JSON configuration, is there a way to choose cluster vs. fork mode based on the environment?
Also, it seems like putting watch inside the development environment doesn't actualy restart on changes, even though pm2 status shows watch is enabled?
I've tried this configuration but don't get the expected results:
"env_production": {
"NODE_ENV": "production",
"watch": false,
"exec_mode": "cluster",
"instances": "max"
},
"env": {
"watch": ["files/to/watch/*"],
"ignore_watch" : ["files/to/watch/not/*"],
"exec_mode": "fork"
},
When I run pm2 start app.json it results in mode = cluster but I expect mode = fork
When I kill and re-run pm2 start app.json --env production it results in mode = cluster as expected but the number of workers does not equal number of cores.
I solved it by splitting out each environment into its own "app" within the JSON configuration file.
I want to start node with pm2 and environment variables like --nouse-idle-notification or --max-old-space-size=2048.
However, whatever I do, it is not passing the node variables. I start my app with pm2 and a configuration file. The configuration file looks like:
{
"apps" : [{
"env": {
"NODE_PATH": "/usr/bin/node",
"interpreter_args": "--max-old-space-size=2048 --nouse-idle-notification"
},
"env_development": {
"NODE_ENV": "development"
},
"env_production" : {
"NODE_ENV": "production",
"APP_TYPE": "web"
},
"exec_mode" : "fork",
"name" : "MyApp",
"script" : "/opt/myapp/app.js",
"watch" : false,
"out_file" : "/var/log/app.log",
"error_file" : "/var/log/app.log",
"combine_logs": true,
"node_args": "--max-old-space-size=2048 --nouse-idle-notification",
"args": "--max-old-space-size=2048 --nouse-idle-notification"
}]
}
(as you can see I try to pass in the node variables in multiple ways)
I then start the app with:
pm2 restart pathtojsonfile --env production
Everything is starting up properly and I see variables like "MY_APP" in my code. However, now when I look at the process with "top" I only see:
node /opt/myapp/app.js
When I start the app with forever or manually I can see the process like:
node --max-old-space-size=2048 --nouse-idle-notification /opt/myapp/app.js
Is pm2 just not showing those node arguments or are they really not passed in? (The pm2 started process uses less memory)
Below is extact command to start pm2 with node-args
pm2 start app.js --node-args="--max-old-space-size=4096"
By using "node_args": "--max-old-space-size=2048 --nouse-idle-notification" you did the right thing and these arguments are taken into account.
PM2 renames the process and drop the specified node argument in the process title.