We've observed that the princexml engine also listens to the shutdown signals. While this is not inherently a negative thing, it conflicts with our approach of "cleaning up" before shutting down. For us, cleaning up means finishing any active pdf generation before shutting down. i.e. preventing princexml from abruptly shutting down.

Firstly, are our observations correct about the princexml engine? Any suggestions on the best way to deal with this?

Thanks.

By shutdown signals, do you mean UNIX signals like SIGTERM, that might be sent to the process that originally launched Prince?

Yes, that's correct.

I've done some experimenting to try to reproduce this behaviour but have so far been unable to. I can spawn a process with node.js and kill the parent and see the child continue. I can reproduce the behaviour you describe by signalling the process group instead of the process (which is what Ctrl-c does) with `kill -TERM -1187093` (note hypen before process id). In that case the signal is sent to all process in the group and the child exits as well.

To help further I think I need a bit more info:

• What does the code look like that is spawning prince and catching signals?
  
  • Or, if you're using the node-prince npm package, what version?
• How is the signal being sent? What is the command?

Looking at the details provided via email I see you're using dumb-init in the docker container. I think this is the issue. The dumb-init README notes:



This means that when `docker stop` is run it signals the main process, which is dumb-init. dumb-init then signals the process group that it is running, which signals all processes in that group, including Prince.

For the behaviour you're after I think you need to run dumb-init with the --single-child option, which is described as follows:

-c, --single-child   Run in single-child mode.
                     In this mode, signals are only proxied to the
                     direct child and not any of its descendants.