Comments (4)
While a PID file might be useful, the best way to run the final-pm daemon via systemd would be to directly
launch the daemon executable.
The executable bin/daemon
just takes an URI to bind to (unix:// or tcp://) for its one argument. Example: node node_modules/.bin/final-pm-daemon unix:///tmp/test-sock.sock
The daemon logs to stdout and stderr, meaning you can comfortably redirect logging from the parent process to wherever you want those to go. The final-pm "launcher" just sets stdout/stderr to
open file descriptors of the configured log file. Systemd on the other hand will send stdout/stderr to journald by default.
The daemon's signal handling might need to be re-thought for that though, since
SIGINT
initiates a fast shutdown (where the daemon SIGKILL
s all processes and
loggers receive their configured kill-signal
). Maybe there should be a mode
where the daemon cleanly stops everything before exiting on SIGINT
.
This might mean your system will take hours to shutdown depending on how your applications
stop though.
I'll have to make a one-line change so the daemon doesn't expect an open IPC channel on launch, but once I've done so I'll provide an example systemd configuration and probably provide a built-in logger
for logging to journald as well.
from final-pm.
The one-line change I talked about is already in the repo if you want to try it out. There's no release (yet) though - not until some more thought went into this.
Changing anything about this later on might break existing setups.
from final-pm.
While a PID file might be useful, the best way to run the final-pm daemon via systemd would be to directly launch the daemon executable.
Having final-pm run in the foreground is certainly an alternative. Maybe It could be even exposed in the CLI interface via -f/--foreground
/--no-daemon
.
The daemon's signal handling might need to be re-thought for that though, since
SIGINT
initiates a fast shutdown (where the daemonSIGKILL
s all processes and
loggers receive their configuredkill-signal
). Maybe there should be a mode
where the daemon cleanly stops everything before exiting onSIGINT
.
Either that or advise users to customize ExecStop
to do something like ... --wait --kill stop all
along with properly configured TimeoutStopSec
and kill mode.
This might mean your system will take hours to shutdown depending on how your applications
stop though.
This is already configurable via stop-timeout
, isn't it? The clean stop would just respect it as usual.
I'll provide an example systemd configuration and probably provide a built-in logger
for logging to journald as well
👍
from final-pm.
Having final-pm run in the foreground is certainly an alternative. Maybe It could be even exposed in the CLI interface via -f/--foreground/--no-daemon.
This would mean having all the CLI code loaded into the daemon process though. The CLI code isn't as rigorously tested as the daemon (as you already discovered yourself) and it also pulls a ton of extra dependencies. I don't really want all that in a lean daemon...
This is already configurable via stop-timeout, isn't it? The clean stop would just respect it as usual.
Yes.
Just thinking of my own use-case here where a clean stop of a process might take as long as a few days, since it waits until all clients have disconnected. That is usually what I want when I'm just restarting my application within final-pm to get to a new version. But it's not what I'd want to happen when I'm restarting the whole server.
Either that or advise users to customize ExecStop to do something like ... --wait --kill stop all along with properly configured TimeoutStopSec and kill mode.
An added bonus of this approach is that it makes the shutdown behavior of the daemon essentially configurable via your systemd unit file, solving the issue I just raised.
from final-pm.
Related Issues (7)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from final-pm.