The Unix concept of a background process is part of job control. However if a process killed with SIGKILL the program might not have an opportunity to delete it, so subsequent container re-start will fail because the pid file will already be there, but is expected not to. It is not clear for me what is responsible for deleting the pid files, some sources suggest that it's the init system, such as systemd, while others imply that it's the program responsibility. Is there something here I'm missing? What is exactly the background? (And who is responsible for deleting the pid file, while we are at it?)ġ - in a docker container context, where the question arose from, the existence of the pid file can cause problems when the container is stopped and then restarted. In this respect asking the process not to auto-background and then background it does not make a lot of sense. Is the background that the process would normally enter is a different background it is sent to by using &? From all I read, it seems that the only meaning of the background is that shell is not blocked.

So on the face value it seems that the command in question first tells the program not to run in the background with -n, then specify NONE for the pid file, to indicate it is not a daemon 1, and then right after that specify & to send it into the background. If my understanding is correct, pid files are used with daemons, that is when a program is run in the background. The ampersand & seems to mean to request that the command is run in the background, see, for example here. The rsyslogd is started and controlled by init(8). Writing a pid file, use the reserved name 'NONE' (all This option must be used if multiple instances of Specify an alternative pid file instead of the default The question came to live as a result of reading this line of code: /usr/sbin/rsyslogd -niNONE & I want to understand a little bit better, what a background process is.

Python run subprocess in background