detached child processes are killed when nodemon resets

[Autre31415]

• nodemon -v: 8.11.3
• node -v: 1.18.3
• Operating system/terminal environment: macOS iTerm2
• Command you ran: nodemon -v app.js --development-mode

Expected behaviour

Detached child processes should survive a nodemon reset, just as they would survive a CTRL+C.

Actual behaviour

Detached child processes are killed on reset. If that child process happens to be a java process the app directory will also get spammed with hs_err_pidxxxx.log files that indicate SIGSEGV errors. Example:

# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x000000010da86c68, pid=13670, tid=0x0000000000000307

Steps to reproduce

1. In macOS start up a node process in nodemon which spawns a detached child process.
2. Reset by either editing a watched file or using rs

Note: I don't believe this issue exists on windows.

[stale]

This issue has been automatically marked as idle and stale because it hasn't had any recent activity. It will be automtically closed if no further activity occurs. If you think this is wrong, or the problem still persists, just pop a reply in the comments and @remy will (try!) to follow up.
Thank you for contributing <3

[alallier]

I don't believe this is stale since it hasn't been interacted by the owner or any maintainers in the timeframe.

[remy]

@alallier I'm all the maintainers and owner. I don't have a solution, and so it's stale as no one has come forth.

Can @Autre31415 provide parred down code to replicate? I'm not sure this is fixable (again, since no one has offered any solution), as nodemon is doing exactly what it's supposed to do (end all the subprocesses).

[stale]

This issue has been automatically marked as idle and stale because it hasn't had any recent activity. It will be automtically closed if no further activity occurs. If you think this is wrong, or the problem still persists, just pop a reply in the comments and @remy will (try!) to follow up.
Thank you for contributing <3

[wsmd]

I'm also dealing with this issue. I'm spawning worker processes as detached children that are not part of the codebase I'm using nodemon with, so when the parent process exists, ideally, I'd like for those processes to keep running, even during development.

For example:

const worker = spawn('some_command', args, {
  stdio: 'ignore',
  detached: true,
});

worker.unref()

Using detached and unref() has no effect when the application is running with nodemon as it ends up killing all child processes in the tree on restart anyways:

nodemon/lib/monitor/run.js

Lines 323 to 343 in 7e00a30

	// we use psTree to kill the full subtree of nodemon, because when
	// spawning processes like `coffee` under the `--debug` flag, it'll spawn
	// it's own child, and that can't be killed by nodemon, so psTree gives us
	// an array of PIDs that have spawned under nodemon, and we send each the
	// configured signal (default: SIGUSR2) signal, which fixes #335
	// note that psTree also works if `ps` is missing by looking in /proc
	let sig = signal.replace('SIG', '');
	psTree(child.pid, function (err, pids) {
	// if ps isn't native to the OS, then we need to send the numeric value
	// for the signal during the kill, `signals` is a lookup table for that.
	if (!psTree.hasPS) {
	sig = signals[signal];
	}
	// the sub processes need to be killed from smallest to largest
	debug('sending kill signal to ' + pids.join(', '));
	child.kill(signal);
	pids.sort().forEach(pid => exec(`kill -${sig} ${pid}`, noop));

I can't think of an elegant way to exclude processes that are explicitly detached, but maybe we can add a --no-tree-kill flag for this kind of scenarios. I know that fewer flags is one of the design principles of nodemon, but there isn't really a workaround here, is there?

Could you please consider reevaluating this issue?

[remy]

Nodemon is a development tool for shutting down and restarting. If a process is being "detected", then the dev cycle is to shut it down - not ignore it.

If you need to use nodemon with your codebase in this fashion, the best approach is to spawn the subprocess outside of what's being monitored by nodemon.